Transcript 设计模式与重构.ppt

漫谈架构设计
课程目的
最难的课程
 架构师的成长，有没有捷径？
 架构师能不能成体系的培养？
 寻找我的直觉的来源:
这些自觉不连续，不成体系，我想整理
（但在我自己这里是整体性的，对同样的问
题，我总是能得到几乎一样的答案）

内容摘要
如何进行架构设计
 如何评价并有章法的改进架构
 设计模式介绍（不是重点）

架构设计要解决的问题
架构设计的目标当然不是为了实现模式
 架构设计的最终目的是为了产品能给用户提供
更好的服务与体验。
 降低开发维护成本。
 使软件产品与硬件结合达到最佳的体验和性能
 提高产品的发布，部署，维护，升级的灵活性
 产品的稳定性，安全性，可靠性。

架构师素质模型
评分
懂需求
/通用格式
/通用格式
安全知识
/通用格式
/通用格式
/通用格式
产品的发布升
级流程
懂代码
评分
懂项目管理
硬件架构
交付能力模型
T=function(交付能力,项目复杂度)
 交付能力雷达图

2
团队能力
/通用格式
/通用格式
/通用格式
/通用格式
/通用格式
系统架构
2
项目管理能
力
架构设计的几个层次
语言对架构设计的影响:
结构化语言 C
静态面向对象语言 C++
完全面向对象语言 Java,Obj-C
动态语言:JS,Lua
 系统级架构
 模块级架构
 编码级架构
 每个层次都很重要

好架构可以
应对预期的需求变更（如何做好需求分
析？）
 有清晰的模块边界
 工作可分：支持多人并行开发
1项工作需要60个人月，那么是否是60个人做
1个月就能完成呢？
 易于理解与维护(KISS)
 是合适的，能尽量与当前的计划匹配

如何开始架构设计
分析系统需求，确定系统所在的领域
 使用领域里的成熟设计/从头设计
 关键技术选型
 寻找本质问题：架构要强化体现本质问
题，弱化次要问题的关注度。
 抽象高于实现：先抽象概念，再用概念来
组合解决系统的本质问题。
 架构并不直接解决问题，而是提供持续解
决问题的平台。

详细的架构设计
大的系统结构设计 (关注协议)
 每个子系统的模块设计（关注接口）
 模块的关键实现描述,包括有哪些类，类
之间的继承关系，持有关系，依赖关系，
方法属性事件，关键函数可以写伪代码
（关注问题解决）
 根据项目计划调整（调整架构或调整计
划）

架构设计文档化







第一部分，第二部分用图文档化
UML? 使用你的读者能无歧义理解的方法均
可。UML重点关心的问题有哪些?
描述模块划分
类的依赖关系，继承关系
类实例之间的持有关系
类的关键方法与事件
类的关键方法的大体实现逻辑，如有需要请
描述核心问题解决需要的时间复杂度和空间
复杂度
为什么要有设计模式？
设计模式是对常见架构设计的总结和提炼
 不使用设计模式的架构不一定是坏架构，
而大量使用设计模式的架构不一定是好架
构

方便沟通！

区分 模式(Pattern) 框架(Framework) 和
平台(Platform)
量化的评价架构


需求变更/新增成本度量
原理：需求变更/新增时架构能让修改尽量集
中，影响的模块尽量少,需要重新测试的模块少
（模块A依赖模块B,如果模块B修改，那么理论
上模块A也是需要测试的）
算法：
修改配置文件:修改每个文件3分,修改的内容超
过一段每段2分
修改代码:修改一个物理模块5分,新建文件1分,修
改文件2分，修改文件超过1段的每段代码加2
分。模块编译3分。
需求变更了！
是预期的变更么?
 代码怎么改？
 哪几个层次的架构该改了?
 需求变更成本评价得分:

产品发展中的架构演进：架构重构
《重构-改善既有代码的设计》
 为什么要重构？架构有问题
 敏锐的闻到代码的坏味道
 优先重构难懂的代码
 一步一个脚印，明确重构的界限
 注意项目的进度控制
 最简单的重构:rename
 必要时重新设计系统

三次设计原理
架构严重依赖领域经验
 通常在一个新的领域，一个系统要重新设
计三次才能得到一个比较靠谱的架构。
 找到本质问题
 正确的抽象

一些架构设计的原则
少用继承多用聚合
 清晰的单向依赖
 模块越底层，依赖项就应越少
 依赖越少的代码越有价值
 清晰一致的生命周期管理
 代码看起来和跑起来要一致
 DRY原则要让位于KISS原则
 找到“一定要写的代码”，写“依赖最少的代
码”

常用设计模式
GoF的《设计模式》是经典，值得多读
 注意《设计模式》里的背景
 区分通用模式与领域模式

常见通用模式
单件(Singlon)
 工厂模式(Factory)
 命令模式(Command)
 适配器(Adapter)与桥接(Bridge)
 策略(Strategy)
 迭代器(iterator)
 生产者-消费者
 MVC （图形交互应用）

领域模式
有限状态机解释器(Parser)
拒绝string::find,实现O(n)的算法
 用脚本代替配置文件
 反应器(Reactor与Proactor)
 文档-视图(Document-View)
 UI对象树(UIObjTree)
 GFS,BigTable,MapReduce
 Interface - LRU Cache - DB
 Plugin

选择合适的架构
最终用户不关心架构
 互联网产品非常复杂：多平台,变化快,还要
求完美的细节
 面对本质问题

不要过度设计！
-----简单性是这个世界上最难获
得的东西;它是经验的最终极
限，也是天才的最终努力目
标。
推荐书籍
《设计模式》
 《重构-改善既有代码的设计》
 《人月神话》
 阅读更多的(好)代码
 写更多的代码,并不断让他变的更好
