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

　　复杂度的要点

　　复杂度的要点所在就是程序给大脑带来的负担，它等同于程序员提升和开发程序的难易程度，这个负担随着模块的复杂度大约是平方级数增长。
　　如果负担很低，那么一段程序的就容易控制，程序员就容易提升程序的质量（包括开发效率，运行稳定性和运行效率）。
　　所以我们也不需要在任何时候任何情况去做复杂度的最小化，如果一个模块本身规模很小，那么就不需要花很多精力去做进一步简化（当然处于自我提升和精益求精的本能，在时间允许的情况下，做这个当然好的了）
　　同时低复杂度度也不等同于最少行数的代码，而是给大脑带来最少负担的代码，比如后文举得代码例子，虽然另外一种写法代码行数更多，但是由于它符合一个更稳定的模式，所以在大脑负担和心理负担都更轻，它可以认为是更低复杂度的代码。

　　复杂度控制的实际意义

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

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

　　运行效率
　　处理效率，常规的基本做法是profile热点，以及根据游戏的情况进行feature的关闭。
　　但是这个能做的事情是非常有限的，如果想做进一步提升性能，接近性能的极限，必须要做的就是：
　　- 对于每一个模块有充分的理解
　　- 可以做到快速的反复尝试迭代
　　处理性能热点，在优化早期是一个非常高效的做法，准确来讲，热点处理是”在有水分的情况下，高效提升性能“的方法。
　　但是在追求极限性能方面，热点优化还是不够，某一个模块的性能消耗是不是超过了它应该有的，以及一个排名10名开外的模块其实是不需要高频运行的等等，这些都是热点处理不能解决的。
　　在对于程序有充分了解，就可以进行更彻底的调整，把大量的运行做并行，低频执行或者直接优化掉。
　　实践中看下来，这样的处理会把程序的性能带到一个新的台阶。
　　这个道理可以说是知易行难，难就难在，对一个超大系统（比如对于《天涯明月刀》来说，就是整个客户端，覆盖几十万行的代码），如何做到充分理解，如何做到容易的彻底的修改优化。
　　所以关键点又回到复杂度，只有程序的复杂度得到最好的控制，才能较好的做这个工作。
　　这个后来在实践中，优化过程中，大约一半时间是在做代码的调整和重构，代码合理就会让优化更加的可行和高效。

　　复杂度控制的方法与实践

　　实践下来，复杂度控制的能力在我看来可以从三个方面来拆解：渴望，目标与时间积累。

　　渴望：
　　首先最有效的方式就是去承担实际的，要覆盖非常大范畴的开发任务，这种情况下，你就会对于复杂度有切肤之痛，你就会非常真切的了解到复杂度是什么，什么是重要的，让你抓狂的，什么只是虚张声势，无足轻重的，有了非常充分的渴望，那么后面的积累和实践就容易多了。

　　目标：
　　方法和实践会是非常的多，但是目标却简单很多，就是能够始终保持对于整个系统，在代码级别非常的清晰。在开发设计和做决定的时候，能有心如止水般的顺畅即可。所以一定程度上，可以说复杂度控制还是比较主观的，也很看火候的。比如有时候项目本来就比较小，即便复杂度控制不是很好，但是也非常的清晰，hold住，那就可以把更多的精力放在其他方面。

　　方法：
　　个人实践中，这几个方面可以注意下：
　　- 任务切分+代码整理：在较小型的任务结束的时候，就开始做小规模的代码整理，始终保持代码是干净的
　　- 模式+自然：积累更多的模式，比如一大片的代码，其实就是做了pool的事情，那么这一大片的复杂度就是一个词：pool。让所有的东西都更加自然，符合编程的优秀实践，这样需要你记和注意的东西就很少，那么它就是一个很低的复杂度。
　　比如下面这个代码：

int a[5];　　
for(int i=0; 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 　　
{　　
     printf("%d",a）;
}

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

　　复杂度控制的“敌人”
　　没有意识到“复杂度”的重要性
　　遇到不少程序员（甚至是大部分）对于复杂度无感，把一些算法和效率因素重要性远远放在复杂度之上，甚至是以写出很复杂的程序为荣。这一块不是很容易沟通，只有实际去承担大量的程序实现，对复杂度有切肤之痛的情况，才能有一个真实的认识。
　　还有就是没有及时和项目组沟通，争取足够的时间来处理复杂度问题以及清理代码，相当多的程序员都不会对复杂度有充分的认识，那么要求项目经理有足够的认识在我看来不太合理。基本上较有可行性的方法是程序员给予足够的沟通，以及在实现估时上留有充分的余量，而如果出现没有意识到，没有沟通充分，甚至是为了取悦manager而无视复杂度，疯狂追求实现时间的情况，这都太糟糕了。

　　进度问题
　　时间紧任务重的情况，这个前面已经提过了，但是实际项目中还是会反复出现，这块其实是可以是一个大的话题。
　　首先每个程序员需要建立一个代码实现的profile机制–我个人一直使用worklog，然后对于自己的开发效率有一个跟踪，这样才能知道哪种方法是正确的更快的。磨刀什么情况下才不误砍材工，profile了才知道。
　　根据具体情况采取具体的策略，个人经验下，相当的情况都是一边实现一边整理是更快的。
　　编程基本功，就是快速稳定的实现了，这个需要长期的有意识的积累。

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