在Coding上，重构是一个不可避免的问题，本文结合个人经历和同事对话，对重构做一个总结
前两天，在公司论坛看到一个问题：
重构代码的好坏有什么评价标准吗？
我们为什么要重构代码？
在回答上面那位同学的问题前，也许更应该思考一个问题：我们为什么要重构代码以及选择开始重构代码的时机？
重构代码的原因有以下几个：
①代码风格的统一
随着IT行业越来越完善，在代码规范上，各个公司的态度越来越趋于一致：要有自己的Style Check，这是保证代码健壮性、可阅读性的有力保障措施，所以当一份超大圈复杂度，臃肿不堪的代码呈现在眼前时，重构这个概念自然就出来了，clear code也是代码重构的一个重要意义。
②业务需要
如果现有系统已经不能满足业务场景需要，那似乎可以行的通的道路就只有重构一条。我现在所经手的一个项目，主要就是因为这个原因开始了重构之路，前前后后花了4700余万，并且还在持续迭代中。
选择重构的时机：
是不是一份看起来有坏味道代码在眼前时我们就需要选择重构？答案当然是否定的！重构的代价是很大的，没有谁可以随随便便拍板说：这个代码不行不好看，我们要重构！
选择重构的时机应当是：从长期看，当后续代码改动较大，后续改动过程中的带来的维护成本大于重构成本时，此时就需要重构，即到了选择重构的时机。一句话总结就是长远收益大于当前重构成本，如果代码后续的改动不大，自然没必要去重构。
重构代码有什么评价标准？
就现在业内而言，实际上对于重构后代码并没有统一的评价标准，当然，就Style而言，大型公司都有自己的检测工具，通过检测后能够作为评价的一部分依据。
其他维度上，可以给自己提一些疑问：重构后，开发者测试（ LLT/ DT）是不是真的更好做了？模块间的耦合是不是更少了？接口传递的信息有没有更精简？一个好的重构，相关部分的 LLT，打桩应该会更少，数据应该会更好构造。如果这些效果达到了，至少说明还是有些重构效果，如果只是应付了些圈复杂度等指标，一般情况下，不会有啥改善。
如何重构（对函数的拆分)？
重构分为单人开发项目和团队开发项目，如果是单人项目，就不要搞这么多微服务。多个服务整合到一个单体应用里面拉到。毕竟，微服务是跟组织架构匹配的。一个人就是一个组织，最好就负责一个应用（服务）。
重构是分颗粒度的，包含架构的重构、类和代码块的重构。可以先从小的类、代码块重构开始。等到熟悉整个架构，则可以介入架构的重构。千万不要随意去动你不熟悉的代码。
函数到底多大才应该拆分？
首先，我们应该明确什么样的函数需要拆分这个问题，是因为它是巨函数吗？那巨函数到底要多少行代码为标准呢？是1000行，100行，还是10行，甚至5行？这是一个没有正确答案的问题。那我们拆分函数的原则是什么呢？事实上，这便是 Unix的设计哲学： SRP，单一职责原则。 Do One thing， Do it Well.这样便不会需要依据多少行作为拆分函数的依据。但是，依据 SRP原则拆分函数，往往得到小函数。怎么拆分函数函数拆分遵循什么实现模式呢？ Kent Beck建议使用 Compose Method的实现模式分解巨函数； Martin Flower也建议应用 Extract Method的重构手法提炼函数，两种方法殊途同归，是一种分解巨函数的有效方法。 Extract Method最重要的就是识别出代码中的抽象层次，并梳理出主干并按照自顶向下的规则实现函数的。我的经验依据几条简单的规则：
- 实现对称性
正如 Bob大叔提到的那样，程序就像是一系列的段落，每一段落都描述了当前抽象层次的逻辑，并引用下一抽象层次的段落。
- 过度防御式编程
过度的防御式编程，常常导致无谓的前置条件判断。事实上，错误处理需要划分信任边界，边界处校验是必须的，这个应该可以达成共识。但信任边界内，往往是没有必要的做过多的校验。否则，不仅代码可读性下降，其次导致性能下降。另外，错误处理有时应该借助于设计。我推荐大家阅读
“预防大于治疗”https://www.jianshu.com/p/718fe24c3a35，
这篇文章内包含了很多错误处理的哲学和方法。
- 拆分函数的可读性
拆分函数后，可能存在很多小函数。虽然每个小函数都很小，但总感觉只见树木，不见森林的感觉。之所以有这个问题，我个人觉得有如下原因。很多人特别习惯于大函数，非常不习惯于回调，接口，抽象等编程思维。事实上，抽象往往是软件设计的魅力所在，也是组合式设计的重要源泉；缺失领域模型的牵引，函数虽然变小了，但终究失去载体，造成缺失领域概念来归纳和整理相关函数；没有将函数名取好。我特别建议多和周围的同事多交流，多查字典，必然会得到一个很好的领域名称；需要刻意训练重构技能，这个只能靠自己了，没有捷径。
- 收发自如
重构是一项实践性的工程技术，通过合理地应用一系列重构手法，安全地、小步地、高效地完成代码修改。在重构过程中，应遵从最基本的重构原则：等价替换，过程可逆，随时终止，断点续传。如果我们发现自己不能随时终止，断点续传，建议大家下来做一些小练习，提高重构技能，然后在真实项目中锻炼成长。
- 重构过程
任何优秀的程序员，都会对设计的坏味道保持敏感的嗅觉。当出现违背简单设计四个基本原则的坏味道时，则编排一系列安全的、小步的重构手法，高效地完成代码修改，使其设计逐渐靠近简单设计的四个基本原则，做到以始为终。因此，支撑重构背后的价值观和原则是最重要的。如果没有软件设计的正确价值观和良好设计原则，则会导致重构本身也是一种高成本、低收益的活动。这会导致重构既有的代码从一种风格到另一种风格，或将他人的风格重构为自己的风格，其本质并没有改善设计本身。因此，重构的基础是软件设计，价值观和原则是实践重构最本质的基础。
如何锻炼重构技能？
想提高重构或任何其他技能的方法都是一样的：
1、多练手，在实践中总结和提高，注意不是仅仅重复劳动层面的，也不是应付了事层面的，公司很多人写了很多年代码还是那个水平，就是按这两种思路做事的后果。正确的是要在练的过程中应用书上学到的新知识，要自我严格要求，做到自己能做到的最好，这样经过几次反复（做到最好->发现存在的问题->继续改进到自己认为的最好->再发现问题->再解决）就会对一些知识有深刻的认识。
2、多跟高手一起练手，自己闷头干往往进展很慢，因为很多好东西你都不一定知道，跟高手一起工作，向高手学习，甚至先模仿高手的做法然后出现问题再想办法改进，能少走很多弯路。
评论区