思考

为什么难以避免重构代码

Tags:

-2019年3月1日

最近参与重构项目,每天重构的很痛苦,有时候焦躁的实在受不了,就去楼下抽根烟,完了上楼继续。

这也让一个我很久之前就有过的问题再次出现:重构这事在软件开发中是可以避免的吗?

什么是重构代码?

《重构:改善既有代码的设计》这本书中对重构的定义为:

重构(名词):对软件内部结构的一种调整,目的是在不改变软件可观察行为的前提下,提高其可理解性,降低其修改成本。重构(动词):使用一系列重构手法,在不改变软件可观察行为的前提下,调整其结构。

本文要探讨的重构代码,用个通俗的比喻就是:Broken the cup, repair it !

根据常识就可以知道,repair一个cup要比重新造一个更麻烦,这也是重构这件事一般都会让做的人很头痛的原因。

为什么需要重构代码?

一个系统从开始到发展成为必须要进行改造(也即重构)的原因的很复杂的,就我个人经验来看,至少可能包含以下三方面的原因:

第1,前期设计不合理,导致后期模型无法支持后续业务发展;
第2,在开发的过程中开发人员不重视代码质量,欠债多了总有一天要还;
第3,支持新业务发展进行的合理改造;

我们来分析这3中情况产生的原因,再看是否可以避免。

对于第1和2种情况,最主要的是人为的原因,但也有不同之处。

第1点发生的原因在于开发人员系统设计不合理,这其实是技术人员本身能力的问题,通过提升业务能力和抽象思维能力,其实是可以很大程度上避免的。有人可能会觉得有些系统过于复杂,能力再高也难免设计会有不合理的地方。现实确实是有的,但理论上来讲,系统可以更复杂,人的思维和能力也可以更厉害,只不过是说到一定程度之后系统复杂性的增长速率是不是比人思维能力提升的速度要快的问题,这里的提升速度也可以理解为所花费成本的多少。

第2点可能是因为两方面的原因,一是开发人员可能本身编码能力较弱,二是开发人员嫌麻烦堆代码。依我过往的经验来看,有些人实际上可以写出更好的代码,但为了方便抱着完任务的心态随意写,就好比砌墙的人在当时可以用不规则的砖头,在短时间内并不影响墙可以继续往高砌,但时间久了这个墙就必然要推倒重来。而他决定当时用一块不规则砖头的原因其实很简单,就是这块砖头在手旁,去拿规则砖头要起身走点路。
不论是因为开发能力弱,还是不够用心,实际上都是人为原因,也都是可以避免的。站在开发人员的角度想象一下如何避免代码重构,不外乎提高自身编码能力和提升工作态度,站在公司角度想如何避免项目重构带来的额外成本,那就招聘更厉害的程序员,但这不一定是好事。

再来看第3点,实际上这一点是在我看来唯一无法避免的。一个公司的发展在现如今如同探险者在亚马逊丛林中穿越一样,谁也不知道前面是什么样,尤其互联网公司都是迭代开发的模式,很多庞大的APP上的功能都是一点点叠代完成的,支付宝发展初期也很难设计到能完全满足未来像余额宝、芝麻信用、保险这些业务的发展需求。
所以这一点我认为是无法避免的,但这一点也不一定会导致代码重构。

结论

通过上面的分析,我们发现代码重构的风险是很容易发生的,人为和不可控的非人为因素都有可能导致系统发展到一定阶段需要重构。

但不能就此而人为所有的重构都是合理的,我们应该在项目开发中严格控制代码质量,在系统设计时要尽量保证实体的单一性、业务模型的合理性,功能模块符合低耦合高内聚的原则,引入一种概念模型要深入到本质,极有可能就是和已有概念模型重叠 等等。在做好的该做的之后,至于由于未来业务需求导致系统的重构改造,那就是正常开发工作的一部分,在正常情况下不排斥的看待重构反而可以减少在重构时的痛苦。

完。




Leave a Comment