浅谈程序的核心复杂度.docVIP

浅谈程序的核心——S杂度 在《The art of unix programming》屮，复杂度的控制被看的非常的重，里面 一川话提到编程项目的核心就是对于复杂度的控制，以及simple原则其实也在 讲这个事情。 我自己在08年也写了关于这个的话题：复杂度与＞」惯。7年过去了，也经历了 《天涯明月刀》这样的重型项目的磨练，也宥了更多的认识。 复杂度的要点 复杂度的要点所在就是程序给大脑带来的负担，它等同于程序员提升和开发程序 的难易程度，这个负枳随着模块的复杂度大约是平方级数增长。 如果负扪很低，那么一段程序的就容易控制，程序员就容易提升程序的质量（包 括开发效率，运行稳定性和运行效率）。 所以我们也不需耍在任何时候任何情况去做复杂度的最小化，如果一个模块本身 规模很小，那么就不需要花很多精力去做进一步简化（当然处于自我提升和精益 求精的木能，在吋间允许的情况下，做这个当然好的了） 同时低复杂度度也不等同于最少行数的代码，而是给人脑带來最少负担的代码， 比如后文举得代码例子，虽然另外一种写法代码行数更多，但是由于它符合一个 更稳定的模式，所以在大脑负担和心理负担都更轻，它可以认为足更低复杂度的 代码。 复杂度控制的实际意义 先从实用的角度来看：关乎运行效率和开发效率（当然其他的扩展性等等也会包 拈，但是实际在项目里的感受是这两个尤其的明显）。 其实7年前我也是毫无疑问的这么认为的，但是实践起来并不是一码事情，大约 几年前，才真正的形成开发的原则。 开发效率 这个最深刻的认识原则当初开发地形系统，包括从编辑器的底层部分（UI部分 是另外一个同事做的）以及runtime部分，从材质到高度图，系统庞大而且复杂。 开发过程中，也不可避免的遭遇到需求变动（包拈材质系统的能力，地图大小这 种非常颠覆性的）。 吋间紧任务蜇，一直想尽量快点把东西做好，开发过程中，代码整理和系统整体 控制没宥做太多，然?其他组可以同步进行，然?再进行代码整理。 但是对于一个庞大的系统，这种策略就不好。 写程序的时候，质量和效率最好的情况就是始终对于整个系统，在代码级别保持 一个非常清晰的状态，你心里知道要写成什么样，写的过程，整体的代码也清晰 合理，与你心里的样子相印证，然后可以心如止水的一寅非常快的写，整个过程 非常的享受。 而如采实现过程中，缺乏对于系统良好的认识和整理，希望“随便搞搞，搞出來 再整理“，这种在小型情况下是Ok的，但是大型系统下，即便思维保持清晰， 但是庞大的系统缺乏整理，而造成非常的复杂，很多东丙由于前后设计的不一致, 导致是处于一个不合理的复杂情况-需要你去死记。 这样造成的结果就是，即便你对于整体系统的设计非常的清晰，但是在编程过程 中，由于系统的一定的混乱，让你没法整个过程非常清晰的，心如止水的进行, 整个的过程，磕磕绊绊，让人疲惫不堪。 所以在后半段，就停下来改变Y策略，先做充分的整理，把不需要的部分去除, 然后把代码整理到完全准备好来做新代码的实现，才去做新的实现，这样反而是 最快的，写起來也愉快迅捷。 运行效率 处理效率，常规的基本做法是profile热点，以及根据游戏的情况进行feature 的关闭。 但是这个能做的事情是非常有限的，如果想做进一步提升性能，接近性能的极限, 必须要做的就是： ?对于每一个模块宥充分的理解 ?可以做到快速的反复尝试迭代 处理性能热点，在优化早期是一个非常高效的做法，准确来讲，热点处理是”在 有水分的情况下，高效提升性能“的方法。 但是在追求极限性能方血，热点优化还是不够，某一个模块的性能消耗是不是超 过了它应该有的，以及一个排名10名开外的模块其实是不需要高频运行的等等, 这些都是热点处理不能解决的。 在对于程序有充分了解，就可以进行更彻底的调整，把大量的运行做并行，低频 执行或者直接优化掉。 实践中看下來，这样的处理会把程序的性能带到一个新的台阶。 这个道理可以说是知易行难，难就难在，对一个超大系统（比如对于《天涯明月 刀》来说，就是整个客户端，覆盖儿十万行的代码），如何做到充分理解，如何 做到容易的彻底的修改优化。 所以关键点又回到复杂度，只冇程序的复杂度得到最好的控制，j能较好的做这 个工作。 这个后来在实践中，优化过程中，大约一半时间是在做代码的调整和重构，代码 合理就会让优化更加的可行和高效。 复杂度控制的方法与实践 实践下来，复杂度控制的能力在我看来可以从三个方而来拆解：渴望，目标与时 问积累。 渴望： 首先最冇效的方式就是去承扪实际的，要覆盖非常大范畴的开发任务，这种情况 下，你就会对于复杂度宥切肤之痛，你就会非常真切的了解到复杂度是什么，什 么是重耍的，让你抓狂的，什么只是虚张声势，无足轻重的，冇了非常充分的渴 望，那么后面的积累和实践就容易多了。 口标： 方法和实践会是非常