代码的坏味道和重构

时间 2019-12-06

标签代码味道繁體版

原文原文链接

:notebook: 本文已归档到：「blog」html

第一次读《重构:改善既有代码的设计》时，我曾整理过一个简单的笔记。最近，由于参与一个重构项目，再一次温习了《重构:改善既有代码的设计》。过程当中，萌发了认真总结、整理重构方法的冲动，因而有了这系列文字。git

代码的坏味道还有几篇没有完稿，后面我会陆续补充。。。github

症与药

对代码的坏味道的思考

“有病要早治，不要放弃治疗”。多么朴素的道理，人人都懂。数据库

病，就是不健康。编程

人有病，能够经过打针、吃药、作手术来进行治疗。设计模式

若是把代码的坏味道（代码质量问题）比做病症，那么重构就是治疗代码的坏味道的药。安全

我的认为，在重构这件事上，也能够应用治病的道理：架构

防病于未然。 —— 春秋战国时期的一代名医扁鹊，曾经有个很著名的医学主张：防病于未然。我以为这个道理应用于软件代码的重构亦然。编程前要有合理的设计、编程时要有良好的编程风格，尽可能减小问题。从这个层面上说，了解代码的坏味道，不只仅是为了发现问题、解决问题。更重要的做用是：指导咱们在编程过程当中有意识的去规避这些问题。并发
小病不医，易得大病。 —— 刘备说过：“勿以善小而不为，勿以恶小而为之”。发现问题就及时修改，代码质量天然容易进入良性循环；反之，亦然。要重视积累的力量，别总觉得代码出现点小问题，那都不是事儿。框架
对症下药。 —— 程序出现了问题，要分析出问题的根本，有针对性的制定合理的重构方案。你们都知道吃错药的后果，一样的，瞎改还不如不改。
忌猛药 —— 医病用猛药容易产生反作用。换一句俗语：步子大了容易扯着蛋。重构若是大刀阔斧的干，那你就要有随时可能扑街的心理准备。推倒重来不是重构，而是重写。重构应该是按部就班，步步为营的过程。当你发现重写代码比重构代码更简单，每每说明你早就该重构了。

重构的原则

前面把代码质量问题比做病症，而把重构比做药。这里，咱们再进一步讨论一下重构的原则。

何谓重构(What)

重构（Refactoring） 的常见定义是：不改变软件系统外部行为的前提下，改善它的内部结构。

我的以为这个定义有点生涩。不妨理解为：重构是给代码治病的行为。而代码有病是指代码的质量（可靠性、安全性、可复用性、可维护性）和性能有问题。

重构的目的是为了提升代码的质量和性能。

注：功能不全或者不正确，那是残疾代码。就像治病治不了残疾，重构也解决不了功能问题。

为什么重构(Why)

翻翻书，上网搜一下，谈到重构的理由大致相同：

重构改进软件设计
重构使软件更容易理解
重构帮助找到 bug
重构提升编程速度

总之就是，重构能够提升代码质量。

什么时候重构(When)

关于什么时候重构，我先引用一下重构并不是难在如何作，而是难在什么时候开始作一文的观点。

对于一个高速发展的公司来讲，中止业务开发，专门来作重构项目，历来就不是一个可接受的选项，“边开飞机边换引擎”才是这种公司想要的。

咱们不妨来衡量一下重构的成本和收益。

重构的成本

重构是有成本的，费时费力（时间、人力）不说，还有可能会使原本正常运行的程序出错。因此，不少人都抱着“不求有功，但求无过”的心理得过且过。

还有一种成本：重构使用较新且较为复杂的技术，学习曲线不平滑，团队成员技术切换困难，短时间内开发效率可能不升反降。

可是，若是一直听任代码腐朽下去，技术债务会愈来愈沉重。当代码最终快要跑不动时，架构师们每每仍是不得不使用激进的手段来治疗代码的顽疾。可是，这个过程一般都是很是痛苦的，并且有着很高的失败风险。
重构的收益

