优雅程序设计.pptVIP

优雅程序设计 软件编码中的敏捷设计 主题摘要 从一个案例开始 程序的臭味 敏捷团队的实践与原则 测试驱动的开发 代码也会“腐化”？？ 厄运！造化弄人 厄运！造化再三弄人 敏捷设计者又会如何呢？ 这些家伙为什么会这么做？ 敏捷人员的处世原则： 遵循敏捷实践去发现问题； 应用设计原则去诊断问题； 运用适当的设计模式去解决问题。 保持尽可能好的设计 每天、每小时、每分钟 随时随地的重构 敏捷团队无法容忍程序中的臭味！ ——敏捷设计是一个过程，不是一个事件 分辨程序的臭味 程序的臭味——Kent Beck，Martin Fowler ——学会从代码中找寻某些特征，这些特征指出（有时甚至就像尖叫呼喊）重构的可能性。 合理把握重构时机，培养判断能力 ——解释“如何产生一个对象继承体系”非常简单，但是要解释“应该在什么时候做这些动作”就不那么简单了。 常见的臭味： 重复的代码；过长函数；过大类；发散式变化…… ——更多程序臭味，请看《重构》（Martin Fowler） Duplicated Code（重复的代码） 尖叫的臭味——可以肯定的是，设法把它们合而为一，程序会变得更好 同一个Class的两个函数内有相同的代码 ——Extract Method。 互为兄弟的SubClass内含相同的代码 ——Extract Method; Pull Up Method。 毫不相关的两个Class中出现相同的代码 ——Extract Class; 进而决定提炼出的重复代码放在哪个Class中。 Long Method（过长函数） Short Method：复用能力；解释能力；选择能力； Short Method 需要一个好名字； 函数“做什么”和“如何做”之间存在语义差距； ——Extract Method 提炼函数体； ——Replace Temp with Query; Introduce Par-ameter Object; Preserve Whole Object; 处理参数列表； 方法调用的性能开销？ 什么是Long？什么是Short？ Large Class（过大类） 职责定位不清！——典型特征是拥有太多的成员变量； 分辨逻辑关联的变量； ——Extract Class; Extract Subclass; 成员方法瘦身； ——如果有5个百行函数，也许可以变成5个十行和10个二行函数?； Class瘦身运动； ——Extract Class; Extract Subclass; Extract Interface; GUI Class？ ——Duplicate Observed Data; 提炼数据和行为到独立的领域对象（Domain Object）；同步重复数据； 还有…… Long Parameter List（过长参数列） Divergent Change（发散式变化） Shotgun Surgery （霰弹式修改） Feature Envy（依恋情结） Data Clumps（数据泥团） Primitive Obsession（基本型别偏执） Switch Statements（Switch 惊现） Message Chains（过度耦合的消息链） …… 何谓Extract Method？ 一种重构手段，还有“Extract Class”; “Pull Up Method”等等； 动机与做法 实例： 设计的臭味…… 僵化性——改动程序会导致连锁改动 脆弱性——出现问题的地方与改动的地方没有任何概念上的联系 牢固性——设计中含有可重用的成份，但是分离这一部分的难度非常大 粘滞性——做错误的事容易，做正确的事难 不必要的复杂性——为过多的可能性做准备 晦涩性——难以理解的代码，随着时间的变化，代码会变得越来越晦涩 什么激发了软件的腐化？ 设计的缺陷 ——需求的变化同设计的初衷不吻合； 实践的缺陷 ——改动都很急迫，但实施改动的人员往往不是非常理解原始设计； 软件腐化的根本原因是：需求总是在变化的 ——这确实令人非常沮丧！ 我们必须使设计面对需求变化时更具有弹性，并且运用一些合理的实践来防止设计腐化。 回过头来看Copy 最初的设计，简单并且优雅； ——唯一的问题是缺乏适当的弹性 对变化的不恰当应对是失败的直接原因； ——我们的工作是要保证我们的软件能够经受得住连续的变化 思考： 变化总是存在的； 如果我们的软件由于需求变化了而退化，那么我们就不是敏捷的。 敏捷团队的常规实践 敏捷（Agility）团队，是以微小增量的方式构建软件的团体。 敏捷团队不会花费很多时间去预测未来的需求和需要，他们更愿意关注当前的系统结构，并使它尽可能的好。 团队使用许多单元测试和验收测试作为支援，更加使设计灵活、易于理解； 利用设计上的灵