软件开发复杂性解决作者之见

概述

本书2020年炒的太热，是一本好书，但是书中几乎没有提出什么新的思想以及新的方法。可以理解为作者对软件研发的一份个人思考总结。

本书主要围绕软件开发的复杂性来展开，如何定义复杂性？如何识别复杂性？如何降低软件的复杂性？

系统的总体复杂度是由每个部分的复杂度乘以开发人员在该部分上花费的时间总和。而复杂性的症状主要体现在三个方面：一个是在做修改的时候工作量很大，另外一个就是代码阅读认知很困难，最后一个就是修改让开发者者恐慌，不知道会导致什么问题。而对于复杂性的原因，则是依赖性和模糊性导致的。另外，复杂性并不是突然出现的，而是经过日积月累的技术债务累计而产生的，只关注功能，不经过思考，没有设计是复杂性产生的过程。

核心的设计建议

1. 复杂性是逐步增加的：需要适当进行设计（请参阅第 11 页）。
2. 能跑起来的代码是不够的，不能始终只以快速上线为目的，需要进行投入少量时间设计，也就是战略变成，战略性编程需要一种投资心态。（请参阅第 14 页）。
3. 系统需要进行模块化，在设计模块的时候最优的是深模块，深模块的定义是更多的逻辑封装，更少、更简单的的接口（请参见第 22 页）
4. 接口的设计应更多考虑调用方的感受，以最少知识原则进行封装，能提供自动化提供自动化，能提供默认值提供默认值，不要将非常用功能暴露成通用接口（请参阅第 27 页）。
5. 一个模块具有一个简单的接口比一个简单的实现更重要（请参阅第 55、71 页）。
6. 以稍微通用的方式实现新模块，这样可以取得需求的不确定性与扩展性的平衡（请参阅第 39 页）。
7. 通用代码和专用代码分离，避免交叉影响（请参见第 62 页）。
8. 分层是降低复杂度的通用方法，另外注意不同的层应具有不同的抽象维度，抽象以功能、领域的方式进行抽象，而不是以操作流程、顺序的方式抽象（请参见第 45 页）。
9. 在开发模块时，需要寻找机会较少自己的复杂性，同时较少用户复杂性（请参阅第 55 页）。
10. 减少强制异常数量，简化异常处理（请参阅第 79 页）。
11. 设计两个以上的方案，而后评估方案的优劣势，最终确定（请参阅第 91 页）。
12. 注释应描述代码中不够直白的逻辑（请参见第 101 页）。
13. 代码除了正确运行，更重要的是给人读的，所以易读性比编码方便更重要（请参见第 149 页）。
14. 软件开发的增量开发容易导致战术编程，所以要谨记增量应该是面向设计而不是仅仅是功能（请参见第 154 页）。