第二章 务实的方法

本章介绍适用于软件开发的公理，帮你更好更快地写出健壮、可读性好的代码。

「优秀设计的精髓」是软件开发的核心主题。
「DRY-邪恶的重复和正交性」提醒你不要在系统重复知识、不要把同一块知识切分到多个组件中。
「可逆性」介绍一些有助于把项目从所在的千变万化的环境中隔离出来的技术。
「曳光弹」讨论一种开发风格，允许你在同一时间收集需求、测试设计和实现代码。
「原型与便签」告诉你怎么用原型来测试架构、算法、接口及想法。
「领域语言」给出了应对高级设计语言的建议。
「评估」中教你如何克服时间资源有限又想让老板高兴的矛盾。

1. 优秀设计的精髓

优秀的设计总是比糟糕的设计更容易变更。

能适应使用者的就是好的设计，简言之就是要顺应变化。因此要信奉ETC原则。

解耦、单一职责、命名无一不是为了让变更更容易。

ETC（easier to change）是一种价值观念，不是一条规则。

你需要一周左右的时间来有意识地问自己：我刚做的事情是让系统更容易改变还是更难改变？

可以在编辑器保存的时候自动弹出一个提示，督促你写的代码是否更容易变更。

2. DRY-邪恶的重复

知识并不稳定，通常改变的频率还很高。一旦我们开始在规范、流程、程序中复制知识，想要找到并并且变更事物的表达，就会是噩梦的开始。

要让心开发项目更容易理解和维护，唯一的办法就是：遵循DRY原则。

在一个系统中，每一处知识都必须单一、明确、权威地表达。

DRY不限于编码

源码知识很小的一部分，DRY针对的是你对知识和意图的复制。下面是一些场景

1. 当你在一处修改代码时，多个地方需要进行同样的变更；
2. 当你修改代码时，文档也要进行修改，这里要质疑更好的代码结构（包含变量命名）是否是更好的选择；
3. 当你修改数据库schema，也要变更代码中相关的数据结构；
4. 当你定义数据结构，一个属性是否依赖另外一个属性，是否提供了访问器来读写函数
5. 当开发人员相互拷贝或重复实现逻辑时

数据的例子

class Line {
  Point start;
  Point end;
  double length;
}

如果使用Line的地方，需要自己基于start和end进行计算，那就是知识的重复，合理的做法是，Line将length提供为访问函数：无论什么时候，只要模块暴露出数据姐㷣股，就意味着所有事你用这个数据结构点代码都和这个模块的实现产生了耦合，但凡有可能，都应该采用一组防蚊器韩束来读写对象都属性。未来需要增加功能，能让事情变得更容易。

表征的重复

借助于工具的力量，此块更多是后端的领域，提到了OpenAPI可以了解下。

开发人员的重复

最好的办法是鼓励开发人员之间积极频繁地交流：

• 日常Scrum晨会
• 开一个论坛讨论常见问题
• 指定知识管理员，促进知识传播
• 重视阅读其他人的源码和文档

创造出环境

你努力的方向是，孕育出一个更容易找到和复用已有事物的环境，而不是重新编写。

如果你未能复用，就有重复知识的风险；如果复用不易，人们就不会这么做。

3. 正交性

正交是集合学中的术语，在计算科学中象征着独立性或解耦。

对于两个或多个事物，其中一个改变不影响其他任何一个，则这些事物是正交的。

正交的好处是：提高生产力、降低风险。

如果一个功能背后的需求发生变化，多少模块会受影响。将那些可能发生变化的、无法控制的东西抽象出来。

在编码中一些具体的建议是

• 保持代码节藕，不会向其他模块透露任何不必要的信息，也不依赖其他模块的实现
• 避免全局数据
• 避免相似的函数（可能在开头和结尾共享了相似代码）

如果单元测试需要其他大部分代码，证明发现了一个与其他部分没有很好节藕的模块。

修复bug的时候也可以评估修复行为影响了多少模块，如果分散在系统各处，可以进行分析。

4. 可逆性

没有什么是永恒不变的 - 如果你严重依赖某些事实，几乎可以肯定将来其会发生变化。

如果你坚持第131页的解耦、170页的外部配置这些原则，就不比做太多不可逆转的关键决定。

相关部分：

• 28页 优秀设计的精髓
• 40页 正交性
• 88页 解耦
• 131页 版本控制
• 252页 需求之坑
• 281页 务实的入门套件