简约之美：软件设计之道

D表示这个变化的合意程度（可取程度）。我们对此项工作的需求有多么迫切？

V表示它的价值。该变化价值几何？一般来说，你可以问自己“这个变化对用户有多少用”；当然，还有很多其他方法来判断其价值。

E表示完成这个变化的成本，也就是完成它需要付出的代价。

另外这个公式没有写到维护，后面章节会做补充。

不要编写不是必需的代码，并且要删除没有用到的代码。

注 teawater: 即使觉得以后可能会有用也要将其删除掉，删除掉的代码可以保存在版本控制里或者其他地方。

僵化设计有两大原因：

更好的办法是每次只确定一个或者少数几个需求，然后立刻让开发人员实现它。在开发过程中，用户可以扮演开发人员的角色，反复进行沟通。上次确定的功能实现并发布之后，就可以继续处理其他的功能。这样，最终得到的系统是设计良好的，完全满足用户需求的。
注 teawater: 对未来做太多假设的解决方法。

设计程序时，应当根据你现在确切知道的需求，而不是你认为未来会出现的需求。

注 teawater: 这里和后面三点都是过度工程引起的问题。

注 teawater: 过度工程的解决方法。

这个办法很容易举例来说明。假如需要开发可以计算加减乘除的计算器程序。
（1）设计一个只能进行加法运算的系统。
（2）实现它。
（3）修改现有设计，很容易就可以支持减法运算。
（4）实现减法运算。现在，系统只能进行加、减运算。
（5）再次修改现有系统的设计，很容易就可以支持乘法运算。
（6）实现乘法运算功能。现在的系统可以支持加、减、乘运算了。
（7）再次修改系统的设计，添加除法运算（现在做这一步应该不需要花多少功夫了，因为我们早就改进了设计，添加过减法、乘法）。
（8）实现除法功能。这时候得到的就是一开始期望构建的完整系统，而且拥有满足需求的良好设计。

永远不要“修正”任何东西，除非它真的有问题，而且有证据表明问题确实存在。

如果你收到很多这样的请求，就说明用户很难在你的程序里找到自己想要的功能。这才是真正要改进的地方。
注 teawater: 如果收到很多要加入已经存在功能的要求。

有时候用户会报告某个bug，但程序其实是完全按照预期来运行的。果真如此，就应当少数服从多数。如果相当多的用户认为某个行为是bug，它就是bug；如果只是少数用户（比如一两个）认为它是bug，那么它就不算bug。
注 teawater: 这里不是软件bug而是对行为的意见，作者建议少数服从多数，不过如何知道是多数用户想修改这个行为呢？这是个问题。

在这类问题上，最有名的错误就是所谓的“提前优化”。

动手解决之前，真正拿到证据，证明问题确实存在。

理想情况下，任何系统里的任何信息，都应当只存在一次。

编程也是这样——缺乏一致性，只会一团糟。有了一致性，世界就很简单。

即便你做不到那么简单，至少也要做到：一旦你理解了某种复杂性，就不必再进行重复劳动。

要把各部分拆分开来，就必须留出空白。

7.5.1　命名

7.5.2　注释

注 teawater: 本节是心灵硫酸。

8.1　复杂性与软件的用途

相比众多平庸的开发人员，少量精干的开发人员更容易获得成功。

出现复杂性的另一个常见原因就是，系统里选择了错误的技术，尤其是最终发现并不能很好适应未来需求的技术。

程序员不理解自己的工作，就容易设计出复杂的系统。

一般来说，它指的是“没有为变化做计划”。万物都是会变化的，项目增长时，设计仍然要维持简单。

你必须一开始就做好设计，而且在系统膨胀时不断进行优秀的设计；否则，复杂性就会迅速增长，因为如果设计得不好，每项功能都会让代码加倍复杂，而不是只复杂一点点。

只有在满足以下任何一个条件的前提下，重新发明轮子才有价值：

真正要解决的问题是什么？

8.4 复杂问题

8.5　应对复杂性

8.6　推倒重来