重构代码应如健康地生活

重构代码应如健康地生活

在工作6年的时间里遇过不少项目重构、项目重写的情况。有从PHP重写到Java,前后端一起重写;有App用 Ionic 重写,也有过同技术栈的老系统重构成新系统,更多的情况是老系统代码混乱,设计较差,业务变化时无法很好的扩展,使得代码在维护和改动时,开发成本剧增。

我认为一个软件的生命周期正常不应该低于3年,如果业务飞速发展,架构设计不够,只能撑2年也还行,这种是例外情况,毕竟业务飞速发展的情况下,软件设计的时候无法预想到更多的扩展情形,这需要非常有业务和技术经验才能做得好系统架构设计。

业务飞速发展也不是重构系统的借口,做好的话就可以避免重构的情况,要做的就是写代码的时候一直在不停的重构……

为什么要重构(Why)?

首先要理解重构和重写的区别,重构不是单纯的指重新开发,重新写代码,而是改进代码与设计。

直白的说重构就是改善现状,使得系统在扩展需求和写代码的时候更快更好、更合理。专业的定义:重构是一种对软件内部结构的改善,目的是在不改变软件的可见行为的情况下,使其更易理解,修改成本更低

重构的目的是改善代码质量,以便不至于让代码腐化到无可救药的地步。(程序员不愿意去维护的老代码,看到就口吐芬芳…)。项目需求在每日迭代演进,代码不停的堆砌。如果没有人为代码的质量负责,代码总是会往坏味道的方向走,味道变了,发出恶臭后(混乱),项目的维护成本就慢慢的高过重新开发一套新代码的成本,这时候要想再去重构,可能就做不到,做不好,不如重新开发一个新系统。 这时候可能就是重写了。

任何优秀的代码和架构,不是在着手写的时候就可以做好的,都是慢慢迭代出来的。我们无法100%预检未来的需求,也没有足够的精力、时间、资源为遥远的未来买单,这也是避免过度设计。特别是创业公司,应该以最快、最低成本的研发达到业务需求。所以,随着系统的演讲,我们再进行重构代码。

当我们真正遇到问题时,就应该着手重构,而不是说先这样,日后再改(重构),慢慢的就改不动了。重构代码其实对一个程序员的编码能力提升有很大的帮助的。有句话是这么说的:初级工程师在维护代码,高级工程师在设计代码,资深工程师在重构代码。 (这里的级别不是职称,就是个能力的概念)。

到底重构什么(What)?

重构分为大型重构和小型重构。大型重构指的是对顶层代码的设计的重构,包括:系统、模块、代码结构、类与类之间的关系等的重构,重构的手段有:分层、模块化、解耦、抽象可复用组件等。

小型重构指的是对代码细节的重构,主要是针对类、函数、变量等代码级别的重构,比如规范命名、规范注释、消除超大类或函数、提取重复代码等等。

不管是大型重构和小型重构,都需要用到设计思想、原则和模式。

何时重构(When)?

把一个系统当做我们的健康身体,我们不能等到代码烂到一定的程度(身体出现问题)之后才去重构(锻炼、改善饮食、不熬夜)。当身体出现大问题,就不能像健康的身体那样能承受日常生活的压力,日久就会加剧,而锻炼和端正作息的行为的目的就是让身体恢复到健康,这时候的目的就降了一个级别了。以前你身体也健康,也有理想去实现,现在理想变成梦想,理想变成了身体健康。所以,我们需要一开始就要保证身体健康,才能继续的去为了生活、未来目标、理想奋斗。重构就是身体健康的保证。

项目代码拉倒一定程度后,开发效率低,招了很多人,天天加班,出活率低,线上bug频发,领导发飙,管理束手无策,工程师抱怨不断,查bug难。这时候再重构也是比较晚的了,可能也无法解决问题。

和健康生活保障健康一样,日常就需要锻炼、不熬夜、按时吃饭。平时如果不注重代码质量,堆砌烂代码,实在维护不了了就大刀阔斧地重构,甚至重写代码,也不是一种可持续、可演进的方式。

何时重构的答案就是持续重构,日常迭代需求,修改代码的时候,顺手把不符合规范、不好的设计重构一下,这是最好的时机,因为之前的代码可能预想不到此时的业务需求,写得不够,当前需求完善的时候就应该改进该处代码,保证日后的可扩展性、易读性、健壮性等。

项目团队中要把单元测试、Code Review 作为开发的一部分,把持续重构作为开发的一部分,成为一种习惯,对项目、对自己都会很有好处。

该如何重构(How)?

大型重构时,需要提前做好重构计划,然后按阶段来进行。每个阶段完成一小部分代码的重构,比如一次最多动一个微服务,做好测试覆盖,上新版本,保留旧版本预后等。控制重构的影响范围,兼容业务和老代码,必要的时候都会写一些类似适配器的过渡代码。

大规模高层次的重构需要有组织和计划,也要有经验和熟悉业务的资深同事来主导。小规模低层次的重构因为影响范围小,改动耗时短,随时有时间都推荐去做,避免堆积后期改不动了。

重构这件事,需要团队中的资深工程师和项目leader负起责任。对代码放任不管时,有人堆砌了烂代码,日后也会更多的烂代码。

保持代码质量最后的方法是打造一种好的技术氛围,以此来驱动大家主动去关注代码质量。


参考资料 《设计模式之美》


本人自动发布于:https://github.com/giscafer/blog/issues/49