为什么拒绝代码重构?
一、什么是代码重构
重构(Refactoring)就是在不改变软件现有功能的基础上,通过调整程序代码改善软件的质量、性能,使其程序的设计模式和架构更趋合理,提高软件的扩展性和维护性。
也许有人会问,为什么不在项目开始时多花些时间把设计做好,而要以后花时间来重构呢?要知道一个完美得可以预见未来任何变化的设计,或一个灵活得可以容纳任何扩展的设计是不存在的。系统设计人员对即将着手的项目往往只能从大方向予以把控,而无法知道每个细枝末节,其次永远不变的就是变化,提出需求的用户往往要在软件成型后,始才开始"品头论足",系统设计人员毕竟不是先知先觉的神仙,功能的变化导致设计的调整再所难免。所以"测试为先,持续重构"作为良好开发习惯被越来越多的人所采纳,测试和重构像黄河的护堤,成为保证软件质量的法宝。
以上引用百度百科中的解释,详见http://baike.baidu.com/view/5310022.htm。
二、难以得到各部门支持
根据代码重构的定义,我们可以看出代码重构是一项纯技术改造,要求不改变原有的业务流程,这样的话,我们就很难得到业务部门(前台部门)的有效支持。
少了业务部门的参与,一方面申请项目资源会遇到这样那样的困难;另一方面,业务验收测试也没法进行,少了对重构后是否影响原有业务流程的校验。
对于热衷于提出新需求的业务部门,技术部门很难去要求他们做什么,只能由更高层去协调。或者由开发部门的BOSS向高层介绍代码重构的重要性以及对改善用户体验带来的帮助等等,再由高层向业务部门指派任务。
三、难以评估工作量
有些单位的QA人员没有写过代码,进行工作量评估时会问我们,你们这都有现成的代码,略加梳理优化即可,算作新开发同类接口的工作量的一半吧。
遇到这种情况,其实我们很无语。说实话,怎么评估呢?工作量可大可小、重构程度可深可浅,并且开发人员经验水平不同同等程度重构所花时间也不尽相同。
也许与QA搞好关系,尽量让他们评估的结果与我们预想的一致是一条捷径吧。
四、采取渐进式重构
难以得到相关部门支持、难以评估工作量这些困难我们都认了,关键是我们费尽心力重构完毕后,使用人员看不到任何变化,自然也会认为我们什么都没做。
别管这些了,只要认识到重构的重要性,就将此项工作提上日程吧。
但做此事,不要冒进。切忌把一个系统的所有代码都挖出来,然后分工各自优化重构去,那样的话,项目很容易失控。
建议采取渐进式重构的策略,各个击破,最后夺取胜利。具体办法是,将重构任务分配到具体项目中,比方说项目A需要对交易XX增加新功能,那么我们评估XX的工作量时,既要算上增加新功能的工作量,也要算上重构的工作量。另外,重构代码占项目的比列不要太高,需要PM合理配置。