进一步谈及开发中的复杂度控制–单脑原则。
就是一个模块(无论多大的模块)的一个层级,需要至少一个大脑(一个人)对此有完全的控制,这块的复杂度才能被真正控制。
最优解作用域
如同全局规划算法,对于一个域,求它的最优解,那么就要在这个范围内去进行(使用迭代规划等等)。
如果两个人合作,各自领一半的作用域,那么得出来的解就不是这个域的最优解。
所以这里至少有一个面向整个作用域的人来求最优的程序解法,代码结构才可以的。
分级是“单体能力有限+全局最优解”的良药
这样如果一个人负担太大的模块,就难以兼顾细节,所以分级应运而生。
其出现和发挥作用的核心就在于:
- 要保持求解作用域是全局
- 将问题进行分解,然后以递归的方式去求解,每一级都保持当前的最优解
- 每一级落在单体可承受的范围内
所以从这个角度来看,扁平化组织以及编程设计面对大型问题是一个糟糕的解法,更多是硬核人类习性文化的设计。
过度层级,当然也是将问题复杂化的设计。
合作中的推荐方式
比如一个类,多个人参与,那么就推荐如此:
- 在任何一个时间里,至少有一个人,对整个类的结构实现做最终负责
- 这个人对于改动,可以从整个功能的角度,做最优解保证
- 若干良好的习惯策略会很好的提升维持模块最优解的能力
- 模块参与者但遵循良好的设计实现思路(解耦,分级,单个职责等设计原则)
- 在设计早期与负责人进行实际复杂度和设计方面的沟通,而非集中在最终的coding上
一些要避免的认知
这些认知都还不够好或者错的:
- 在没人对整体把控,一堆人认真写,也能把一个模块写好
- 模块写坏了,不是因为我,所以心里就“心安理得”了,这样都是不好的