重构的收益是提升代码的质量和性能，并提升将来的开发效率。可是，应当看到，重构每每并不能在短时间内带来实际的效益，或者很难直观看出效益。而对于一个企业来讲，没有什么比效益更重要。换句话说，没有实际效益的事，一般也没有价值。不少领导，尤为是非技术方向的领导，并不关心你应用了什么新技术，让代码变得多么优雅等等。
重构的合适时机

从以上来看，重构实在是个吃力不讨好的事情。

因而，不少人屈服于万恶的 KPI 和要命的 deadline，一边吐槽着之前的代码是垃圾，一边本身也在造垃圾。

可是，**重构本应该是个渐进式的过程，不是只有伤筋动骨的改造才叫重构。**若是非要等到代码已经烂到病入膏肓，再使用激进方式来重构，那必然是困难重重，风险极高。

《重构》书中提到的重构时机应该在添加功能、修复功能、审查代码时，不建议专门抽出时间专门作重构项目。

我认为，其思想就是指：重构应该是在开发过程当中实时的、渐进的演化过程。
重构的不恰当时机

可是，这里我也要强调一下：不是全部软件开发过程都必定要重构。

较能凸显重构价值的场景是：代码规模较大、生命周期还较长、承担了较多责任、有一个较大（且较不稳定，人员流动频繁）团队在其上工做的单一代码库。

与之相反，有一些场景的重构价值就很小：
- 代码库生命周期快要走到尾声，开发逐渐减小，以维护为主。
- 代码库当前版本立刻要发布了，这时重构无疑是给本身找麻烦。
- 重构代价过于沉重：重构后功能的正确性、稳定性难以保障；技术过于超前，团队成员技术迁移难度太大。

如何重构(How)

重构行为在我看来，也是能够分层级的。由高到低，越高层级难度越大：

服务、数据库现代软件每每业务复杂、庞大。使用微服务、数据迁移来拆分业务，下降业务复杂度成为了主流。可是，这些技术的测试、部署复杂，技术难度很高。
组件、模块、框架组件、模块、框架的重构，主要是针对代码的设计问题。解决的是代码的总体结构问题。须要对框架、设计模式、分布式、并发等等有足够的了解。
类、接口、函数、字段《重构》一书提到了**“代码的坏味道”**以及相关的重构方法。这些都是对类、接口、函数、字段级别代码的重构手段。因为这一级别的重构方法较为简单，因此可操做性较强。具体细节能够阅读《代码的坏味道》篇章。

前两种层级的重构已经涉及到架构层面，影响较大，难度较高，若是功力不够不要轻易变更。因为这两个层级涉及领域较广，这里不作论述。

此处为分割线。下面是代码的坏味道系列。。。

代码的坏味道

《重构:改善既有代码的设计》中介绍了 22 种代码的坏味道以及重构手法。这些坏味道能够进一步归类。我总以为将事物分类有助于理解和记忆。因此本系列将坏味道按照特性分类，而后逐一讲解。

代码坏味道之代码臃肿

代码臃肿(Bloated)这组坏味道意味着：代码中的类、函数、字段没有通过合理的组织，只是简单的堆砌起来。这一类型的问题一般在代码的初期并不明显，可是随着代码规模的增加而逐渐积累（特别是当没有人努力去根除它们时）。

代码坏味道之滥用面向对象

滥用面向对象(Object-Orientation Abusers)这组坏味道意味着：代码部分或彻底地违背了面向对象编程原则。

代码坏味道之变革的障碍

变革的障碍(Change Preventers)这组坏味道意味着：当你须要改变一处代码时，却发现不得不改变其余的地方。这使得程序开发变得复杂、代价高昂。

代码坏味道之非必要的

非必要的(Dispensables)这组坏味道意味着：这样的代码无关紧要，它的存在反而影响总体代码的整洁和可读性。

代码坏味道之耦合

耦合(Couplers)这组坏味道意味着：不一样类之间过分耦合。

扩展阅读

参考资料

重构——改善既有代码的设计 - by Martin Fowler
https://sourcemaking.com/refactoring