重复的危害

系统中的每一项知识都必须具有单一、无歧义、权威的表示。（感觉翻译得怪怪的）

Tip 11 DRY - Don’t Repeat Yourself 不要重复你自己

重复是怎样发生的

  • 强加的重复（imposed duplication）：开发者觉得他们无可选择 —— 环境似乎要求重复。
  • 无意的重复（inadvertent duplication）：开发者没有意识到他们在重复信息。
  • 无耐性的重复（impatient duplication）：开发者偷懒，他们重复，因为那样似乎更容易。
  • 开发者之间的重复（interdeveloper duplication）：同一团队（或不同团队）的几个人重复了同样的信息。
强加的重复

  • 信息的多种表示

    我们也许在编写客户-服务器应用，在客户和服务器端使用了不同的语言，并且需要在两端都表示某种共有的结构。我们或许需要一个类，其属性是某个数据库表的 schema。

    解决办法是编写简单的过滤器或代码生成器。可以在每次构建（build）软件时，使用简单的代码生成器，根据公共的元数据表示构建多种语言下的结构。可以用最初用于构建 schema 的元数据，自动生成类定义。

  • 代码中的文档

    代码为什么需要注释：糟糕的代码才需要许多注释。

    DRY 法则告诉我们，要把低级的知识放在代码中，它属于那里；把注释保留给其他高级说明。否则，我们就是在重复知识，而每一次改变都意味着既要改变代码，也要改变注释。注释将不可避免地变得过时，而不可信任的注释比完全没有注释更糟。

  • 文档与代码

    你撰写文档，然后编写代码。有些东西变了，你修订文档、更新代码。文档和代码都含有同一知识表示。

    可以根据文档来生成测试。

  • 语言问题

    许多语言会在源码中强加可观的重复。如果语言使模块的接口与其实现分离，就常常会出现这样的情况。C/C++ 有头文件，在其中重复了被导出变量、函数和（C++）类的名称和类型信息。

    再思考一下头文件和实现文件中的注释。绝对没有理由在这两种文件之间重复函数或类头注释（head comment）。应该用头文件记载接口问题，用实现文件记载代码的使用者无需了解的实际细节。

无意的重复

有时，重复来自设计中的错误。

举个例子：

class Line {
	public:
		Point start;
		Point end;
		double lenght;
};

第一眼看上去这个类似乎是合理的。线段显然有起点和终点，并总是有长度的。但这里有重复，长度是由起点和终点决定的：改变其中一个，长度就会变化。最好是让长度编程计算字段：

class Line {
	public:
		Point start;
		Point end;
		double lenght() { return start.distanceTo(end); }
};
无耐性的重复

每个项目都有时间压力。

如果你觉得受到了诱惑，想一想古老的格言「欲速则不达」。你现在也许可以节省几秒钟（感觉不止），但以后可能损失几小时。（如果一个人不打算在公司长久待下去的话是会写出重复的代码的，所以 code review 要做好）

无耐性的重复是一种容易检测和处理的重复形式，但那需要你接受训练，并愿意为避免以后的痛苦而预先话一些时间。

开发者之间的重复

或许最难检测和处理的重复发生在项目的不同开发者之间。处理这个问题的最佳方式是鼓励开发者进行主动地交流。

Tip 12 Make It Easy to Reuse 让复用变得容易

你所要做的就是营造一种环境，在其中找到并复用已有的东西，比自己编写更容易。

正交性

如果你想要制作易于设计、构建、测试及扩展的系统，正交性是一个十分关键的概念。

什么是正交性

「正交性」是从几何学中借来的术语。如果两条直线相交成直角，它们就是正交的。

在计算机技术中，该术语用于表示某种不相依赖性和解耦性。如果两个或更多事物中的一个发生变化，不会影响到其他事物，这些事物就是正交的。

正交的好处

非正交系统的改变与控制更复杂是其固有的性质。当任何系统的各组件互相高度依赖时，就不在具有局部修正这样的事情。

Tip 13 Eliminate Effects Between Unrelated Things 消除无关事物之间的影响

我们想要设计自足（self-contained）的组件：独立、具有单一、良好定义的目的（内聚）。如果组件是相互隔离的，你就知道你能够改变其中之一，而不用担心其余组件。只要你不改变组件的外部接口。

  • 提高生产率
    • 改动得以局部化，所以开发实践和测试时间得以降低。编写多个相对较小的、自足的组件更为容易，你可以设计、编写简单的组间，对其进行单元测试。当你增加新代码时，无需不断改动已有的代码。
    • 正交的途径还能够促进复用。如果组间具有明确而具体的、良好定义的责任，就可以把它们和新组件整合到一起。
    • 如果你对正交的组件进行组合，生产效率会有相当微妙的提高（M x N > M * (N - i), i 为 M、N 重复内容）
  • 降低风险
    • 有问题的代码区域被隔离开来。
    • 所得的系统更健壮。
    • 政教系统很可能得到更好的测试。

项目团队

怎样把团队划分为责任得到了良好定义的小组，并使重叠降至最低呢？没有简单的答案。我们的偏好是从使基础设施与应用分离开始。每个主要的基础设施组间（数据库、通信接口、中间件层等）有自己的子团队。如果应用功能的划分显而易见，那就照此划分。然后我们考察现有的人员，并对分组进行相应的调整。

在讨论每个所需改动时需要涉及多少人。人数越多，团队的正交性就越差。

设计

对于正交设计，有一种简单的测试方法。一旦设计好组件，问问你自己：如果我显著地改变了某个特定功能背后的需求，有多少模块会受到影响？在正交系统中，大难应该是「一个」。

