漫谈重构

　　因为工作内容的原因，我在前后两家公司中的工作中主持和经历了十余次代码和架构的重构，下面随便说说我对重构的一些经验和想法。

　　关于重构

　　首先重构面临的背景都是相似的，程序员们为了快速完成需求和上线而写出了最基本的代码，而在功能的不断扩充过程中，以打补丁的方式对代码进行扩充，中间还会面临着开发人员的变更和离职。逐渐的，代码就会越来越臃肿，渐渐的变得难以维护。

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

　　重构要解决的问题

　　重构不能凭空重构，一定是要解决一个问题，一般情况下重构要解决的问题大致有以下几种。

• 结构糟糕。相信很多码农们，都遇到过接手别人的代码后都感到挠头的事情，五千行以上的文件，三千行以上的函数，面对这样子的代码，对其进行修改和继续开发是件很艰难的事情。

• 安全隐患。很多代码，都只是为了功能上快速完成，而对很多潜在的安全风险置之不管，如内存管理、异常处理、模块接口等。有的雷如果不扫，可能迟早有一天会爆发。

• 性能问题。对于很多大型服务，性能高一点可以节省很多的服务器费用。性能问题主要需要找到核心问题，有的问题出在架构，而大多出代码上。

• 功能扩展。有的模块，开始设计时只是实现一些很基本的功能，而随着产品功能不断增强，被赋予了越来越复杂的功能，到了一定程度，需要进行重构以让其能够实现新赋予的任务。

• 协同开发。很多时候，一个大系统往往需要多个人一起进行开发，如果需要这些人改同一个类甚至同一个函数，往往是冲突不断，而代码的整合往往也会存在更多问题。这时候需要很好的架构能够支持多人的共同开发和修改。

• 模块调试。在一个大系统中，往往有很多子模块互相关联，而假如某个模块的调试需要启动整个大系统，或者会受到其他模块稳定性的影响，对于效率是非常低的。而重构建立调试层或者开发调试工具是更好的选择。

• 模块复用。有些时候，多个系统或算法，可能会用到子算法和子模块，而不同项目或模块重复开发相同功能的子模块，在很多公司都很常见。而很多时候，将一些公共的部分抽象出来，能够将这部分做的更好更精，而从整体上，往往能大幅度提高开发效率和效果，往往也能优化算法性能。

• 算法使用不当。在有些模块中，使用了不恰当的数据结构或者相关算法，使得或者是性能，或者是效果出现了问题。这种情况，甚至要将原有的体系结构推到重来，重新设计算法和数据结构，达到尽可能好的匹配效果。

• 承载规模不够。对于一些系统，都有其设计的容纳规模，例如瞬间访问量、同时在线人数，很多公司从小到大都经历过这个过城，当超过一定量级时，很多时候并非简单通过加服务器能解决，有时需要重新设计架构。就像 12306，因为架构问题使得很难承担过高的瞬时在线人数。

　　重构经验感受

　　重构时，第一道难关是如何过领导这道关。很多领导都要背着产品指标和任务，大多人也更关心其能够在多长时间做出什么，重构这种事情，在很多时候，有可能是“费力不讨好”的代名词，因为在大多情况，无法帮助领导完成指标。这种情况下，如何获得领导的支持就极其重要了。

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

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

　　如果团队规模有一定的人的话，也可以分出一部分进行新型架构的开发，而另一部分人在现有架构上进行改进，使得短期目标和长期目标两不耽误。这时候，值得注意的就是，不管从代码还是设计角度上来看，都要让现有做的事情能够复用，而不是新架构上线之后就会被废掉。

　　如何进行渐进式重构，也是很多架构师需要去思考的问题。就是不搞一下子半年一年的重构，而是以月为单位，快速的迭代，能够很快的看到效果，并且小规模投入使用。

　　不管怎样，重构，一定不能是为了重构而重构，或者对前人的代码看着不爽，或者抱有技术完美主义而进行重构，最重要是找准其要解决的实际问题，这时候的重构，能带来的是开发效率上的提升。

