现在敏捷开发已经深入人心了，但敏捷方法依然难于衡量与提高。本书将介绍用于评估和优化个人及团队敏捷实践的已经过证明有效的技巧。通过真实的实例，书中介绍了规则、态度、习惯、技术实践以及各种设计老师，除此炎外，还展示了如何把这些组合在一起以开发出高质量的软件。适合于开发人员、项目经理和项目团队人员阅读。

我曾经告诉我的团队，精益和敏捷实践应该像吃自助餐那样：不要试图掌握所有一切，而是去尝试那些对项目有意义的事情，否则就会失败。在这本书里，作者简洁地描述了最有效的那些实践的‘为什么’及‘怎么做’，这些有效的方式可以帮助所有软件工程师在短周期内写出高质量代码。
—— Kay Johnson，IBM软件开发效率顾问

成功的敏捷开发不仅仅要求精通一门计算机语言，更要求对敏捷开发方式和最佳实践有深层次的理解。这本书为学习乃至真正理解敏捷开发背后的方法和动机提供了一个完善的基础。
—— R.L. Bogetti，www.RLBogetti.com，Baxter Healthcare公司系统设计师

这本书是一个很好的资源库，它提供了许多可供练习的、能演示那些关键敏捷实践的代码样例。
—— Dave Hendricksen，Thomson Reuters软件架构师


虽然敏捷已经成为当今软件开发领域的典范，但是敏捷方法仍然难以考量和改进。本书采用自底向上的方式填补了这一空白。书中介绍了评估与优化个人和团队敏捷实践两方面已经过验证的技术。
本书作者是Net Objectives公司（Net Objectives是当今敏捷领域领先的培训和咨询公司）的4位顶级软件开发专家。书中展示了他们在帮助企业向敏捷转型方面的非凡经验，讨论了一些特定活动和见解，以保证如何用最经济的投入来获得最大的设计和开发回报。
作者在本书中揭示了与成功敏捷项目相关的关键因素及测量它们的切实可行的方法。通过一些真实的例子，展示了敏捷实践的原则、对问题处理的态度、编程的行为习惯、技术实践以及设计需要关注的几个方面，同时又展示了如何将这几个关键因素结合起来最终交付高价值的软件。公司的管理层和团队用这些法宝来优化整个组织及产品整个生命周期的运维，一定会受益匪浅。

译者简介
郑 立　敏捷教练、CSP、管理咨询顾问和资深软件开发工程师，致力于敏捷技术的实践、研究和推广，曾发表论文《敏捷软件开发模型实施研究》，组织并参加了中国敏捷之旅（AgileTour）、Scrum Gathering China、敏捷中国（Agile China）和其他敏捷活动。在软件开发流程和管理方面有深刻的认识，专注于提高企业级软件的开发效率和品质。

邹 骏　敏捷教练、极限编程实践者和资深软件开发工程师，是国内Scrum和持续集成技术的先驱者之一，致力于帮助企业实践敏捷软件开发方法，并重点关注优秀的软件设计原则和编码方式、持续集成、测试自动化等工程实践能力的培养。

黄 灵　敏捷教练、PMP、CSM 和CSP，有多年软件开发项目和项目群管理经验。现就职于惠普，担任敏捷教练和咨询师，为团队提供敏捷培训和咨询，并在这个过程中不断提升自己对敏捷思想的理解和认识。上海敏捷社区的积极参与者和贡献者之一，曾参与过AgileTour Shanghai 和Scrum Gathering China的组织活动。

作者简介
Alan Shalloway　Net Objectives公司创始人兼CEO，Jolt大奖得主，精益软件和系统协会（the Lean Software and Systems Consortium）的共同创始人及董事会成员，有40余年工作经验，是精益、产品管理、敏捷软件设计领域的思想领袖。致力于帮助企业完成向精益和敏捷的转型，并研发了一套关于精益和敏捷的培训辅导方法，帮助Net Objectives公司的客户取得了可持续的生产力。他拥有麻省理工学院计算机科学系的硕士学位和艾莫利大学数学系的硕士学位，经常活跃于全球范围的各种顶尖技术会议并发表精彩演讲。著有《Design Patterns Explained: A New Perspective on Object-Oriented Design》（获Jolt大奖）和《Lean-Agile Pocket Guide for Scrum Teams》等经典著作。

