复杂度控制--单脑原则

进一步谈及开发中的复杂度控制–单脑原则。
就是一个模块（无论多大的模块）的一个层级，需要至少一个大脑（一个人）对此有完全的控制，这块的复杂度才能被真正控制。

最优解作用域

如同全局规划算法，对于一个域，求它的最优解，那么就要在这个范围内去进行（使用迭代规划等等）。
如果两个人合作，各自领一半的作用域，那么得出来的解就不是这个域的最优解。
所以这里至少有一个面向整个作用域的人来求最优的程序解法，代码结构才可以的。

分级是“单体能力有限+全局最优解”的良药

这样如果一个人负担太大的模块，就难以兼顾细节，所以分级应运而生。
其出现和发挥作用的核心就在于：

1. 要保持求解作用域是全局
2. 将问题进行分解，然后以递归的方式去求解，每一级都保持当前的最优解
3. 每一级落在单体可承受的范围内
   所以从这个角度来看，扁平化组织以及编程设计面对大型问题是一个糟糕的解法，更多是硬核人类习性文化的设计。
   过度层级，当然也是将问题复杂化的设计。

合作中的推荐方式

比如一个类，多个人参与，那么就推荐如此：

• 在任何一个时间里，至少有一个人，对整个类的结构实现做最终负责
  • 这个人对于改动，可以从整个功能的角度，做最优解保证
• 若干良好的习惯策略会很好的提升维持模块最优解的能力
  • 模块参与者但遵循良好的设计实现思路（解耦，分级，单个职责等设计原则）
  • 在设计早期与负责人进行实际复杂度和设计方面的沟通，而非集中在最终的coding上

一些要避免的认知

这些认知都还不够好或者错的：

• 在没人对整体把控，一堆人认真写，也能把一个模块写好
• 模块写坏了，不是因为我，所以心里就“心安理得”了，这样都是不好的