　　而在重构的过程中，也需要做好新架构的设计，并且拥有一定的前瞻性，否则很容易出现新架构、新新架构、新新新架构这样子的事情。另外，也要尽可能的增强代码的复用性，让其中的模块，在任何一个架构中都能够很好的被应用，当然这个要根据具体情况具体分析。

　　对于重构，也尽量不要拥有技术完美主义。很多时候，使用最成熟的方案及最简单的架构模型实现所需要的功能一般来说更加“简单可依赖”，有的时候架构过于复杂反而喧宾夺主，因为所有架构都是为了功能服务的。同时，也尽量不要使用很多未经广泛使用的前沿技术，因为这些在开发和部署过程中，很多都可能会遇到意想不到的问题，延缓开发速度并影响线上效果。

　　此外，作为重构时的负责人，一定要紧跟代码开发的过程，并随时进行指导，一般情况下，不要相信写出糟糕代码的人，经过略加指导就能写出漂亮代码了。我曾经有过这样的经历，要将一个超大的类按照功能进行模块化拆分，设计好了架构及每个子模块就让组员进行开发。开发完了我看代码时登时就抓狂了，模块是拆分了，每个功能也都建立好了子类，并通过主类调用子类，但是每个子类又都将主类作为友元，又去调用主类里面的成员变量和函数。这种代码，再次重构也是难免的，这个给我的经验教训就是，重构的工作一定要做细，迭代中的代码检查也是必不可少的。

　　良好的习惯，从最初做起

　　当然，重构再怎么样，也是一种推翻重做，耽误时间的做法。从我的经验来看，其实大多数的重构都是可以避免的，这需要从以下几个方面去提高。

　　良好的编码风格，好的习惯往往很难是天然形成的，更多是在工作中不断的老带新中耳濡目染练出来的。很多领导希望员工全部时间都用来做项目，不断地去压更多的活，实际上是在用跑短跑的方式跑长跑，很容易出现后劲不足的情况。而我在微软的经历，也让自己感受到了从潮手到逐渐成熟的过程，后来在搜狗时即使再忙没法搞 team review，我也会去尽量给每个组员检查他们的代码，帮助别人去提高。

　　初期的架构设计，这个也是非常重要的。架构设计能不能一次到位，这个不太好说。但是相信好的架构，一定比粗糙的设计能够坚持更长得多的时间。并且好架构可以考虑到未来可能扩充的规模和功能，为未来的发展留好接口。同时在其中所有的模块都非常有序，即使大的框架要修改的话，也只是搭一个架子，原有的子功能和子模块都能够被很好的复用，

　　其实很多时候，代码并非要开发一阵就重构一次，而写出好的架构，也并非是那么难。更重要的是，需要的是不断的提高程序员的自我修养，不仅仅是能力上的，还有态度上的。不要只想最初开发时省事，而不考虑若干时间后的事情。好的架构，对未来的开发以及发展，可以说是真真实实的“事半功倍”。

　　最后，我们看一个关于扁鹊的故事：

　　魏文王曾求教于名医扁鹊：“你们家兄弟三人，都精于医术，谁是医术最好的呢？”扁鹊：“大哥最好，二哥差些，我是三人中最差的一个。”　　

　　魏王不解地说：“请你介绍的详细些。”

　　扁鹊解释说：“大哥治病，是在病情发作之前，那时候病人自己还不觉得有病，但大哥就下药铲除了病根，使他的医术难以被人认可，所以没有名气，只是在我们家中被推崇备至。我的二哥治病，是在病初起之时，症状尚不十分明显，病人也没有觉得痛苦，二哥就能药到病除，使乡里人都认为二哥只是治小病很灵。我治病，都是在病情十分严重之时，病人痛苦万分，病人家属心急如焚。此时，他们看到我在经脉上穿刺，用针放血，或在患处敷以毒药以毒攻毒，或动大手术直指病灶，使重病人病情得到缓解或很快治愈，所以我名闻天下。”

　　扁鹊实际上就是一个很好的重构高手，但是扁鹊的大哥，就是因为能够将问题看在前面，处理在前面，所以能够永葆健康，这更是高手中的高手！