大多数重构可以避免

这篇文章的内容其实是我一直想说的，郭昂写的即全又现实。领导都怕重构的，其实也没并要一开始就大刀阔斧的重构，一般来说可以在实现新功能时就一边重构一边做新的功能。慢慢的，那些旧的过时的代码自然也会被淘汰的。

郭昂在前后两家公司的工作中，主持和经历十余次重构，涉及代码和架构。在他看来，如果不做重构，任代码随意膨胀，就会产生糟糕的架构，其恶劣影响包括：

首先是开发效率的降低，在糟糕架构下加进新功能，会受之前代码的影响，可能存在意想不到的改动点和问题点，开发和调试时间都会大大增加；其次是故障率的提升，在质量低下的代码中，总是容易藏着很多不易发现的坑，这些都会成为故障的隐患；同时，架构也会使得需求的完成大打折扣，使得设计好的目标，因为架构限制或者性能等原因，只能完成80%甚至更低。

接下来，他列出了重构要解决的各种问题：

• 结构糟糕：五千行以上的文件，三千行以上的函数，面对这样子的代码，对其进行修改和继续开发是件很艰难的事情。
• 安全隐患：很多代码，为了快速完成功能，对很多潜在安全风险置之不管，如内存管理、异常处理、模块接口等，迟早有一天会爆发。
• 性能问题：对于很多大型服务，性能高一点可以节省很多服务器费用。性能的核心问题大多在出代码上。
• 功能扩展：有的模块，开始设计时只是实现一些很基本的功能，而随着产品功能不断增强，需要进行重构以让其能够实现新赋予的任务。
• 协同开发：大系统需要多人一起开发，如果需要改同一个类甚至同一个函数，往往是冲突不断，而代码的整合往往也会存在更多问题。这时候需要很好的架构能够支持多人共同开发和修改。
• 模块调试：大系统中有很多子模块互相关联，假如某个模块的调试需要启动整个大系统，或者会受到其他模块稳定性的影响，效率非常低。通过重构建立调试层，或者开发调试工具是更好的选择。
• 模块复用：不同项目或模块重复开发相同功能子模块，在很多公司都很常见。将公共部分抽象出来，能够将这部分做得更好更精，从整体上，往往能大幅度提高开发效率和效果，往往也能优化算法性能。
• 算法使用不当：使用不恰当的数据结构或者相关算法，会使得性能或效果出现问题。这种情况，甚至要将原有的体系结构推倒重来，重新设计算法和数据结构，达到尽可能好的匹配效果。
• 承载规模不够：一些系统有其设计的容纳规模，例如瞬间访问量、同时在线人数，当超过一定量级时，很多时候并非简单通过加服务器能解决，有时需要重新设计架构。

接下来，他总结了自己重构经历的经验和感受，指出“第一道难关是如何过领导这道关”：

很多领导都要背着产品指标和任务，重构这种事情，在很多时候，有可能是“费力不讨好”的代名词，因为在大多情况，无法帮助领导完成指标。

他的建议是：

让重构与某些技术或产品指标挂钩，例如完成新产品、改进效果、提高性能等，相当于是重构伴随着其他改进搭帮上线，那么这种情况可以比较顺利的完成重构。

……

而如果单纯为了架构的合理性而去重构的话，就需要去说服领导，为什么原来的架构会降低开发效率，新做的架构能带来哪方面的提升。一定要让领导明白，这个能带来实实在在的长期收益，不管性能、效率、安全等都可以，而并非只是“看着不爽”而进行的重构。

在团队规模有保证的前提下，郭昂建议可以分工，一部分开发新架构，另一部分进行架构改进，保证长期目标和短期目标都可以落实：

值得注意的就是，不管从代码还是设计角度上来看，都要让现有做的事情能够复用，而不是新架构上线之后就会被废掉。

对于渐进式重构，郭昂建议：

以月为单位，快速的迭代，能够很快的看到效果，并且小规模投入使用。

对于重构中新架构的设计，郭昂指出：前瞻性、复用性、避免技术完美主义、避免使用过多未经广泛使用的前沿技术，这都应该注意。

他认为：重构的负责人非常重要。

作为重构时的负责人，一定要紧跟代码开发的过程，并随时进行指导，一般情况下，不要相信写出糟糕代码的人，经过略加指导就能写出漂亮代码了。……重构的工作一定要做细，迭代中的代码检查也是必不可少的。

在文章最后一部分，郭昂指出：

大多数的重构都是可以避免的，这需要从以下几个方面去提高。

• 良好的编码风格，好的习惯往往很难天然形成，更多是在工作中不断的老带新中耳濡目染练出来的。

• 初期的架构设计，也是非常重要。好的架构，对未来的开发以及发展，可以说是真真实实的“事半功倍”。

• 更重要的是，需要的是不断的提高程序员的自我修养，不仅仅是能力上的，还有态度上的。不要只想最初开发时省事，而不考虑若干时间后的事情。

郭昂文中有一句话可作总结：

不管怎样，重构，一定不能是为了重构而重构，……最重要是找准其要解决的实际问题。