重构—时时勤拂拭，勿使惹尘埃

忙里偷闲，完成了对项目代码两个模块的重构：

• 将CodeGen之前对算子依赖分析的代码提到Pass里；
• 将发射算子的模块由一个类改造为“基类+派生类”的结构，抽象出公共接口，必要时在派生类中覆写虚函数。

重构完成以后，好处是显而易见的。算子依赖分析的pass，逻辑简洁而清晰，并且易于修改和扩展。codegen.cpp文件的代码行数减少了900多行，发射算子的模块也根据硬件特性，搭建了清晰的类关系。顺便地，我也改善了一些变量和函数的命名，抽取了一些工具函数和公共函数。

重构一时爽，但我必须保证重构之后的代码不影响功能，不引入新bug，不影响测试部测试。好在CodeGen模块会输出一个模型文件，我通过工具对比重构前后产生的模型文件是否一致，如果不一致，差异在哪里，再消灭差异。这样，代码的正确性也得到了保证。

提交代码后，我觉得一身轻松，终于完成这项工作了。

因为我早就想去整理代码了。

比如算子依赖分析的代码，要扩展，或者要修复bug的时候，总是难于下手：因为之前的代码逻辑太混乱，分支太多。每次要分析一个问题的时候，总得花时间先捋一捋代码逻辑。

比如算子发射的代码，所有类型的算子都放在一个类里面，导致这个类的庞大而复杂。这明显违背了单一职责原则。初始化这个类时，得给构造函数传入一堆参数，因为这个类要处理的算子类型太多了。每次添加新算子，就得考虑是不是要加接口？还是可以复用现有的？

阻碍我没及时重构的原因有三：

• “还得做其他好多工作呢！哪有时间来重构”！
• 现在是时候重构吗？还是等“适当的时候”再重构？
• 重构会调整已有的结构，可这个模块是我一手搭建开发起来的，重构岂不是意味着我要推翻自己的设计？岂不是意味着今后会经常推翻之前的设计？岂不是意味着这个开发人员很垃圾，在开发之前没有良好的设计？

完成重构以后，是时候来回击这3个借口了。

关于第一点，“没有时间去重构”。其实我已经深刻体会到了，在老代码上耗费的时间更长，而重构后的代码易于理解和扩展，综合下来，重构的时间开销并不大，性价比极高，事半功倍。不过重构之前需要仔细分析代码的结构，上下游接口。

第二点，该什么时候开始重构呢？我看完《重构—改善既有代码的设计》一书后，深受启发。

“时时勤拂拭，勿使惹尘埃”。作者提到，在他编程的每个小时，他都会做重构。这未免有些夸张，但也意味着，并没有什么时间节点预示着你应该着手重构了，改善代码的设计应该是和开发一样，融入日常的工作中。在完成一个feature开发之后，再回头看看，是不是可以优化设计？在修复一个bug后，是不是可以借此优化接口？在开发一个新功能之前，是否可以分离职责、提取接口？

这本书分章节介绍了一些重构的技术要点，不过给我启发最深的，还是书中关于何时重构以及软件设计思想的论述。关于第二点，这种几乎“随时重构”的思想，理论上来说，的确可以使代码设计合理、易于理解和修改、减少垃圾代码。

关于第三点，“重构意味着推翻（或者局部推翻）了软件原有的设计”，这是否意味着最开始的设计不合理？我担心，当周一来临，主管和同事们pull代码时，发现Jungle竟然做了如此大的改动，他们是否会觉得Jungle是个垃圾，最开始设计模块的时候就没想到过这些吗？

现在我打消了这些多余的顾虑。其实从实事求是的角度来说，也不要有这样的顾虑。“好代码的检验标准，就是人们是否能够轻而易举地修改它。重构是为了让代码更容易理解，更易于修改”。这是书中的观点，我深以为然。

另一方面，也许行业陈规认为：“良好的设计必须在开始编程之前完成，因为一旦开始编写代码，设计就会逐渐腐败”。但经历过项目开发和维护工作的coder们都知道，软件设计并不是在一开始就完成的，而是在整个开发过程中逐渐浮现出来。开发过程中时常伴随着需求的变化，伴随着对测试corner case的bug的解决，也时常伴随着上下游接口需求的变化。

我刚入职上一家公司时，组里正好完成了对项目架构的重构，称为“新统一架构”，这直接抛弃了原来的仓库。在已量产项目上做这样的重构，可谓相当有魄力。可即便如此，后来各个项目修复bug时，仍旧在新统一架构上缝缝补补。当我离职时，项目代码上充斥着各种针对不同项目的配置文件和宏开关。为顺利完成交接，我还搭配了一个文档，来说明哪个项目对应哪个甚至哪几个宏。

时时勤拂拭，勿使惹尘埃。一个重要的前提是，得保证重构后不影响正常的功能，不引入新的bug，且重构后的代码真的得到了改善。否则，就遵循那句古老的谚语“如果它还可以运行，就不要动它！”