《软件设计的哲学》读后感

引言

在知乎上看到有人推荐《软件设计的哲学》，遂找来读了。或许是由于个人水平有限，虽然感觉确实不错，但是却没有推荐的那么好。

复杂度

书中的核心观点认为软件开发的关键在于控制复杂度，以便后续的维护和扩展功能。
类似的观点在《代码大全》中也有看到过——《代码大全》提到，管理软件实质上是管理复杂度。

《软件设计的哲学》认为，复杂度会导致：修改放大、增加认知负荷和“未知的未知”，这三种现象最终导致了软件的难以维护。而软件的复杂度不是一下子就变得很复杂的，而是在开发的过程中不断积累，最终导致整个软件变得越来越复杂，以至于无法维护。因此，要控制复杂度，就应该在软件的开发过程中持续的调整优化，通过良好的设计降低复杂度，使整个软件系统保持较低的复杂度。

好的设计

书中认为，好的设计应该是：

1. 接口应该尽可能的简单,通用
2. 应该尝试在不降低整体功能的前提下减少接口数量,从而创建更通用的接口
3. 系统中不同层次之间的抽象应该是不同的
4. 方法(类, 模块)应该是深的,而不是浅的(简单的接口,复杂的实现)
5. 应该避免跨多个API传递参数
6. 异常会增加接口的复杂性,有时可以通过调整接口的定义避免异常

书中列举了很多例子,如认为好的接口应该像Unix的文件IO接口那样:简单,又提供了足够的功能,并且隐藏了文件系统的细节.而认为Java提供的文件IO接口则是不好的例子.具体建议去阅读原文.

持续的重构

要使系统保持较低的复杂度需要良好的设计,但是很难在最开始就设计好软件的所有细节而不进行调整,并且也不应该这样中.要维持整个软件始终有良好的设计,应该在开发的过程中不断调整,优化软件设计.

应该采用增量迭代的开发方式,但是重点不应该只是新功能的实现,而是每次迭代中软件的抽象.

这也就意味着,每次迭代除了添加新功能和修复缺陷外,应该要审查软件的设计是否合理,是否有可以优化的地方,并且及时优化,要用战略的编程,而不是战术的编程.

同时,作者认为在前期花更多的时间在设计上能够节省下未来在开发和维护中花费的时间,从整体上而言使更有效率的.

注释,

为了让后续的开发维护的人能更好的维护代码, 需要编写良好的注释.
注释应该要描述无法从代码中直接看到的东西,而不是代码的重复,具体应该包括:

1. 接口(类, 模块)的抽象设计
2. 为什么这么写的原因
3. 更加底层的精确描述

同时注释应该尽量的靠近代码,让读者更方便找到. 不要一份注释多个副本,这会增加注释维护的难度,进而导致程序员不想写注释.

命名

接口和变量的命名应该是清晰的,无歧义的,并且在系统中表示相同含义的接口或变量应该是一致的.
保持命名的一致可以减低阅读代码时的认知负荷.

有一份编码规范是很重要的,规范的具体内容不是很重要,更重要的是要保持整个系统的命名,风格的一致性.而具体的编码规范可以在网上看到流传的很多大公司关于具体语言的编码规范.

性能优化

书中最后也提到了性能优化的问题, 并且指出: 好的设计通常也会带来好的性能

如果确实要优化性能，应该先具体的定位到导致性能问题的原因，再进行优化，而不是根据直觉进行优化
优化时可以找出该部分代码的关键路径，尝试仅实现关键路径的代码，然后再处理其他的情况