Scott Bain　敏捷导师，Jolt大奖得主，有近40年计算机行业工作经验，在软件开发、软件工程、框架设计和计算机教育等领域都有深入的研究，是敏捷分析、高级软件设计和测试驱动开发等领域的权威人物。著有经典著作《Emergent Design: The Evolutionary Nature of Professional Software Development》（获Jolt大奖），曾多次受邀在JavaOne和SDWest这样的开发者大会上发表精彩演讲。

Ken Pugh　 敏捷导师，Jolt大奖得主，Net Objectives公司高级咨询师，多年来致力于帮助企业完成向精益和敏捷的转型，为企业提供培训和辅导。他热衷于研究沟通（尤其是有效地传递需求）和业务价值交付，以及用精益原则来快速实现高质量的软件交付。著有《Prefactoring: Extreme Abstraction, Extreme Separation, Extreme Readability》（获Jolt大奖）和《Lean-Agile Acceptance Test Driven Development: Better Software Through Collaboration》等多本经典著作。工作之余，他喜欢滑雪、帆船、自行车和阿巴拉契亚徒步登山活动。

Amir Kolsky　资深敏捷技术专家，Net Objectives公司资深咨询师和培训讲师。有超过25年的计算机行业工作经验，曾在IBM研究院工作过10年，此外有9年时间在各种大小类型的公司担任首席架构师和首席技术官等职位。他在敏捷和精益领域都颇有建树，在精益、敏捷、极限编程、设计模式以及测试驱动开发等方面有深厚的积累，先后创建了MobileSpear和XPand等软件公司，专门在以色列和欧洲提供敏捷培训和敏捷项目实施。

尽管本书是一本技术性的书籍，但里面涉及的很多想法都是我们在Net Objectives公司的敏捷开发培训课程中迸发出来的。过去，在给学生传授如何采用Scrum或者精益方法的时候，经常有人会问我：“我们应该怎样做，才有能力一步步地构造我们的软件呢？”答案对我而言显而易见。他们其实真正想问的问题是：“我们怎么才能用最好的方式，学习如何一步步地构造我们的软件？”关于这个问题，有下面三种方法：
 读书我相信任何一个读过并且读懂了《Design Patterns Explained:A New Perspective on ObjectOriented Design》和《Emergent Design:The Evolutionary Nature of Professional Software Development》的人，都知道如何一步步地写软件。
　参加培训这个方法要更好一点。如果能够把Net Objectives公司的课程(设计模式（Design Patterns）和浮现式设计(Emergent Design))结合在一起上，那就无法超越了。
　学习一些“小舵板”（trim tab）软件开发中的“小舵板”使得一步步地构造软件更加有效。
第一种方法需要投入很多时间，第二种方法则花费很高。相比之下，第三种方法所需要的投入则小得多。遗憾的是，这些“小舵板”不是简简单单就可以讲清楚的。
“什么是小舵板（trim tab)呢？”它们是飞机和船只上的零件，用以减少控制飞机副翼或者船舵所需要的能量。但是这里“小舵板”的意思则是来源于Bucky Fuller曾经提到过的东西。
　或译为配平调整片。——译者注 
　　在思考一个小小的人类个体能够做什么的时候，一些东西曾经给过我很深的冲击。
　　想象一下“玛丽皇后”号——当整艘船远去，它的舵浮现眼前。你会发现，在舵的边缘，有一个小零件，叫做“小舵板”。它是一个微缩版的船舵。只需移动这块小小的舵板，产生一个轻微的压力，就可以拉动整个船舵转动，毫不费力。我认为小小的个体也可以成为“小舵板”。一个人在社会中的行为，就好比一艘船的舵板，细微的行动也可以驱动社会这艘大船向前行驶。
　　所以，请叫我“小舵板”。
　　换言之，这里要学习的“小舵板”，就是指可以让我们在较小投入下获得最深刻理解的措施和真知灼见。在设计模式课程中，我们识别出三个基本的“小舵板”。实践了这三点的学生，他们都看到了自己在设计和编程能力上的巨大提高。“这三点是什么？”当然就是本书要讲的内容：
　　 意图导向编程（Programming by Intention）。
　　 把使用从构造中分离。
　　 编码前考虑可测试性。
　　这三点非常简单，实践它们也几乎不会增加额外的时间。 实际上，它们都是与封装相关的。第一点和第三点封装的是行为的具体实现，而第二点则显然着重于封装如何构造。这个主旨非常重要，因为对实现进行封装是一种抽象过程。　　它是众多实现方式中的一种——在未来，可能还会有其他的方式。我认为，把新代码集成到原有系统时遇到严重问题的主要原因，就是因为忘记了这一点。
　　要推荐的第四个“小舵板”是，遵循Shalloway原则。这一点需要多花点时间，但总是很有用处。
　　本书就是“小舵板”的汇集。这些“小舵板”都是Net Objectives公司的讲师和教练发现的敏捷软件开发人员可以遵从的基本要素，告诉我们如何以有效的形式来编写高质量的代码。你可以在闲暇的时间里，按任何的章节顺序来阅读本书。也就是说，这些章节顺序如此编排仅仅是为了协助我们理顺思绪而已。

