共计 3036 个字符，预计需要花费 8 分钟才能阅读完成。
🤫 关注 Zilliz 微信公众号并回复「重构」🤫
获取《重构：改善既有代码的设计》超具体思维导图
尽管代码还是能够跑，然而各种规定越来越简单、外围继承体系越来越凌乱、零碎的保护工作越来越重……
1999 年，Martin Fowler 作为技术顾问造访了一个我的项目，他倡议项目经理好好整顿这些乱哄哄的代码。然而，项目经理示意：🙏算了吧🙏
六个月后，这个我的项目宣告失败，因为代码太简单难以调试，性能也达不到要求。
这件事给 Martin 留下很深的印象，随后，他写下了《重构：改善既有代码的设计》。
《重构》出版 22 年后，已成为软件开发畛域不可代替的经典。这本书解释了重构的原理和最佳实际形式，并给出了批改代码的动机和具体案例，值得重复消化咀嚼。
这本书还凝聚了多位软件开发领域专家的贵重教训：摩根大通架构师 Bill Opdyke 在第 13 章记述他将重构技术利用到商业开发过程中的一些问题；软件开发方法学泰斗 Kent Beck 和 Don Roberts 合写了第 14 章，瞻望重构技术的将来——自动化工具；Kent Beck 还写了最初一章，总结如何学习重构。
你将从这本书中取得：
- 了解什么是重构、为什么要重构、何时重构，了解
- 了解重构准则：一次一小步地批改代码并屡次测试
- 实操演练重构的动机和办法，使既有代码更易了解、晋升软件的可维护性
无论你是软件工程师还是产品经理，都须要翻一翻这本经典；而零碎设计师和架构师则更有必要理解重构原理，依据须要在本人的我的项目中使用重构技术、优化零碎性能。
💡 小编揭示，这本书中第一版的案例语言应用 Java，第二版的语言应用 JavaScript。总体而言，作者展现的重构手法在各种支流的面向对象语言中基本上都能够通用。
为何重构？
第二章中，作者具体介绍了重构的价值。重构不仅能够改良软件设计自身的缺点、帮忙找到 bug、晋升开发速度，还能够使软件更容易被了解——这是因为，程序设计很大水平上是人与计算机、人与人的沟通。
Martin Fowler 曾提及，任何一个傻瓜都能写出计算机能够了解的代码，唯有能写出人类容易了解的代码的，才是优良的程序员。
所谓程序设计，便是与计算机交谈。你编写代码通知计算机做什么事件，它的响应则是依照你的批示口头。你得及时填补「想要它做什么」和「通知它做什么」之间的缝隙。这种编程模式的外围就是「精确说出我想要的」。除了计算机之外，你的源码还有其余读者。计算机是否多花了几个小时来编译，又有什么关系呢？如果一个程序员破费一周工夫来批改某段代码，那才要命呢——如果他了解了你的代码，这个批改本来只需一小时。……而很多时候，那个将来的程序员就是我本人。
《重构（第 2 版）》译者熊节也曾谈到，「编程其实是个社会活动」。
一方面，程序员要把自然语言说进去的需要翻译成机器能运行的机器语言；另一方面，翻译进去的后果（也就是代码）还要撑持团队（包含技术和非技术的团队）一直地在它根底上合作和交换。……编程的大挑战不是把代码写进去，而是要在代码的根底上建设无效的多方沟通。
那么，咱们 何时须要重构？书中第三章列举了一些「代码的坏气息」。「坏气息」指的是代码中某些不完满之处，开发人员能够通过这些细节上的征兆在代码中追捕到更大问题。小编不禁联想到了《Clean Code》中的「好气息」和「坏气息」。
一个重构案例
家喻户晓，重构有危险，挖坑需谨慎。如果重构形式不失当，危险反而更大。
试想一下这样的状况：你开掘本人的代码，很快就发现了一些能够批改的中央，于是你挖得更深。挖得愈深，能够批改的中央就愈多……最初，你给本人挖了一个大坑，再也爬不进来了。
为了防止掉进坑里，重构必须依照肯定的准则和办法进行。
作者在第 5 – 12 章给出了一个重构列表，每一个重构案例都写明了重构实用的情景、动机、重构办法。让咱们来看一个案例吧：
Extract Method（提炼函数）
你有一段代码能够被组织在一起并独立进去：
void printOwing(double amount) {printBanner();
//print details
System.out.println ("name:" + _name);
System.out.println ("amount" + amount);
}将这段代码放进一个独立函数中，并让函数名称解释该函数的用处：
void printOwing(double amount) {printBanner();
printDetails(amount);
}
void printDetails (double amount) {System.out.println ("name:" + _name);
System.out.println ("amount" + amount);
}这样做的动机：
函数应该简短而有的良好命名。起因如下：
- 首先，如果每个函数的粒度都很小，那么函数之间彼此复用的机会就更大；其次，这会使高层函数码读起来就像一系列正文；再者，如果函数都是细粒度，那么函数的覆写也会更容易些。
- 如果提炼动作能够强化代码的清晰度，那就去做，就算函数名称比提炼进去的代码还长也无所谓。
重构办法
- 发明一个新函数，以它「做什么」来命名，而不是以它「怎么做」命名
- 将提炼出的代码从源函数拷贝到新建的指标函数中
- 仔细检查提炼出的代码，看看其中是否援用了「作用域限于源函数」的变量（包含局部变量和源函数参数）
- 查看是否有「仅用于被提炼码」的长期变量，如果有，则在指标函数中将它们申明为长期变量
- 查看被提炼码，看看是否有任何局部变量的值被它扭转。如果一个长期变量值被批改了，看看是否能够将被提炼码解决为一个查问，并将后果赋值给相干变量。如果很难这样做，或如果被批改的变量不止一个，你就不能仅仅将这段代码一成不变地提炼进去。你可能须要先应用 Split Temporary Variable 办法，而后再尝试提炼。也能够应用 Replace Temp with Query 将长期变量毁灭掉。
- 将被提炼码中须要读取的局部变量，当作参数传给指标函数
- 解决完所有局部变量之后，进行编译
- 在源函数中，将被提炼码替换为「对指标函数的调用」
- 如果你将任何长期变量移到指标函数中，请查看它们本来的申明式是否在被提炼码的外围。如果是，当初你能够删除这些申明式了
- 编译，测试
随后，作者给出了无局部变量、有局部变量、对局部变量再赋值三种范例，手把手解释如何提炼函数。
更多资源
这本书第 5 – 12 章是一份「重构列表」，有些概念比拟形象。为了更好地了解列表的内容，小编举荐 Refactoring Guru 这个网站，网站上不仅有许多对于重构的理论解释，还介绍了罕用的设计模式和设计准则。这个网站能够帮忙你用简略便捷的形式迅速把握重构的理念、学习各个设计模式。
想要理解更多具体内容？关注 Zilliz 微信公众号并回复书名「重构」
即可取得小编整顿的《重构：改善既有代码的设计》高清思维导图。
积攒代码量很重要，
读书、读好书也很重要。
「Zilliz 好书举荐」栏目，
旨在与你分享技术成长相干的书籍，
与你一起先把书读厚，再把书读薄。
——————————————————————————
Zilliz 以从新定义数据迷信为愿景，致力于打造一家寰球当先的开源技术创新公司，并通过开源和云原生解决方案为企业解锁非结构化数据的暗藏价值。
Zilliz 构建了 Milvus 向量数据库，以放慢下一代数据平台的倒退。Milvus 数据库是 LF AI & Data 基金会的毕业我的项目，可能治理大量非结构化数据集，在新药发现、举荐零碎、聊天机器人等方面具备宽泛的利用。