简约之美:软件设计之道

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 推倒重来