不要依赖你无法控制的事物属性。

工具箱与库

在你引入第三方工具箱和库时，要注意保持系统的正交性。要明智地选择技术。它是否会迫使你对代码进行不必要的改动。如果对象持久模型（object persistence scheme）是透明的，那么它就是正交的。如果它要求你以一种特殊的方式创建或访问对象，那么它就不是正交的。

正交性的另一个有趣的变体是面向切片编程（Aspect-Oriented Programming, AOP）。AOP 能让你在一个地方表达本来会分散在源码各处的某种行为。例如，日志消息通常是在源码各处、通过显式地调用某个日志函数生成的。通过 AOP，你可以把日志功能正交地实现到要进行日志记录的代码中。（Python 中的装饰器就可以实现这个功能）

编码

你可以将若干技术用于维持正交性：

  • 让你的代码保持「解耦」：编写不会没有必要地向其他模块暴露任何事情、也不依赖其他模块具体实现的模块。
  • 避免使用全局数据
  • 避免编写相似的函数：使用 Strategy（策略）模式

养成不断地批判对待自己打的代码的习惯，寻找任何重新进行组织、以改善其结构和正交性的机会。这个过程叫重构（refactoring）。

测试

正交地设计和实现的系统也更易于测试，因为系统的各组件间的交互是形式化和有限的，更多的系统测试可以在单个的模块进行。

可撤销性

如果某个想法是你唯一的想法，再没有什么比这更危险的事了。 —— Emil-Auguste Chartier

Tip 14 There Are No Final Decisions 不存在最终决策

通常，你可以把第三方产品隐藏在定义良好的抽象接口后面。

曳光弹

为了在代码中获得「曳光弹」的效果，我们要找到某种东西，让我们能快速、直观和可重复地从需求出发，满足最终系统的某个方面要求。

Tip 15 Use Tracer Bullets to Find the Target 用曳光弹找到目标

曳光弹告诉你击中的是什么，那不一定总是目标，于是你调整准心，直到完全击中目标为止，这正是要点所在。

原型与便笺

你可以为下列事物制作原型：

  • 架构
  • 已有系统中的新功能
  • 外部数据的结构或内容
  • 第三方工具或组件
  • 性能问题
  • 用户界面设计

原型制作是一种学习经验。其价值并不在于所产生的代码，而在于所学到的经验教训。那才是原型制作的要点所在。

Tip 16 Prototype to Learn 为了学习而制作原型

怎样使用原型

在构建原型时，你可以忽略哪些细节？

  • 正确性：你也许可以在适当的地方使用虚假的数据；
  • 完整性：原型也许只能在非常有限的意义上工作；
  • 健壮性：错误检查很有可能不完整。如果你偏离预定路径，原型就可能崩溃，这没有关系；
  • 风格：原型代码可能没有多少注释或文档。

因为原型应该遮盖细节，并聚焦于所考虑系统的某些具体方面，你可以用非常高级的语言实现原型。高级的脚本语言能让你推迟考虑许多细节，并且仍然能制作出可以工作的代码。

制作架构原型

一些你可以在架构原型中寻求解答的具体问题：

  • 主要组间的责任是否得到了良好的定义？是否适当？
  • 主要组间间的协作是否得到了良好的定义？
  • 耦合是否得以最小化？
  • 你能否确定重复的潜在来源？
  • 接口定义和各项约束是否可接受？
  • 每个模块在执行过程中是否能访问到其所需的数据？能够在需要时进行访问？

领域语言

Tip 17 Program Close to the Problem domain 靠近问题领域编程

无论适用于配置和控制应用程序的简单语言，还是用于指定规则或过程的更为复杂的语言，我们认为，你都应该考虑让你的项目更靠近问题领域。通过在更高的抽象层面上编码，你获得了专心解决领域问题的自由，并且可以忽略琐碎的实现细节。

估算

Tip 18 Estimate to Avoid Surprises 估算，以避免发生意外

估算来自哪里

  1. 理解提问内容：任何估算练习的第一步都是建立对提问内容的理解。除了上面讨论的精确度以外，你还需要把我问题域的范围。这常常隐含在问题中，但你需要养成在开始猜想之前先思考范围的习惯。
  2. 建立系统的模型：根据你对所提问题的理解，建立粗略、就绪的思维模型骨架。
  3. 把模型分解为组件：你需要找出描述这些组件怎样交互的数学规则。你将会发现，在典型的情况下，每个组件都有一些参数，会对它给整个模型带来什么造成影响。在这一阶段，只要确定每个参数就行了。
  4. 给每个参数指定值：一旦你分解出各个参数，你就可以逐一给每个参数赋值。在这个步骤中你可能会引入一些错误。诀窍是找出哪些参数对结果的影响最大，并致力于让它们大致正确。
  5. 计算答案：在计算阶段，你可能会得到看起来很奇怪的答案。不哟啊太快放弃它们，如果你的运算是正确的，那你对问题或模型的理解就很可能是错的。这是非常宝贵的信息。
  6. 追踪你的估算能力

估算项目进度

在面对相当大的应用开发的各种复杂问题与反复无常的情况时，普通的估算规则可能会失效。为项目确定进度表的唯一途径常常是在相同的项目上获取经验。

  • 检查需求
  • 分析风险
  • 设计、实现、继承
  • 向用户确认

Tip 19 Iterate the Schedule with the Code 通过代码对进度表进行迭代

总结

第二章其实更多的再讲团队和产品设计方面的问题，自己在这两方面并没有什么经验。不过 DRY 和正交性的概念还是比较重要的。