计算机\软件工程

“我曾经告诉我的团队，精益和敏捷实践应该像吃自助餐那样：不要试图掌握所有一切，而是去尝试那些对项目有意义的事情，否则就会失败。在这本书里，作者简洁地描述了最有效的那些实践的‘为什么’及‘怎么做’，这些有效的方式可以帮助所有软件工程师在短周期内写出高质量代码。”
——Kay Johnson，IBM软件开发效率顾问
“成功的敏捷开发不仅仅要求精通一门计算机语言，更要求对敏捷开发方式和最佳实践有深层次的理解。这本书为学习乃至真正理解敏捷开发背后的方法和动机提供了一个完善的基础。”
——R.L. Bogetti，www.RLBogetti.com，Baxter Healthcare公司系统设计师
“这本书是一个很好的资源库，它提供了许多可供练习的、能演示那些关键敏捷实践的代码样例。”
——Dave Hendricksen，Thomson Reuters软件架构师


虽然敏捷已经成为当今软件开发领域的典范，但是敏捷方法仍然难以考量和改进。本书采用自下向上的方式填补了这一空白。书中介绍了评估与优化个人和团队敏捷实践两方面已经过检验的技术。
本书作者是Net Objectives公司（Net Objectives是当今敏捷领域领先的培训和咨询公司）的4位顶级软件开发专家。书中展示了他们在帮助企业向敏捷转型方面的非凡经验，讨论了一些特定活动和见解，以保证如何用最经济的投入来获得最大的设计和开发回报。
作者在本书中揭示了与成功敏捷项目相关的关键因素及测量它们的切实可行的方法。通过一些真实的例子，展示了敏捷实践的原则、对问题处理的态度、编程的行为习惯、技术实践以及设计需要关注的几个方面，同时又展示了如何将这几个关键因素结合起来最终交付高价值的软件。公司的管理层和团队用这些法宝来优化整个组织及产品整个生命周期的运维，一定会受益匪浅。

（美）Alan Shalloway， Scott Bain， Ken Pugh， Amir Kolsky 著：暂无简介

郑立 邹骏 黄灵 译：暂无简介

