最近准备推动团队产品进行代码重构，过程中遇到一些问题与困难，由此也回想起早年经历过的一些重构，其中有些并非我主导，在此简单记录，主要谈其中印象深刻的体会，不展开。
第一次重构
我刚参加工作不久，进入了一个刚刚重组成立的项目组，我们接手时前面的人都已经离职了，一个不剩，就是这么任性，当时的代码是用 C++ 写的，而且比较混乱，难以维护，当时的老大决定用 C# 将项目重写, 于是带领我们进行了我职业生涯的第一次重构。重构的目的主要是希望优化设计，减小维护成本。印象深刻的是在重构之前，老大让我跟他一起画了一个看起来巨牛逼的重构设计图，其中引入了各种不明觉厉的设计模式，今天回想起来只能用过度设计来形容了，实际上最后非但没有减小维护成本，反而因为引入了一些复杂的设计模式，导致代码层次深性能差，难以理解。随着最初主导设计人员的离职，框架开始崩坏，后续越来越难以维护，到最后不得不面临再次被重构。
第二次重构
这次的重构由公司里一位非常优秀的工程师来主导，也正是他直接指出之前过度设计的问题，提出了一套更加简单清晰的设计方案，设计本身是业内经典架构，并没有太大问题，最后也是顺利完成，但重构后的代码并没有坚持太久，又开始逐渐腐化，根本原因还是在于各种程序员的代码水平参差不齐，项目里太多低质量的代码，又没有code review 来保障质量。我的感受是光靠架构设计本身，并不能解决所有问题，代码腐化是发生在产品演进迭代过程中的，好的架构不是银弹，只关注宏观结构不注重细节质量必然也是不行的。
第三次重构
这次我们面临了新的复杂业务的需要，同时也引入了一位新的、比较纯粹的架构师，意思是基本只负责架构设计与架构实现，在实际重构过程中，还是发现了一些问题：架构师有自己的架构理想，希望将自己多年的架构经验付诸到具体的业务里，验证自己的想法，因此这次又产生了过度设计的老问题，而且比之前还要严重，每当问及他这里为何要如此复杂设计？理由都是将来这里可能会怎样变化云云，咋一看挺有道理，而实际上很多担心过的变化直到我与他都离开也从未发生过；除却过度设计，他当时的一些设计观点现在看来也有些陈旧过时，应该跟他之前的从业经历有关，每个人都可能受自身背景的局限，唯有不断学习与了解各种业内新知识，与大家多交流，才能突破自身技术视野的狭窄。
第四次重构
这次是我自己主导，主要是针对新业务的扩展需要，对现有代码进行调整，其实并没有大的架构调整，除了对代码的整体结构整理，都是一些局部代码的调整，以满足业务的扩展需要，同时对以前的一些痛点针对性调整，完成后确实也达到了部分目标，但仍然遗留了很多问题没有解决。这次的主要收获是，重构前要有明确的要解决的目标，针对目标设计方案，不要为了重构而重构，追求完美心态的重构。当然也有一些教训，重新认识到自己能力有限，看了很多这方面的书，还是没能做好，低估了其中的困难，也没能从整体上进行规划，代码已经过于庞大，也是畏惧大改，深怕陷进去，一些陈旧的不好的代码模版仍然被保留，甚至还引入了一些新的坑。
在迭代中重构
以上是我职业生涯经历过的一些印象深刻的大规模重构，越到后面，越发明白等到技术债务欠到一定程度，需要进行完全推翻重来的重构，是一件多么困难的事情，除非有足够的资源与支持，否则风险极高，也未必能做好，因此个人的建议是重构必须随时进行，在每个迭代中进行，在很多重构相关的书里都提到过这点，但真正能做到的人不多，每次我们要开发新功能，一旦涉及到代码里的技术债务，就尽量设法一并处理掉，这样你不仅做完了新功能，同时也还清了一个技术债务，是我认为比较理想的重构方式，当然这需要我们在开发时为此预留足够的时间，最终能否可行，取决于团队以怎样的态度看待技术债务，在技术改进与业务推进之间做出权衡。
