关于写程序的一个经验

最近有一些感触。

我从外企出来以后，分别进入过两家民企，接触过两个游戏项目，也算是大项目。

虽然两个项目的技术层次不一样，但有一个症结都很雷同，我相信也是大部分项目都有的问题。

就是，今天修好了这个bug，那边又冒起来一个，像打地鼠一样，根本就修不完。就算是修到基本稳定，也是千疮百孔，四处补丁。

我认为，导致这种问题的最根本原因是，程序员没有遵照：一个模块只做一件事情  的基本原则。这里的模块可以指一个函数（我认为函数是最基本的逻辑单元），也可以是一个大逻辑模块。

因为之前在外企受过良好的影响，我非常注重这一个问题，如果说写代码花1小时，那么我至少花了三个小时来规划架构和反复的重构接口，务必让每个模块，每个参数绝对没有二义性，也没有矛盾冲突。

实践证明，我写过的模块，复杂度再高，也很稳定，基本不会反反复复出bug，以至于到项目后期我都挺寂寞的，呵呵。

其实模块稳定只是一个最基本最基本的要求，这个原则的更大的优点是：扩展性相当的好。因为每个函数的含义都唯一，所以只要模块逻辑本身没有问题，都可以很纯粹的通过重组来实现。经常听到程序员抱怨需求变化让他大改大修，其实这是典型的一个没有把问题进行抽象分解导致的问题。很多时候，我们不应该仅仅只看需求表面的文字，而应该通过表面看到这个问题的实质，针对这个实质提出解决方案，就算他表面再怎么变，也就是重组一下结构，增加一些接口而已。

如果一个函数不纯粹，或者模块内部彼此错综复杂理不顺，这里if那里if的，这种模块就相当脆弱，更别指望它的性能。

通常表现就是：代码冗余，if语句遍地都是，函数爆长，参数暴多，到处都是潜规则。每次看到这种代码我就一阵头疼。那不是在和计算机斗争，那是在和一个精神分裂逻辑混乱的患者尝试交流。

还有一些人对扩展性的理解就是，对函数加一票参数，然后告诉你这个参数改一改可以这样，那个参数改一改可以那样，反正是一串，十多个。这种理解实在太病态了。每次遇到这种接口（特别是原作者已经不在），都忍不住找个墙来撞。

我以为，对于一个bug，程序员在30分钟以内，找到原因，在一个小时内修好，并保证这个模块永远不再出现类似的bug，就是优秀的。

如果掌握了这个原则，其实是很容易达成这一点的。