为什么拒绝代码重构？

为什么拒绝代码重构？

一、什么是代码重构

     

      重构（Refactoring）就是在不改变软件现有功能的基础上，通过调整程序代码改善软件的质量、性能，使其程序的设计模式和架构更趋合理，提高软件的扩展性和维护性。　

     也许有人会问，为什么不在项目开始时多花些时间把设计做好，而要以后花时间来重构呢？要知道一个完美得可以预见未来任何变化的设计，或一个灵活得可以容纳任何扩展的设计是不存在的。系统设计人员对即将着手的项目往往只能从大方向予以把控，而无法知道每个细枝末节，其次永远不变的就是变化，提出需求的用户往往要在软件成型后，始才开始"品头论足"，系统设计人员毕竟不是先知先觉的神仙，功能的变化导致设计的调整再所难免。所以"测试为先，持续重构"作为良好开发习惯被越来越多的人所采纳，测试和重构像黄河的护堤，成为保证软件质量的法宝。

     以上引用百度百科中的解释，详见http://baike.baidu.com/view/5310022.htm。

二、难以得到各部门支持

      根据代码重构的定义，我们可以看出代码重构是一项纯技术改造，要求不改变原有的业务流程，这样的话，我们就很难得到业务部门（前台部门）的有效支持。

      少了业务部门的参与，一方面申请项目资源会遇到这样那样的困难；另一方面，业务验收测试也没法进行，少了对重构后是否影响原有业务流程的校验。

      对于热衷于提出新需求的业务部门，技术部门很难去要求他们做什么，只能由更高层去协调。或者由开发部门的BOSS向高层介绍代码重构的重要性以及对改善用户体验带来的帮助等等，再由高层向业务部门指派任务。

三、难以评估工作量

      有些单位的QA人员没有写过代码，进行工作量评估时会问我们，你们这都有现成的代码，略加梳理优化即可，算作新开发同类接口的工作量的一半吧。

      遇到这种情况，其实我们很无语。说实话，怎么评估呢？工作量可大可小、重构程度可深可浅，并且开发人员经验水平不同同等程度重构所花时间也不尽相同。

      也许与QA搞好关系，尽量让他们评估的结果与我们预想的一致是一条捷径吧。

四、采取渐进式重构

      难以得到相关部门支持、难以评估工作量这些困难我们都认了，关键是我们费尽心力重构完毕后，使用人员看不到任何变化，自然也会认为我们什么都没做。

      别管这些了，只要认识到重构的重要性，就将此项工作提上日程吧。

      但做此事，不要冒进。切忌把一个系统的所有代码都挖出来，然后分工各自优化重构去，那样的话，项目很容易失控。

      建议采取渐进式重构的策略，各个击破，最后夺取胜利。具体办法是，将重构任务分配到具体项目中，比方说项目A需要对交易XX增加新功能，那么我们评估XX的工作量时，既要算上增加新功能的工作量，也要算上重构的工作量。另外，重构代码占项目的比列不要太高，需要PM合理配置。