1 / 23

设计模式与重构

漫谈架构设计. 设计模式与重构. 怎么做架构. 课程目的. 最 难的课程 架构 师的成长，有没有 捷径？ 架构 师能不能成体系的 培养？ 寻找我 的 直觉的来源 : 这些自觉不连续 ，不成体系，我想整理 （但在我自己这里是整体性的，对同样的问题，我总是能得到几乎一样的答案）. 内容摘要. 如何进行架构设计 如何 评价并有章法的改进 架构 设计模式 介绍（不是重点）. 架构设计要解决的问题. 架构设计的目标当然不是为了实现模式  架构设计的最终目的是为了产品能给用户提供更好的服务与体验。 降低开发维护成本。

harrison-sullivan
Download Presentation

设计模式与重构

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

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. 推荐书籍 • 《设计模式》 • 《重构-改善既有代码的设计》 • 《人月神话》 • 阅读更多的(好)代码 • 写更多的代码,并不断让他变的更好

More Related