一直记得一句话：一个好的程序员，每天至少写一行代码。
　　经常看到一句话：程序写得好不好，就看架构写得好不好。
　　现在想到一句话：是否敏捷程序员，就看有没有看过本书。
　　翻译这本书之前，我们每人每年平均能看十来本书，以为翻译也是个轻松活，应该可以轻松搞定。结果翻译这本书时，我们三个人花了将近9个月的时间。回顾整个过程，不是这本书涉及的技术难倒了我们，而是担心没有理解原作者的意图，生怕给读者传达了错误的信息。好书就应该体现出它应有的价值。我们在文字表达上尽量避免使用拗口的方式，力争用朴素的语言给大家打开这扇学习之门，唯一遗憾的是我们使用的语言还不够诙谐和幽默，所以请你在看本书的时候，尽量选择能够放松的环境，来点背景音乐可能会更好。
　　译完本书最大的感悟是，“世界上不存在这样一种方法：只要套用，就可以写出完美的软件，无论使用的是哪种设计模式；但是却存在一种开发方式，可以帮助我们一步步构造出需要的软件和架构——这就是敏捷软件开发模式。”
　　本书不是一本介绍编程基础的书，作者没有花任何精力去介绍如何使用一门编程语言，也没有在此介绍任何工具。自始至终，作者围绕一个主题——“敏捷式编程”。书中引用了作者工作过程中的大量实际例子作为参考，认真解释了每一步分析过程，如果你正处于追求设计能力提高的阶段，或者你正为如何减轻以后重构的负担，又或者碰到了一些一直解决不了的设计问题，那么你将很可能在本书中得到一些启发。
　　本书共分为四个部分。
　　第一部分重点介绍了“小舵板”理论，顾名思义这是一种四两拨千斤的思想方法。如何使用我们每个人心中的小舵板是每个架构师应该考虑的问题。这一部分介绍了多种小舵板：意图导向编程、分离构造和使用以及测试先行。此外还介绍了业界常用的几种最佳实践，包括如何封装、面向接口的设计和验收测试驱动等。
　　意图导向编程并不是一个新概念，如果你看过Net Objective产品开发系列丛书，应该对它或多或少有所了解。本书将以意图导向编程开始，让你了解到如何从上往下，逐步将使用的需求转换为被封装功能或者意图。就是那么简单的层层分解和封装，加上我们基本的设计方法即可实现意图导向编程。通过意图导向编程，我们可以使代码的内聚性和可读性得到提升，并易于重构和测试。
　　和意图导向编程有相同优点的是测试先行，这两种方法都是对功能实现的过程。分离构造和使用部分着重于封装如何去构造。再加上Shalloway——去冗余理论，结合这四种方式，将给我们未来代码的设计和实现带来意想不到的清晰感和发挥空间。你将不会再为重构难而犯愁了。
　　本书第二部分对过度设计问题和持续集成这两个最佳实践做出了诠释，相信可以帮助那些正处于设计阶段感到困难的架构师一点启示。持续集成应该是老话题了，不过作为敏捷的最佳实践之一，有些经验性的东西，作者很愿意与大家分享。
　　在本书第三部分中，作者凭借多年的教学经验，分享了很多只有在他们的教学现场才能得到的经验。这些内容你或许听说过，只有少部分人能够真正理解这些精髓。但这些经验却是优秀架构师应该具备的。这部分重点介绍了设计中隐藏的一些问题，以及我们该如何去解决。
　　例如，对象共性和可变性分析帮助我们定义架构的基础，译者也曾在介绍如何分析用户故事时用到这一理念，颇为受益。开放关闭原则告诉我们任何系统都可能被更改，因此我们的设计要时刻为改变做好准备。遵循开放关闭原则是我们可复用设计的基石。这个部分将用一个实例介绍开放关闭原则，为将来如何做抽象层、如何定义接口带来很多启示。
　　第四部分是附录，介绍了统一建模语言、提高代码质量的原则，以及如何封装原始数据类型等。
　　本书除了作者的一些经验总结外，还有很多与作者相交甚深的知名人士的经验，包括《设计模式》、《多范式设计》、《重构》等书的作者，也有来自客户的经验，当然还有作者所在公司内部之间的相互沟通和学习。因此，译者在此不仅要介绍作者所传授的知识，那种获取知识的途径也是难能可贵的学习财富。
　　作者写了很多，译者在此总结却很少，因为除此以外，本书还有很多对高含金量技术的介绍，书中有很多隐藏的宝藏等待你亲自去发掘。相信本书一定会给你的工作和学习带来较大的收获。
　　参与本书翻译的主要人员是郑立、邹骏和黄灵。熬过将近两百多个日夜的激烈讨论，终于完成了本书的翻译。虽然比起作者，我们的付出是微小的，但是这个过程我们收获了很多，不仅仅是知识、友情、历练以及成就感，这些收获在我们自己的人生道路上是无价的。
　　最后，十分感谢在翻译过程中给予大力帮助的亲戚和朋友，包括：郭继菁对一些重要章节的友情协助；郑立贤惠的妻子和可爱的女儿的精神鼓舞；邹骏妻儿的默默奉献；黄灵家人的温馨陪伴。正是这些亲人和朋友的贡献，给敏捷注入了生命力，让思想随着这本书可以不断地延续和扩展。
译者
2012年7月

