“镶金玫瑰”重构视频秀第三弹:两顶帽子的切换
收藏

我前几天给一组同学讲重构,问了一个问题:拿到一堆很糟烂的、需要重构的祖传代码,你怎么下手?


同学很积极,举手说:我要先理解它的业务逻辑,然后……


我说:打住,这就已经没有然后了。


一旦你开始尝试理解祖传代码的业务逻辑,你就掉进了一个解不开的死结。存在时间越长、质量越烂、越需要重构的祖传代码,越是难以理解。如果你的重构步伐是先理解、再动刀,那最烂的那一堆祖传代码,你就永远下不了刀,你就永远只能重构一些边边角角的、不那么重要的代码,你的老板和同事就永远会拿这个说事儿,说重构放在真实项目里就不好用。


重构的关键要义就在于:重构代码,不需要理解代码的业务逻辑


重构的过程是:


  1. 发现代码中的坏味道。面对纠结的祖传代码。你翻开《重构》第三章,一条条比对,看哪一条符合你代码的情况。

  2. 找到对应的重构手法。每条坏味道都列出了对应的重构手法及其所在的页码,翻到那一页,阅读这条重构手法。

  3. 严格按照重构手法实施重构。不要自己想当然,不要大刀阔斧的就开始砍代码,按照重构手法一步步做,重构手法叫你新建一个空函数你就新建一个空函数,重构手法叫你编译测试你就编译测试。


重复上述三个步骤直到找不出坏味道,这时候你再回去看代码,业务逻辑应该就明明白白摆在你面前。


这个过程是纯粹形式化的,与代码的业务逻辑无关。一开始你对坏味道、对重构手法不熟悉,你需要一边翻书一边操作,你会进展比较慢。经过反复的练习,你的速度就会提高。用同样的过程可以重构任何复杂的祖传代码,你不需要先去理解它的业务逻辑。


当然,在重构的过程中,随着代码逐渐变得干净,以及你对代码逐渐熟悉,你已经开始慢慢理解业务逻辑了。并且你还可能发现,有些业务逻辑的实现并不合理,可以用更合理的方式来实现。


还有些时候,你会发现,有些业务逻辑没有被测试充分覆盖,你考虑添加一些测试。


这时你可以暂时放下重构的帽子,戴上开发的帽子。你可以添加一些测试,确保测试覆盖更充分。你也可以对实现代码做一些修改,当然,必须在有测试覆盖的前提下。在今天的视频秀里,我就做了这样的操作。



当你熟悉了“红-绿-重构”的节奏以后,重构的帽子和开发的帽子可以经常切换。没有熟悉之前,不要着急,慢一点,踩稳节奏是关键。




关注公众号“程序员练功房”

重构细节练起来