iOS开发 代码重构心得

这段时间我处理了大量代码和业务逻辑的细节问题，特来总结一下重构中遇到的问题。

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

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

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

         第四个则是我认为有些代码取得的成绩没有引入的问题多。解决问题的方法有很多，我们完全有能力找到更好、更优秀的方案；而现在问题的关键是，没有人告诉我他需要帮助。

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

事实上，若要想着为团队负责，事无巨细都要管是不合适的；但代码重构这件事，确实还真的是需要亲力亲为的。