漫谈架构设计. 课程目的  最难的课程  架构师的成长，有没有捷径？  架构师能不能成体系的培养？  寻找我的直觉的来源 : 这些自觉不连续，不成体系，我想整理 （但在我自己这里是整体性的，对同样的问 题，我总是能得到几乎一样的答案）

Presentation on theme: "漫谈架构设计. 课程目的  最难的课程  架构师的成长，有没有捷径？  架构师能不能成体系的培养？  寻找我的直觉的来源 : 这些自觉不连续，不成体系，我想整理 （但在我自己这里是整体性的，对同样的问 题，我总是能得到几乎一样的答案）"— Presentation transcript:

1 漫谈架构设计

2 课程目的  最难的课程  架构师的成长，有没有捷径？  架构师能不能成体系的培养？  寻找我的直觉的来源 : 这些自觉不连续，不成体系，我想整理 （但在我自己这里是整体性的，对同样的问 题，我总是能得到几乎一样的答案）

3 内容摘要  如何进行架构设计  如何评价并有章法的改进架构  设计模式介绍（不是重点）

4 架构设计要解决的问题  架构设计的目标当然不是为了实现模式  架构设计的最终目的是为了产品能给用户提供 更好的服务与体验。  降低开发维护成本。  使软件产品与硬件结合达到最佳的体验和性能  提高产品的发布，部署，维护，升级的灵活性  产品的稳定性，安全性，可靠性。

5 架构师素质模型

6 交付能力模型  T=function( 交付能力, 项目复杂度 )  交付能力雷达图

7 架构设计的几个层次  语言对架构设计的影响 : 结构化语言 C 静态面向对象语言 C++ 完全面向对象语言 Java,Obj-C 动态语言 :JS,Lua 系统级架构 模块级架构 编码级架构 每个层次都很重要

8 好架构可以  应对预期的需求变更（如何做好需求分 析？）  有清晰的模块边界  工作可分：支持多人并行开发 1 项工作需要 60 个人月，那么是否是 60 个人做 1 个月就能完成呢？  易于理解与维护 (KISS)  是合适的，能尽量与当前的计划匹配

9 如何开始架构设计  分析系统需求，确定系统所在的领域  使用领域里的成熟设计 / 从头设计  关键技术选型  寻找本质问题：架构要强化体现本质问 题，弱化次要问题的关注度。  抽象高于实现：先抽象概念，再用概念来 组合解决系统的本质问题。  架构并不直接解决问题，而是提供持续解 决问题的平台。

10 详细的架构设计  大的系统结构设计 ( 关注协议 )  每个子系统的模块设计（关注接口）  模块的关键实现描述, 包括有哪些类，类 之间的继承关系，持有关系，依赖关系， 方法属性事件，关键函数可以写伪代码 （关注问题解决）  根据项目计划调整（调整架构或调整计 划）

11 架构设计文档化  第一部分，第二部分用图文档化  UML? 使用你的读者能无歧义理解的方法均 可。 UML 重点关心的问题有哪些 ?  描述模块划分  类的依赖关系，继承关系  类实例之间的持有关系  类的关键方法与事件  类的关键方法的大体实现逻辑，如有需要请 描述核心问题解决需要的时间复杂度和空间 复杂度

12 为什么要有设计模式？  设计模式是对常见架构设计的总结和提炼  不使用设计模式的架构不一定是坏架构， 而大量使用设计模式的架构不一定是好架 构 方便沟通！  区分 模式 (Pattern) 框架 (Framework) 和 平台 (Platform)

13 量化的评价架构 需求变更 / 新增成本度量 原理：需求变更 / 新增时架构能让修改尽量集 中，影响的模块尽量少, 需要重新测试的模块少 （模块 A 依赖模块 B, 如果模块 B 修改，那么理论 上模块 A 也是需要测试的） 算法： 修改配置文件 : 修改每个文件 3 分, 修改的内容超 过一段每段 2 分 修改代码 : 修改一个物理模块 5 分, 新建文件 1 分, 修 改文件 2 分，修改文件超过 1 段的每段代码加 2 分。模块编译 3 分。

14 需求变更了！  是预期的变更么 ?  代码怎么改？  哪几个层次的架构该改了 ?  需求变更成本评价得分 :

15 产品发展中的架构演进：架构重构  《重构 - 改善既有代码的设计》  为什么要重构？架构有问题  敏锐的闻到代码的坏味道  优先重构难懂的代码  一步一个脚印，明确重构的界限  注意项目的进度控制  最简单的重构 :rename  必要时重新设计系统

16 三次设计原理  架构严重依赖领域经验  通常在一个新的领域，一个系统要重新设 计三次才能得到一个比较靠谱的架构。  找到本质问题  正确的抽象

17 一些架构设计的原则  少用继承多用聚合  清晰的单向依赖  模块越底层，依赖项就应越少  依赖越少的代码越有价值  清晰一致的生命周期管理  代码看起来和跑起来要一致  DRY 原则要让位于 KISS 原则  找到 “ 一定要写的代码 ” ，写 “ 依赖最少的代码 ”

18 常用设计模式  GoF 的《设计模式》是经典，值得多读  注意《设计模式》里的背景  区分通用模式与领域模式

19 常见通用模式  单件 (Singlon)  工厂模式 (Factory)  命令模式 (Command)  适配器 (Adapter) 与桥接 (Bridge)  策略 (Strategy)  迭代器 (iterator)  生产者 - 消费者  MVC （图形交互应用）

20 领域模式  有限状态机解释器 (Parser) 拒绝 string::find, 实现 O(n) 的算法  用脚本代替配置文件  反应器 (Reactor 与 Proactor)  文档 - 视图 (Document-View)  UI 对象树 (UIObjTree)  GFS,BigTable,MapReduce  Interface - LRU Cache - DB  Plugin

21 选择合适的架构  最终用户不关心架构  互联网产品非常复杂：多平台, 变化快, 还要 求完美的细节  面对本质问题 不要过度设计！

22 ----- 简单性是这个世界上最难获 得的东西 ; 它是经验的最终极 限，也是天才的最终努力目 标。

23 推荐书籍  《设计模式》  《重构 - 改善既有代码的设计》  《人月神话》  阅读更多的 ( 好 ) 代码  写更多的代码, 并不断让他变的更好