设计模式与重构.ppt

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