代码重构浅谈

1. 为什么要进行代码的重构

    当今时代无论做哪能方面的事情，都离不开速度和效益这两个关键字，软件产品的开发也是如此。那么，在更短的开发周期内，如何才能推出功能更新质量更好的产品呢。如果新Model是在已经有模型的基础上开发的，那么如何优化旧产品本身的结构，使其更加适应新的需求，从而可以在规定的时限内能够使新产品交付使用。基于这些原因重构被作为一个重要环节引入到现代项目开发和管理中。

2. 如何控制重构的风险

   尽管重构的概念很早就已被提出，但是并未被广泛的运用到商用软件开发中，一个重要的原因就在于风险。那么重构会引出哪些方面的风险呢？首先是重构所花费时间上的风险，如果工数付出太多那么即便这么做可能很大的好处它的前景也不容乐观。其次是重构由谁来进行，由于技术人员的水平参差不齐，所做的重构是否值得，以及重构代码的是否真正提高了效率，是否取得了预期的收效都是未知数。再次是重构之后的管理开销，例如重构仅仅是个体的行为，开发人员都按照各自的喜好进行重构，最后可能各个功能模块都还不错，但后期巨大的维护工作会使得所做的重构没有意义。

   如果真的有必要进行代码的重构，如何来避免这些风险呢？首先必须肯定的是重构的工作比常规的基于继承代码的修改更为复杂，所以在人员安排上需要尽可能的将技术上较强的力量放在这些工作上。其次是重构的管理上，必须明确重构不仅仅是开发人员自发的行为，必须在管理层的监控下统一进行。而且必须在重构之前对相似的内容进行梳理，在讨论的基础上确定一个较好的重构方案后，然后再由技术人员统一进行代码重构。再次是加强重构之后的测试。最好的情况是需要一个完整的自动化测试架构，基于它测试用例可以最快速的得到检验。

3.重构内容的筛选

   在一个大型的软件项目中，可能涉及的代码有成百上千万行。哪些代码值得去重构，应如何筛选，是一个很复杂的问题。作为项目的管理者或者某几个开发人员是很难全面准确的给出答案的，一个比较可行的方法是在新项目的前期把重构最为一个议题明确提出，再有开发人员各自总结出负责部分值得重构的内容。管理者和比较有经验的担当根据这些内容，找出多个模块共通的值得重构的内容，进行第一道筛选。再由开发人员根据上边提到的方法给出重构所需工时及修改后可能获得的好处(这一内容也可以通过工时计算大致的给出)，管理者根据投入产出最大化的原则进行第二道筛选，基本上通过上述两个步骤可以找出最值得重构的内容。

本文对重构的管理和组织作了简单的阐述，核心的思想是让重构从开发人员的自发行为转变为从项目全局出发的有组织的行为，通过代码重构提高机能代码的重复利用率，进而提高工作效率，整体上减少开发者自身工数。