我经历过的几次重构

最近准备推动团队产品进行代码重构,过程中遇到一些问题与困难,由此也回想起早年经历过的一些重构,其中有些并非我主导,在此简单记录,主要谈其中印象深刻的体会,不展开。

第一次重构

我刚参加工作不久,进入了一个刚刚重组成立的项目组,我们接手时前面的人都已经离职了,一个不剩,就是这么任性,当时的代码是用 C++ 写的,而且比较混乱,难以维护,当时的老大决定用 C# 将项目重写, 于是带领我们进行了我职业生涯的第一次重构。重构的目的主要是希望优化设计,减小维护成本。印象深刻的是在重构之前,老大让我跟他一起画了一个看起来巨牛逼的重构设计图,其中引入了各种不明觉厉的设计模式,今天回想起来只能用过度设计来形容了,实际上最后非但没有减小维护成本,反而因为引入了一些复杂的设计模式,导致代码层次深性能差,难以理解。随着最初主导设计人员的离职,框架开始崩坏,后续越来越难以维护,到最后不得不面临再次被重构。

第二次重构

这次的重构由公司里一位非常优秀的工程师来主导,也正是他直接指出之前过度设计的问题,提出了一套更加简单清晰的设计方案,设计本身是业内经典架构,并没有太大问题,最后也是顺利完成,但重构后的代码并没有坚持太久,又开始逐渐腐化,根本原因还是在于各种程序员的代码水平参差不齐,项目里太多低质量的代码,又没有code review 来保障质量。我的感受是光靠架构设计本身,并不能解决所有问题,代码腐化是发生在产品演进迭代过程中的,好的架构不是银弹,只关注宏观结构不注重细节质量必然也是不行的。

第三次重构

这次我们面临了新的复杂业务的需要,同时也引入了一位新的、比较纯粹的架构师,意思是基本只负责架构设计与架构实现,在实际重构过程中,还是发现了一些问题:架构师有自己的架构理想,希望将自己多年的架构经验付诸到具体的业务里,验证自己的想法,因此这次又产生了过度设计的老问题,而且比之前还要严重,每当问及他这里为何要如此复杂设计?理由都是将来这里可能会怎样变化云云,咋一看挺有道理,而实际上很多担心过的变化直到我与他都离开也从未发生过;除却过度设计,他当时的一些设计观点现在看来也有些陈旧过时,应该跟他之前的从业经历有关,每个人都可能受自身背景的局限,唯有不断学习与了解各种业内新知识,与大家多交流,才能突破自身技术视野的狭窄。

第四次重构

这次是我自己主导,主要是针对新业务的扩展需要,对现有代码进行调整,其实并没有大的架构调整,除了对代码的整体结构整理,都是一些局部代码的调整,以满足业务的扩展需要,同时对以前的一些痛点针对性调整,完成后确实也达到了部分目标,但仍然遗留了很多问题没有解决。这次的主要收获是,重构前要有明确的要解决的目标,针对目标设计方案,不要为了重构而重构,追求完美心态的重构。当然也有一些教训,重新认识到自己能力有限,看了很多这方面的书,还是没能做好,低估了其中的困难,也没能从整体上进行规划,代码已经过于庞大,也是畏惧大改,深怕陷进去,一些陈旧的不好的代码模版仍然被保留,甚至还引入了一些新的坑。

在迭代中重构

以上是我职业生涯经历过的一些印象深刻的大规模重构,越到后面,越发明白等到技术债务欠到一定程度,需要进行完全推翻重来的重构,是一件多么困难的事情,除非有足够的资源与支持,否则风险极高,也未必能做好,因此个人的建议是重构必须随时进行,在每个迭代中进行,在很多重构相关的书里都提到过这点,但真正能做到的人不多,每次我们要开发新功能,一旦涉及到代码里的技术债务,就尽量设法一并处理掉,这样你不仅做完了新功能,同时也还清了一个技术债务,是我认为比较理想的重构方式,当然这需要我们在开发时为此预留足够的时间,最终能否可行,取决于团队以怎样的态度看待技术债务,在技术改进与业务推进之间做出权衡。

推荐阅读更多精彩内容