代码重构需要亲力亲为

吴旻

泰岩网络工作室

 

         这段时间我处理了大量代码和业务逻辑的细节问题。

         应该说，我已经快有1年没有关心这些细节了。没关心是觉得弟兄们希望自己能处理好这些问题，我应该适当相信他们；现在出来关心则是发现弟兄们对这些问题的把握有偏差。

 

         第一个让我觉得吓一跳的是代码的行数。功能没加多少，代码行数则快翻番了。我看到的最大的一个文件有将近2000行，我凭直觉认为至少可以砍掉一半行数。这些代码的某些函数相似度极高，完全可以合并成一个。无论是业务骨干，还是初级程序员，大部分人都是在不停的添加代码，哪怕根本不需要添加代码；极少人能静下心来把这些代码进行整合、优化。

         第二个让我觉得惊心的是代码架构变成了“高度化中央集权制”。其实只有少数参量是需要对外公开的，但事实上却是全部参量都放到了一个公开的类中，这样做的目的很明确，就是想什么时候用什么时候用，想在哪用就在哪用。但“中央政府”不可能替“地方政府”做好一切，“地方政府”也不可能为了屁大点小事，还得去“中央政府”请示一下。面向对象的一个原则其实就是“属地”原则，自己能解决好的事情，就别闹那么大动静了。

         第三个让我觉得不能理解的是运行效率问题。几个重要的工程，运行起来都很消耗CPU，这让我极度不解。实际上这些程序大多是在进行数据的简单运算，应该不需要什么CPU，仅仅需要有限的内存而已。两点典型的错误是，一个程序在不停的new和delete内存，其实完全可以一次申请，多次复用，最后退出前释放；另一个程序则是在不停的写文件，虽然这些数据需要保存到文件中，但不是必须立刻写入到文件中的，可能半分钟写一次就好了。

         第四个则是我认为有些代码取得的成绩没有引入的问题多。一个小兄弟不只一次向我解释说，“不这样写程序就不能正常运行”。我不得不一次又一次的重申解决问题的方法有很多，我们完全有能力找到更好、更优秀的方案；而现在问题的关键是，没有人告诉我他需要帮助。

         第五个应该是大家都不太愿意理解并简化业务逻辑。代码最终还是要体现业务逻辑的，如果业务逻辑不正确，代码的意义就不大了。我不停的在问弟兄们，你觉得怎样才是合适的？结果让我高兴不起来，大多数人选择了沉默。也有人向我解释了半天，也无非就是说，这个逻辑不是他定的，他把业务逻辑处理成这个样子，是有N+1个原因的。我想这也是第一个问题所说的代码膨胀的根本原因。

 

         事实上，我所在的团队近年来取得了很大的成绩，也得到了大家一致的认可。不过我确实对这些代码非常不满意。代码重构这件事，我也叮嘱过几个骨干人员要做好。但显然我们对什么是“做好”产生了分歧，他们理解的“做好”就是运行起来没问题，而我理解的“做好”是傻瓜也能看得懂。

         在相当长的一段时间里，我都感觉到程序员不太希望我出现。我的出现对他们似乎有太大的压力，于是我尝试着淡出他们的视线。他们偶尔也会来找我，但基本上是在无论如何也进行不下去之时。我经常笑谈，弟兄们只留给了我半天时间。我明显能感觉到，程序员们浪费了大量时间去解决一个什么问题，最后只剩下半天时间了，已经到了完工的截止日期了，突然出现在我面前，告诉我进行不下去了。要么希望我在半天内帮他解决这些困难，要么希望我宣布工作延期。

         我偶尔会感叹，为什么不能留给我一天半的时间呢？

 

         身为团队负责人，事无巨细都要管是不合适的；但代码重构这件事，看来还真的是需要亲力亲为的。