写点什么

何时开始重构?

用户头像
Page
关注
发布于: 2020 年 05 月 15 日

“任何时候都可以重构”,如果这样回答太过于宽泛,因为总有那么一些时候重构的 ROI (投入产出比)并不高,设置与对重构还不那么熟悉的开发者相当于什么都没有说。


所以整理了下日常开发中进行重构的时间点,从而来帮助提升开发效率和重构效率。



如上图:日常重构的时间点可以分为上述三个时间点。


  1. Tasking 之后,开发之前进行重构;

  2. 开发过程中,进行小步重构;

  3. 修复 Bug 时进行重构;


01 Tasking 之后,开发之前进行重构


Tasking 指的是任务拆解(如果不熟悉,可以看这个视频 或者 看这篇文章),拆分过程中有可能会涉及到在原来的代码上进行添加,因此可以在 Tasking 过程中先了解原来的代码,并将原代码中发现的坏味道标注出来列在 Task 列表中。


因此在完成 Tasking 之后,其实就是一个时机来进行重构。当然有些重构并不是一开始做,而是随着实现逐步引发小步重构。但是 Tasking 之后考虑何时重构绝对是一个事半功倍的时间点。


另外,在干净整洁的代码上添加新的代码,也是更加容易的。


02 边添加新代码边重构


Simple Design 在实现业务代码时给我了我们很好的指导,能够在实现代码的过程中,保持代码结构的简单。除了技术上的重构也让产出的代码和业务贴近。


自上而下的开发方式,能够帮助我们维护好代码的层级结构。自上而下的开发方法过程中也需要 小步重构,来让代码在逐渐添加的时候,同时维持整洁。


重构时有个“事不过三,三则重构”的原则,指的是并不是每个 Smell 都需要一上来就聚焦消除,而是随着重复障碍、重复代码的出现次数增多而决定重构的辅助原则。其中的三次是个概数,指的是大于等于 2 次,至于第几次进行重构,取决于你遇到的实际问题,可以延迟解决,也可以当机立断立刻解决。


边添加代码边重构,还能够减少上下文切换的时间。当我们聚焦在一小段代码时就可以重构,由于上下文边界有小,很容易出现重构思路,并采用响应的手段。避免形成大段脏代码之后才进行一次重构。在重构技巧上多加练习就能达到小步重构的能力。


03 修复 Bug 时重构


前面介绍的是添加代码开始之前重构来让后续工作更加高效,添加代码过程中重构,保持开发效率的同时,时刻守护代码设计。还有另外一种场景,就是修复 Bug。


修复 Bug 时,很容易由于修复而导致原本的设计收到破坏,如果原来的设计不合理那么我们当然应该修改它,如果原来的设计挺好,修改 Bug 的时候我们也应该进行重构,避免让代码因为后续的修改而逐渐腐败。


另外一种场景时 Code Review 之后如果发现了某些坏味道或者设计缺陷,或者更好的实现方式,可以在 Code Review 时利用 Todo 插件,编辑需要重构的点、需要重构的原因、重构的目标,并在当天将 CR 时发现的问题进行修复。这个修复 Bug 类似,需要时刻保持重构的习惯。


总结


如果你对重构技艺已经非常精湛,并且能够灵活控制重构对代码添加、修改的影响,那么从各种场景来看“任何时候都可以重构”又是正确的,因为此时:能力决定了生产力


用户头像

Page

关注

如果一项实践有价值,那么就将它做到极致。 2011.04.17 加入

ThoughtWorks

评论

发布
暂无评论
何时开始重构?