程序的核心--复杂度

在《the art of unix programming》中，复杂度的控制被看的非常的重，里面一句话提到编程项目的核心就是对于复杂度的控制，以及simple原则其实也在讲这个事情。
我自己在08年也写了关于这个的话题：http://blog.csdn.net/toughbro/article/details/2679254
7年过去了，也经历了《天涯明月刀》这样的重型项目的磨练，也有了更多的认识。

复杂度控制的实际意义
先从实用的角度来看：关乎运行效率和开发效率（当然其他的扩展性等等也会包括，但是实际在项目里的感受是这两个尤其的明显）。
其实7年前我也是毫无疑问的这么认为的，但是实践起来并不是一码事情，大约几年前，才真正的形成开发的原则。
开发效率

这个最深刻的认识原则当初开发地形系统，包括从编辑器的底层部分（UI部分是另外一个同事做的）以及runtime部分，从材质到高度图，系统庞大而且复杂。
开发过程中，也不可避免的遭遇到需求变动（包括材质系统的能力，地图大小这种非常颠覆性的）。
时间紧任务重，一直想尽量快点把东西做好，开发过程中，代码整理和系统整体控制没有做太多，然后其他组可以同步进行，然后再进行代码整理。
但是对于一个庞大的系统，这种策略就不好。
写程序的时候，质量和效率最好的情况就是始终对于整个系统，在代码级别保持一个非常清晰的状态，你心里知道要写成什么样，写的过程，整体的代码也清晰合理，与你心里的样子相印证，然后可以心如止水的一直非常快的写，整个过程非常的享受。
而如果实现过程中，缺乏对于系统良好的认识和整理，希望“随便搞搞，搞出来再整理“，这种在小型情况下是ok的，但是大型系统下，即便思维保持清晰，但是庞大的系统缺乏整理，而造成非常的复杂，很多东西由于前后设计的不一致，导致是处于一个不合理的复杂情况–需要你去死记。
这样造成的结果就是，即便你对于整体系统的设计非常的清晰，但是在编程过程中，由于系统的一定的混乱，让你没法整个过程非常清晰的，心如止水的进行，整个的过程，磕磕绊绊，让人疲惫不堪。
所以在后半段，就停下来改变了策略，先做充分的整理，把不需要的部分去除，然后把代码整理到完全准备好来做新代码的实现，才去做新的实现，这样反而是最快的，写起来也愉快迅捷。
运行效率

处理效率，常规的基本做法是profile热点，以及根据游戏的情况进行feature的关闭。
但是这个能做的事情是非常有限的，如果想做进一步提升性能，接近性能的极限，必须要做的就是：
- 对于每一个模块有充分的理解
- 可以做到快速的反复尝试迭代
处理性能热点，在优化早期是一个非常高效的做法，准确来讲，热点处理是”在有水分的情况下，高效提升性能“的方法。
但是在追求极限性能方面，热点优化还是不够，某一个模块的性能消耗是不是超过了它应该有的，以及一个排名10名开外的模块其实是不需要高频运行的等等，这些都是热点处理不能解决的。
在对于程序有充分了解，就可以进行更彻底的调整，把大量的运行做并行，低频执行或者直接优化掉。
实践中看下来，这样的处理会把程序的性能带到一个新的台阶。

这个道理可以说是知易行难，难就难在，对一个超大系统（比如对于《天涯明月刀》来说，就是整个客户端，覆盖几十万行的代码），如何做到充分理解，如何做到容易的彻底的修改优化。

所以关键点又回到复杂度，只有程序的复杂度得到最好的控制，才能较好的做这个工作。
这个后来在实践中，优化过程中，大约一半时间是在做代码的调整和重构，代码合理就会让优化更加的可行和高效。

复杂度控制的方法与实践
实践下来，复杂度控制的能力在我看来可以从三个方面来拆解：渴望，目标与时间积累。
渴望：
首先最有效的方式就是去承担实际的，要覆盖非常大范畴的开发任务，这种情况下，你就会对于复杂度有切肤之痛，你就会非常真切的了解到复杂度是什么，什么是重要的，让你抓狂的，什么只是虚张声势，无足轻重的，有了非常充分的渴望，那么后面的积累和实践就容易多了。
目标：
方法和实践会是非常的多，但是目标却简单很多，就是能够始终保持对于整个系统，在代码级别非常的清晰。在开发设计和做决定的时候，能有心如止水般的顺畅即可。所以一定程度上，可以说复杂度控制还是比较主观的，也很看火候的。比如有时候项目本来就比较小，即便复杂度控制不是很好，但是也非常的清晰，hold住，那就可以把更多的精力放在其他方面。
方法：
个人实践中，这几个方面可以注意下：
- 任务切分+代码整理：在较小型的任务结束的时候，就开始做小规模的代码整理，始终保持代码是干净的
- 模式+自然：积累更多的模式，比如一大片的代码，其实就是做了pool的事情，那么这一大片的复杂度就是一个词：pool。让所有的东西都更加自然，符合编程的优秀实践，这样需要你记和注意的东西就很少，那么它就是一个很低的复杂度。
比如下面这个代码：

int a[5];
for(int i=0; i<5; i++)
{
    printf("%d",a[5]);
}

这个在实际程序中就不是一个好的实践，在看到这片代码的时候，应该本能的注意到a[5]如果它的大小变化了怎么办，就会出现for的访问越界的可能。

#define ARRAY_NUM(a) (sizeof(a)/sizeof(a[0]))
int a[5];
for(int i=0; i<ARRAY_NUM(a);i++)
{
     printf("%d",a[i]);
}

那么再次看到这样的代码的时候，就会比较放心，一路就过去了，那么这个就可以认为是复杂度比较低的（需要注意的或者刻意要记的东西少）。
所以保持一个总结积累就变得非常重要，对于编程模式或者算法越来越多的积累，那么在开发和思考的时候，就可以以更高的维度去做，那么对于压缩复杂度，提升思维速度和质量就非常的重要了。
并且，在这个层面上看，尽量返璞归真的编程风格是一个更加有力的编程风格。

good for the programmer’s soul

“Low-level programming is good for the programmer’s soul.” - John Carmack

对于卡神的这句话，无比的赞同，做底层代码实现，对硬件和系统有透彻的理解，对于程序员去清晰的理解整个程序如何运行的至关重要，你就会更好的以底层的思维去思考。
同样的道理，也可以用于高层的复杂度控制上面，更多的优秀的编程实践，更好的理解要做的事情，理解系统本身，最后达到一个最简洁的实现，整个设计和实现的过程，可以让人进入心如止水的状态，同样的”good for the programmer’s soul“