我是一个着迷于产品和运营的技术人，乐于跨界的终身学习者。欢迎关注我哟～
每周五12点 按时送达～
我的第「227」篇原创敬上
大家好，我是Z哥。
(资料图片)
关于重构的文章之前也写过两篇：
《接手历史悠久的老项目，干or跑？》 《好的重构方法才能摆脱“屎山”》但是这两篇主要讲的是重构的方式方法。在 Z 哥看来，除了方式和方法还有一个点对于重构这件事来说也很重要，就是如何能够实现“小步重构”。
因为只有“小步”地进行重构，才能达到那种未雨绸缪、防范于未然的效果，将风险扼杀在摇篮里。
所谓“善战者无赫赫之功”，我是非常不提倡以“憋大招”的方式在某个时期重写一个新系统的，不但风险大成本也大。
但是要实现“小步重构”，需要平时注意一些细节，下面我来分享一些我的经验。
首先，归根到底重构就是偿还技术债。所以小步重构之前我们首先要有一种比较好的方式来对待技术债。
不知道你有没有过这样的经历：
在编码实现一个功能时，发现有一个逻辑如果按照全面去考虑的话需要改动很多地方，甚至可能要推翻当前已经写过的部分代码，但是呢现在实际场景并没那么多，当前的实现已经能满足。算了，先这样吧，后续业务怎么发展还不知道呢，到时候再说。
这就是一种很常见的债务，并且这种债务很容易让人忽视，因为它并没有让你在当下做出什么曲线救国的事情，只是一种“短视”的妥协。但是这种妥协一旦多了之后，后续的迭代往往会有很多大大小小的补丁来覆盖之前没有考虑的场景，最终积重难返，因为项目难以继续维护而重写。
上面提到的“大大小小的补丁”其实就是另一种常见的债务，这些补丁往往伴随着 if-else 这种代码出现。大家也都知道，if-else 代码如果过多的话，对人的阅读是非常不友好的。
技术债还有很多，我想每个程序员其实都能识别出来。对待它们的方式不同，最终形成不同人之间工作成果的差异。
Z哥推荐你对待技术债的方式很简单。就是在代码里增加 todo，然后将清理 todo 作为一个固定的任务安排，定期进行。
记 todo 看上去是一个简单的事情，但是还是值得花点心思来提高效率的。常见的场景比如：
有一些改动需要涉及到多个地方，那么可以用某种标识（我习惯用当前时间精确到分钟）来统一标注一下，这样后续修改的时候就不会出现只改了一半导致出现 bug 的情况。 有些重构可能依赖于一些其它的改动才能进行，那么也可以把依赖的改动信息写一下，如果所依赖的地方恰好也在本项目内，还可以备注一下相关的文件名和方法名。 有些重构还可能有一些 deadline 的约束，比如需要在 xx 日期前完成，那么也可以备注一下。我平时用的 todo 格式是：
//todo：描述需要做什么重构。（202206121536）。依赖于xxx文件中的方法xxx。需要在2022.7.30前完成
做好了备注，剩下的就是定期清理 todo 了，这个需要根据当前的工作饱和度来安排，但 Z 哥建议，哪怕非常忙，至少 1 个月要进行一次。
好了，这篇呢 Z 哥和你分享了我对小步重构这件事的看法和经验。
重构一定是小步快跑式的方式是最好的，不但可以降低风险，从长期来看所耗费的成本也是最低的。具体的做法也很简单就是记 todo 和定时清理。
关于重构的一些方式方法可以查看我之前写的两篇文章。
《接手历史悠久的老项目，干or跑？》 《好的重构方法才能摆脱“屎山”》希望对你有所帮助。
对了，最后还有一个建议强烈推荐给你。就是没有调用的方法尽早删除，不要留着觉得以后可能还会用。根据我这么多年的经验来看，未来再会用到的概率微乎其微，留着反而增加了后续的代码重构成本。因为当你修改一个方法或者字段，然后通过IDE查找引用的时候，这些其实已经没有调用的方法也会被关联到。
推荐阅读：
接手历史悠久的老项目，干or跑？ 好的重构方法才能摆脱“屎山”也可以「关注」我，带你以技术思维看世界～
想更进一步和我一起玩耍，欢迎「搜索微信公号：跨界架构师」。
内容包括：架构设计丨分布式系统丨产品丨运营丨个人深度思考。
