读《对抗软件复杂度的战争》 有感而发
为什么软件必然会变得越来越复杂
熵增定律：孤立系统总是趋向于熵增，最终达到熵的最大状态。但是，对开放系统而言，由于它可以将内部能量交换产生的熵增通过向环境释放热量的方式转移，所以开放系统有可能趋向熵减而达到有序状态。
一个软件系统也可以看作是一个孤立系统，它的复杂度的不断提升实质上就对应了系统的熵增过程，而这是不可逆且必然的。因此，我们能做的是尽力的减慢这种变复杂的趋势。在对抗这种趋势之前，对问题进行本质上的拆解是很有意义的：
全局复杂度 = 本质复杂度 + 偶然复杂度
如何尽量减缓这种变复杂的趋势
引入复杂的来源
原文中的阐述，引入复杂性的来源有4个：
- 本质复杂度
- 业务复杂度的增长
- 偶然复杂度
- 系统问题：分布式系统规模的增长
- 人的问题：团队规模的增长
- 人的问题：关键干系人目标的因素
哪些可以抗争？哪些只能躺平？
其中本质复杂度来自问题空间，是无法简化的。这部分可以躺平。
而偶然复杂度来自方案空间，是可以通过人为的努力去简化，甚至消除的。最理想的情况是偶然复杂度为0。
对于能抗争的来源，怎么抗争？
针对系统问题，分三个层次的解决方案。
- 微观：控制逻辑正交+有效的高质量的单元测试
- 中观：系统架构梳理和维护。
- 康威定律说：“任何系统设计的系统，其系统结构会复制组织的沟通结构。”
- 所以系统架构和组织，也就是人的问题有关。
- 宏观：正确的技术战略，把分布式系统的复杂度外包（阿里、AWS、Azure、谷歌）
针对人的问题
任何一个组织、部门作为一个“生命体”都有扩大自身的欲望和趋势。 一旦扩大到一定规模，就不受任何一个个人完全控制了。这是内禀的。
因此，我认为解决人的问题的方案只有控制人数，提高质量这一条路径。（没错，真正的解决方案就是这么简单直接）
扩展思考
既然孤立系统必然熵增，那是否可以考虑把软件系统变成一个开放系统呢？通过热交换，维持自身的有序？这意味着持续的“能量”输入（Code Review？架构宣导？新人加入？）