软件行业一直有这样的传说，认为同等经验的两个不同程序员，在效率和质量上可能会有10倍的差距。不同的说法很多，具体的倍数差距也各不一样，但都证明了一点，不同人的编程生产力确实存在着巨大的差距。而且，一般来说，那些在单位时间内能够写出更多代码的程序员，他们的代码质量相对更低且更容易出错。我们不由得要问，大家都是写代码的，造成如此巨大差距的原因何在？
　　俗话说“失之毫厘，谬以千里”，对于程序员这个职业来说，若失去良好的编程习惯，那么谬的就是效率、成效和质量。养成良好的编程习惯无比重要，而其中最重要的就是一定要有设计意识，好的程序员不仅仅只是意识低下的键盘、鼠标输入器，而是要将优秀的设计思想和对实现对象的理解融入其中，从而开发出高质量、简洁的代码。
　　本书的几位作者在书中和大家分享了他们高效软件开发的经验，给大家提供了4个撬动敏捷软件开发的“小舵板”：意图导向编程、分离构造与使用、测试先行，以及Shalloway原则。无须从一开始就考虑全盘实践所有的敏捷编码原则，只要从这些小细节入手，就能够逐渐地产生大变化。阿基米德曾说过，“给我一个支点，我就能撬动地球。”而这些小细节，就是敏捷程序员撬动高质量软件开发的支点。
　　不管读者是已经有多年的编程经验还是刚刚入行开始写代码，都可以从此书中有所收获。亡羊补牢为时未晚，现在开始永远都不迟。本书的内容也非常耐读易懂，4位作者就像是循循善诱的老师，带着大家一步一步地体会其中的实践过程。他们总是从一个具体的问题出发，讨论有哪些方法可以实现，使用“小舵板”的方式又有什么样的好处，而使用对比的方式则有助于大家加深对这些编码原则的理解。
　　文中绝大部分内容都是开发人员凭一己之力即可以做到的，只有ATDD和CI需要有其他同事和相应工具的支持才行，这意味着本书的确就是一部开发人员个人的敏捷实践指南。而根据“一万小时天才理论”的说法，任何人都得经过一万小时（即10年每天3小时）才能达到世界级水准。如果我说这本书能够帮助大家事半功倍可能略嫌夸张，但遵循作者们的建议，至少也能够少走弯路，按正常的速度成为高手。
　　近些年来，我一直在从事敏捷教练和顾问的工作，协助一些组织、部门、团队和个人使用敏捷方法和实践。在与软件开发中不同角色的交流合作中，在和不同的软件开发思想、方法论的实践者和积极推动者的交流中，我发现，IT行业其实相当“喜新厌旧”，各种新概念、新方法论、新思想层出不穷，而在这其中唯一不变的就是我们对高质量代码的追求。而这本书的内容，即便到了将来，敏捷可能不再热门的时候，也依然适用，因为它讲的就是如何写出高质量代码的技巧和习惯。
　　书写高质量代码，是每一个软件人的责任。如今有很多团队，他们耗费大量的时间纠缠于所谓的“遗留系统”，为其进行后续开发和维护。这一切都是代码质量低下惹的祸，不管是从创建代码的第一天起，还是在修改代码的每一次，软件缺陷就已经悄悄地扎下了根。其实代码就像是土壤，盐碱地里种不出好粮食，不勤耕细作同样也种不出好粮食，而这一切就需要我们能够了解土壤自身的情况以及耕种所需要顾及的各个方面。代码也一样，你熟悉你的代码吗？面对满目疮痍的遗留代码，你会拿着化肥、杀虫剂、催产素等一大堆化学制品往上面泼，只为了能够继续生产出“可运行”的产品功能吗？着手开发代码之前，你清楚它的脾性吗？知道种植庄稼需要什么样的环境和呵护吗？你会不断地甚至优先地进行检查吗？你会设立可视化手段持续地监控其健康指标吗？你会选择好的种子和作物吗？
　　当然，书写高质量代码也不仅仅是个人层面的事情，它也关系到组织和企业软件研发的延续性。铁打的营盘流水的兵，人员流动对企业来说是常事，而代码则屹立不动、不断延续，直到某一天产品也寿终正寝的时刻便化为灰烬。阅读和修改晦涩难懂的代码，总是比阅读、修改简单易懂的代码来得困难，耗时也更多，出错的概率也更高，这一切也都意味着更高的时间和资金成本。当然，除了可读性，代码的设计和结构也很重要，影响范围和效果也更大。
　　遇到丑陋的代码，我们的第一反应可能是躲避，也可能是“那就改掉呗”。然而，“冰冻三尺非一日之寒”，恶劣代码的形成也不是一朝一夕的，要扭转局面需要比制造局面更坚强的毅力。而在这一切背后，是人的习惯和思维定势，需要创建出一种鼓励产出优良代码、鼓励形成良好习惯的环境，从而培育出更良好的代码，维持可持续的研发速度，不为缺陷修复所累。每一位程序员都应该阅读此书，学习“小舵板”，持之以恒地磨练。研发经理也应该阅读此书，以此为标准，创造出所需的环境并鼓励团队和个人加以实践。
　　“己所不欲，勿施于人”，没有人愿意维护难以理解、难以修改、难以增加功能的代码，那么也应该所有人都努力督促自己不写出这样的代码。就让我们从现在开始，努力地写高质量代码吧！
徐毅
　　诺基亚敏捷及精益教练
　　Agile China 2012大会执行副主席
　　Scrum Gathering Shanghai 2011及2012核心组织者

