关于代码重构的一些常见问题思考

有很多人反馈了重构相关问题。本文结合我6年时间的重构经验，简单的给出我的一些想法，供参考。回答很浅显，欢迎拍砖。

问题1：实际工作中，老代码缺少测试覆盖，以及当前现有代码场景分析不清的情况，如何破局？

答：针对测试覆盖不全情况，尤其开发者测试，唯一要做的就是补齐用例，这个没有捷径。但是针对场景不清，如何保证场景不遗漏，办法貌似也不多，只能看懂代码。如果代码也看不懂，和SE，项目组兄弟讨论。我们当前的场景非常复杂，以及很多代码非常晦涩，一个函数300行，花2，3个小时也看不懂，或者MDE也经常讲不明白，到底这个代码在做啥。只能真正搞清楚我们的代码现状，经常变化的地方在哪里，我们才能启动重构，没有捷径。

问题2：如何对一个项目做好架构，好的架构的主要特征有哪些？

答：架构这个词在很多地方都有，如果这里的架构是说几万以内的代码规模，我感觉，多用一些设计模式，设计方法，就能解决。如果是几十万或者以上的代码。那么飞虎队一直推荐使用4+1架构设计方法进行设计，主要包括：逻辑架构，运行架构，开发架构，部署架构，外加数据架构。推荐看温昱的《一线架构师实践指南》。

问题3：如何消化重构带来的工作量?

答：公司提出了现有产品，预留20%的工作量作为重构输入，但是在实际运作中，其实很难保证20%的专人投入，原因大家都明白。既然在保证不了的情况，作为一名有追求的committer，我们不能看着代码不管吧。我现在的团队做法可以参考，每个PL组，每个月在开发过程中，重构相关代码1K，全员参与，每人大概一个月100行。即不需要落需求管道，也让所有员工养成随时重构代码的习惯，我们运作了几个月，效果还是比较明显。当然这种重构很多都是函数层面，如果涉及到几K以上，需要设计重构，那么还是需要说服你的主管，落入需求管道。

本文系转载，作者：HW-ZT