我的重构感悟

在三年前我就读了《重构改善既有代码的设计》,里面写了很多有关代码重构的技巧,知易行难!我整理了一下重构给我的感悟。

NO.1是什么导致的重构?

为业务的改变而调整

这是一个最合理的原因,我们无法预料到业务的发展,我们当下制定的业务职责和边界,对于一个快速发展的项目,能应对半年的情况,已经是一件相当不容易的事情。正如我们业务发展开始的时候,能承受起几千个用户。而当有十几万用户的时候,系统承受的压力是远远的不一样的。

为自己or别人的错误埋单!

代码是由程序员创造,我们如果不好好教育代码,一旦让它成为令人抓狂的“熊孩子”,最终的恶果还是我们自己承受。我也会吐槽自己写过的代码,毕竟编程技巧是一项技艺,需要日复一日的不断磨练,需要承受自己给自己带来的坑,才会学会成长。作为一名及格的程序员不能把重构时刻挂在嘴边,正如教育孩子更多是需要言传身教,以身作则。所以我们要将重构彻底融入到每一句代码中,我们既是在不断写新的业务,也是不断在重构我们的代码。

“无奈”的架构师

很多公司招了一个牛逼的架构师,怎么可以在短时间内向公司证明自己的能力?重构无疑是一条快捷的出路。

因为公司之前的架构已经不能适应公司发展,导致了公司业务发展不顺。听说过有些创业公司,每招来一个架构师,就把之前的代码进行重构一次的事例。但是这种重构,更多的是重写,而不是重构。但这种重写,往往由于架构师对业务缺乏深度的认识和充裕的时间,带来了断崖般的崩塌,因为在重写的过程中,bug层出不穷,导致业务极其不稳定。这也是一些人对重构嗤之以鼻的情况的根源。

NO.2重构前提条件是什么?

全盘熟悉代码,掌控业务。

接手别人的项目时,在看到混乱不堪的代码后,不要一上来就开始大动干戈。先熟悉代码架构,如果一个代码架构都混乱不堪,那就多费点劲,将代码好好得梳理一遍,如果有详细地文档的话,配合文档一起阅读的效果会更好。但是现实却是,你不得不去阅读一些令你感到莫名其妙的代码,然后自己去整理文档。慢慢熟悉一个项目的业务逻辑,梳理清楚业务内部之间的关系。如果你不熟悉业务,不熟悉代码,来讲重构,无疑是重写的罢了。

时间!

在你尚没能熟练《重构》的各项技巧之前,请首先明白你当下是否有充足的时间,毕竟高效完成工作才是最重要的。在工作中,其他人更多只会关心的是程序员的产出:项目的稳定快速迭代,但是熟练技巧需要大量的练习时间。而大型的重构,则需要更加多的人力物力的投入。

NO.4重构的目标是什么?

标准化

在不断地编码过程中,遇到的重复的问题会越来越多,而各类语言框架正是将标准化的一种体现。而对遇到的重复问题进行标准化处理,除了能让我们避免重复劳动提高开发效率,及让我们将一些业务进行层次分工。在标准化的过程中,主要做的是将业务职责划分清楚,避免混乱不堪的界面。

标准化是一个很漫长的过程,收益很明显,但是正如企业的架构一样,当面临调整的时候,也会面临重大的挑战。当我们面临将已经标准化的代码架构进行重构的时候,这样的重构成本会相当的高。所以在制定标准化中需要严格按照“SOLID”的原则下进行。虽然这是有点古老的原则,但是没有这些原则指导,制定的标准化,寸步难行。

更好,更快

无论在什么情况下,在编程里面完成任务是重中之重(重要的事情要重复一下)。只有先完成,我们才能去说追求更多——让程序运行的更好,更快。要做到这个目标,必须要在时间复杂度和空间复杂度上下更多的功夫。这是《数据结构》这门课程最基础、最简单,也是贯通全书的知识点。最近在阅读《Redis设计与实现》一书的时候,更是充分地了解到这两点的重要,几乎是所有操作都是O(1)的时间复杂度,在它各种数据结构和对象的实现上,都体现了尽量少的存储空间做尽量多的事情。Do less,get more!

我们虽然谨记时间复杂度和空间复杂度,但是不能绝对强调。更好、更快不是单单指这两个基础指标,还有代码的可读性、可扩展性,还有业务之间的耦合度和业务自身的高内聚。如关系型的数据库一样,绝对的范式设计只会存在于实验室。在现实的项目中,为了提高开发效率和查询速度,我们会根据实际需要设计冗余的数据表。所以,在实际开发中我们总要适当的进行取舍,根据业务的特性和实际场景,牺牲一些时间复杂度和空间复杂度,以达到整体更高的收益。

NO.5重构带来了什么?

开发效率的极大提升

之前有一段时间,有好几个项目我需要同时开发,但是我都可以完全轻松的掌控,而且是保质保量地按时完成了开发任务。因为我在不断地重构中,整理出了一套自己的编码标准,在这套编码标准下,设计好了代码思路后,进入了编程阶段的我无需过多的进行思考,只要我按照自己制定好的道路和代码层次去简单编码即可。而在测试阶段出了一些bug,更多的是产品设计上的缺陷而需要产品完善的地方。
对于目前来说,写一个新的业务,就是在一个零零散散的积木进行快速拼凑,再为这个项目添加上它自身的特有的色彩即可。

开发思路的改变

对于我而言,我是在完善自己的代码工具库。首先如何将一些常见的代码逻辑进行不断抽象进行封装,变成自己的工具;如何将自己的工具变得更加快捷便利,当下的工具是否需要进行调整来适应业务发展;在什么业务场景下,哪些工具可以复用或者抽取形成一个微服务。

NO.6重构边界

在《重构》中说到,重构是在时刻进行着的。对于个人开发业务而言,这是正确的,因为需求触发改变。但是对于整体架构而言,我们更多的是在固定的框架下,默默耕耘。

正如在一栋楼房里面,我们可以花一天的时间对其中一个房间进行重新摆设,而对整栋楼房的影响近乎微乎其微。因为每个人有自己的风格,对房间按照自己的心意进行重构,无可厚非。但是要对整栋楼房进行重构,那是一个极其漫长的过程,再者,如果业务没有达到飞跃性的增长,整栋楼房的坚固稳定尤其重要,毕竟人都要舒舒服服地住在里面,谁能容忍,三天两头在自己家里进行装修?

故此,重构的边界显而易见!其实当“人口”激增了,一栋楼房不能再适应的时候,如果有充裕的时间和地方,重建一栋无疑是最好的选择。

推荐阅读更多精彩内容