推荐序
译者序
丛书前言
前言
致谢
第一部分最关键的小舵板
第1章意图导向编程
11意图导向编程：一个实例
12优点
121方法的内聚性
122可读性和表达性
123调试
124重构和增强
125单元测试
126更易修改和扩展
127在代码中发现模式
128可迁移的方法
13小结
第2章分离构造和使用
21一个重要的问题
22两种视图
221创建视图
222使用视图
223隐藏的部分更容易改动
224现实的做法
225一些实际的考量因素
23给你的决策计时
24重载和C++
25自我查验
26小结
第3章代码未动，测试先行
31一个小舵板：测试与可测试性
32什么是测试
33可测试性和代码质量
34案例学习：可测试性
341随时应对变化
342青蛙一样的程序员
35一个关于测试先行的思考
351更好的设计
352更清晰的范围和避免不必要的工作
353降低复杂性
354其他优势
355没有例外
36小结
第4章Shalloway法则和Shalloway原则
41冗余的种类
411复制和粘贴
412“魔法”数字
413其他类型
42重新定义冗余
43其他形式的冗余
44设计模式在减少冗余时扮演的角色
45很少有开发人员花费大量的时间去“修改”代码错误
46冗余对代码质量其他方面的影响
47小结
第5章封装
51未封装的代码：对全局变量的破坏
52成员标志的封装
53自封装成员
54预防代码更改
55封装引用对象的难点
56用get()来打破封装
57对象类型的封装
58设计的封装
59各个层次的封装
510实用性建议：把困难封装起来
511小结
第6章面向接口的设计
61针对接口的设计
62接口的定义
63接口约定
64分离不同的视图
65接口的模拟实现
66让接口保持简单
67避免过早采用继承体系
68接口和抽象类
69依赖反转原则
610多态性概述
611不是每个类都需要接口
612小结
第7章验收测试驱动开发
71两种开发流程
72验收测试
73一个关于验收测试的实例
74实现验收测试
741针对用户界面的测试脚本
742测试用户界面
743XUnit测试
744验收测试框架
745四种方法间的联系
75一个练习
76如果客户不告诉你怎么做的时候，你应该怎么办
77小结
第二部分基本态度
第8章避免过度设计或设计不足
81给开发人员的箴言
82代码质量病理学
83避免过度设计或设计不足
84把复杂度和返工最小化
85永不把代码变得更糟/仅在有目的的情况下降低代码质量
86使代码容易修改，足够强大健壮，适应变化并安全可靠
87在非面向对象的代码或遗留系统里编写易于修改代码的策略
88小结
第9章持续集成
91建立源代码分支
911多版本：特殊分支
912孤立地工作：开发分支
913问题、解决方案、新的问题
92将主干内容合并回分支
93测试驱动开发与合并成本
94持续集成
95持续集成服务器
96小结
第三部分设计问题
第10章共性和可变性分析
101用动词和名词来做指南：警告，前面有危险
102真正的问题是什么
103我们所需要知道的
104共性和可变性分析
1041共性分析
1042可变性分析
1043面向对象设计“一箭三雕”
105发掘对象的新范式
106分析矩阵：一个用例学习
107小结
第11章以开放关闭原则为目标的重构
111开放关闭原则
1111从开放关闭原则引申到其他
1112开放关闭原则是一个“原则”
112重构
1121为何重构
1122负债还是投资
1123重构和遗留系统
1124以开放关闭原则为目标的重构
1125“及时”设计
113小结
第12章需求与功能接口
121迪米特法则
122耦合，可恶的耦合，还有依赖
1221耦合和可测试性
1222需求与功能
123理想的分离方案：需求接口和功能接口
124回到迪米特法则
125小结
第13章何时以及如何使用继承
131“四人组”
132初始向量，最终结果
133优先委托
134使用继承与使用委托
135继承的使用
136可扩展性
137在敏捷开发里应用四人组的训诫
138测试问题
139更多
第四部分附录
附录A统一建模语言概览
附录B代码质量
附录C封装原始数据类型