提示11：
DRY - Don't Repeat Yourself
不要重复你自己
不管原因是什么，维护都不是时有时无的活动，而是整个开发过程中的例行事务。当我们进行维护时，我们必须找到并改变事物的表示——那些嵌在应用中的知识胶囊。问题是，在我们开发的规范、过程和程序中很容易重复表述知识，而当我们这样做时，我们时在向维护的噩梦发出邀请——在应用发布之前就会开始的噩梦。可靠的软件开发、并让我们的开发更易于理解和维护的惟一途径，是遵循我们称之为DRY的原则：
系统中的每一项知识都必须具有单一、无歧义、权威的表示。
与此不同的做法是在两个或更多地方表达同一事物。如果你改变其中一处，你必须记得改变其他各处。这不是你是否能记住的问题，而是你何时忘记的问题。
代码为什么需要注释，代码应该是具有高可读性的，糟糕的代码才需要许多注释。
DRY法则告诉我们，要把低级的知识放在代码中，它属于那里；把注释保留给其他的高级说明。否则，我们就是在重复知识，而每一次改变都意味着既要改变代码，又要改变注释。注释将不可避免地变得过时，而不可信任的注释比完全没有注释更糟。
你可能因为性能原因而选择违反DRY原则。这经常会发生在你需要缓存数据，以避免重复昂贵的操作时。其诀窍时使影响局部化。对DRY原则的违反没有暴露给外界。
提示12：
Make it easy to reuse
让复用变得容易
你所要做的是营造一种环境，在其中要找到并复用已有的东西，比自己编写更容易。
提示13：
Eliminate Effects Between Unrelated Things
消除无关事物之间的影响
在计算技术中，正交性用于表示某种不相依赖性或是解耦性。如果两个或更多事物中的一个发生变化，不会影响其他事物，这些事物就是正交的。
我们想要设计自足的组件：独立，具有单一、良好定义的目的。如果组件是相互隔离的，你就能够改变其中之一，而不用担心其他组件。只要你不改变组件的外部接口，就不会造成波及整个系统的问题。如果你编写正交的系统，就会得到两个好处：提高生产率和降低风险。
提高生产率：
- 改动得以局部化，所以开发时间和测试时间得以降低；
- 正交的途径还能够促进复用；
- 如果对正交的组件进行组合，生产率就会相当微妙的提高。
降低风险：
- 有问题的代码区域被隔离开来；
- 系统更健壮；
- 正交系统很可能得到更好的测试；
- 不会与特定的供应商、产品、或是平台绑定在一起。
系统应该由一组相互协作的模块组成，每个模块都实现不依赖于其他模块的功能。不要依赖无法控制的事物属性。
每当编写代码时，都有降低应用正交性的风险。除非不仅时刻监视正在做的事情，也时刻监视应用的更大的语境。否则，你就有可能无意中重复其他模块的功能，或是两次表示已有的知识。
可以使用若干技术维持正交性：
- 让代码保持解耦；
- 避免使用全局数据；
- 避免编写相似的函数。
养成不断地批判对待自己的代码的习惯。寻找任何重新进行组织、以改善其结构和正交的机会。这个过程叫做重构（refactoring）
正交地设计和实现的系统也更易于测试，因为系统的各组件间的交互是形式化的和有限的，更多的系统测试可以在单个的模块级进行。这是好消息，因为与集成测试相比，模块级（或单元）测试要更容易规定和进行得多。构建单元测试本身时对正交性的一项有趣测试。修改bug也是评估整个系统的正交性的好时候。
提示14：
There are no final decisions
不存在最终决策
我们不必做出许多关键的、不可逆转的决策。我们并非总能再一开始就做出最好的决策。错误在于假定决策是浇铸再石头上的——同时还在于没有为可能出现的意外事件做准备。要不决策视为写在沙滩上的，而不要把它们刻在石头上。
如果让决策保持柔和柔韧，事情就完全不困难。如果在代码中有着糟糕的封装、高度耦合以及硬编码的逻辑或参数，事情也许就是不可能的。
对于第三方产品，要将其隐藏在定义良好的抽象接口后面。
无论使用的是何种机制，让它可撤销。
提示15：
Use tracer bullets to find the target
使用曳光弹找到目标
经典的做法是把系统定死。制作大量文档，逐一列出每项需求、确定所有未知因素、并限定环境。然而，注重实效的程序员往往更喜欢使用曳光弹。
为了在代码中获得同样的效果，我们要找到某种东西，让我们能快速、直观和可重复地从需求出发，满足最终系统的某个方面的要求。
曳光弹并非用过就扔的代码：你编写它，是为了保留它。它含有任何一段产品代码都拥有的完整的错误检测、结构、文档、已经自查。它只不过功能不全而已。
曳光开发与项目永不会结束的理念是一致的：总有改动需要完成，总有功能需要增加。这是一个渐进的过程。
曳光弹并非总能击中目标，但曳光弹能告诉你击中的是什么。那不一定是目标。于是你调整准星，直到完全击中目标为止。这正是要点所在。小段代码的惯性也小——要改变它更容易、更迅速。你能够搜集关于你的应用的反馈，而且与其他任何方法相比，你够能花费较小代价、更为迅速地生成新的、更为准确的版本。同时，因为每个主要的应用组件都已表现在你的曳光代码中，用户可以确信，他们所看到的东西具有现实基础，不仅仅是纸上的规范。
曳光代码 VS. 原型制作
使用原型，你是要探究最终系统的某些具体的方面。使用真正的原型，再对概念进行了实验之后，你会把你捆扎在一起的无论什么东西扔掉，并根据你学到的经验教训重新适当地进行编码。 原型制作生成用过就扔的代码。曳光代码虽然简约，但却是完整的，并且构成了最终系统的骨架的一部分。你可以把原型制作视为在第一发曳光弹发射之前进行的侦查和情报搜集工作。
提示16：
Prototype to learn
为了学习而制作原型
我们以同样的方式构建软件原型，并且原因也一样——为了分析和揭示风险，并以大大降低的代价、为修正提供机会。我们可以把原型用于测试项目的一个或多个方面。
原型的设计目的就是回答一些问题，所以与投入使用的产品应用相比，它们的开发要便宜得多、快捷得多。
应该制作原型的事物：任何带有风险的事物，以前没有试过的事物，或是对于最终系统极端关键的事物，任何未被证明的、实验性的、或有疑问的事物，任何让你觉得不舒服的事物。
原型制作是一种学校经验。其价值并在于所产生的代码，而在于所学到的经验教训。那才是原型制作的要点所在。
制作原型可以忽略哪些细节：
- 正确性
- 完整性
- 健壮性
- 风格
因为原型应该遮盖细节，并聚焦于所考虑系统的某些具体方面，你可以用非常高级的语言实现原型。事实上，要制作架构原型，你甚至不一定需要进行编码——可以使用便签或索引卡片、在白版上制作原型。你寻找的是了解系统怎样结合成为一个整体，并推迟考虑细节。
在你着手制作任何基于代码的原型之前，先确认每个人都理解你正在编写用过就扔的代码。这些代码是用过就扔的，它们不完整，也不可能完整。如果你觉得在你所在的环境或文化中，原型代码的目的很有可能被误解，你也许最好还是采用曳光弹方法。你最后将得到一个坚实的框架，为将来的开发奠定基础。
提示17：
Program close to the problem domain
靠近问题领域编程
计算机语言会影响你思考问题的方式、以及你看待交流的方式。与此相反——我们认为这更重要——问题领域的语言也可能会提示出编程方案。我们总是设法使用应用领域的语汇来编写代码。在某些情况下，我们可以更进一层，拆用领域的语汇、语法、语义——语言——实际进行编程。
你都应该考虑让你的项目更靠近问题领域。通过在更高的抽象层面编程，你获得了专心解决领域问题的自由，并且忽略琐碎的实现细节。
提示18：
Estimate to avoid surprises
估算，以避免发生意外
在某种程度上，所有的解答都是估算。要选择能反映你想要传达的精确度的单位。所有的估算都以问题的模型为基础。去问已经做过这件事情的人。在你一头钻进建模之前，仔细在周围找找也曾处在类似情况下的人。任何估算练习的第一步都是建立对提问内容的理解。还需要把握问题域的范围，需要养成在开始猜想之前先思考范围的习惯。
根据你对所提问题的理解，建立粗略、就绪的思维模型骨架。对于一个项目，模型可以是你的组织在开发过程中所用的步骤、以及系统的实现方式的非常粗略的图景。一旦拥有了模型，你可以把它分解为组件。
提示19：
Iterate the schedule with the code
通过代码对进度表进行迭代
了解团队、团队的生产率、还有环境将决定进度。