什么是重构
什么是重构
在不改动代码外在行为的前提下，对代码做出修正，以改进程序的内部结构。
重构对功能的影响
重构不是代码优化，重构注重的是进步代码的可了解性与可扩展性，对功能的影响可好可坏。
评价是否需求重构
假如需求给程序增加特性，但因为代码缺少杰出结构而难以更改，那能够先重构使其易于修正。
是需求的改动使重构必要，假如代码正常运转，不会再被修正，那彻底能够不去重构。
重构的第一步
保证行将修正的代码具有一组可靠的测验。
重构的进程
分小步走，每修正一小步，从头编译、测验、提交。
营地规律
保证你离开时的代码库一定比来时更健康。
重构的准则
了解重构
重构(名词)：对软件内部结构的一种调整，意图是在不改动软件可调查行为的前提下，进步其可了解性，降低其修正本钱。
重构的关键在于运用很多细小且保持软件行为的步骤，一步步达到大规模的修正。
两顶帽子
代码开发进程中两种截然不同的行为，增加新功能和重构。
不应该常常变换帽子，每次只应该专心于其间一项作业。
为何重构
重构改进软件的规划
假如没有重构，程序的内部规划(或许叫架构)会逐渐腐败蜕变。
当人们只为短期意图而修正代码时，他们常常没有彻底了解架构的整体规划，所以代码逐渐失去了自己的结构。
代码结质量的蜕变具有累计效应、破窗效应。
重构使软件更简略了解
合理的重构能让代码**“自解释”**。
比让计算机读懂代码更难的是，让“人”读懂代码。
重构帮忙找到bug
深化了解代码的所作所为，并立即把新的了解反映在代码当中，在这个进程中，bug自然会被发现。
重构进步编程速度
不同质量的规划，随着功能累计，增加新功能所需的时刻。
需求增加新功能时，内部质量杰出的软件让我能够很简略找到在哪里修正、怎么修正。杰出的模块区分使我只需求 了解代码库的一小部分，就能够做出修正。假如代码很清晰，我引进bug的可能 性就会变小，即使引进了bug，调试也会简略得多。抱负情况下，我的代码库会逐渐演化成一个渠道，在其上能够很简略地结构与其范畴相关的新功能。
“规划耐久性假说”：经过投入精力改进内部规划，我们增加了软件的耐久性，然后能够更长时刻地保持开发的快速。
何时重构
见机行事的重构
预备性重构:让增加新功能更简略
重构的最佳时机就在增加新功能之前。
帮助了解的重构:使代码更易懂
当代码难以了解，使用重构来帮助了解。
捡废物式重构
在日常开发进程中，对不好的实现，经过重构进行整理。
项目方案上没有专门留给重构的时刻，绝大多数重构都在做其他事（增加新功能或许修正bug）的进程中自然发生。
优异的程序员知道，增加新功能最快的办法往往是先修正现有的代码，使新功能简略被加入。
有方案的重构
问题在某个区域逐渐累积长大，终究需求专门花些时刻来处理。
别离重构和增加新功能的提交是比较有益的作业方式。
大规模的重构只在必要的时分进行，更推荐的办法仍是随时随地重构作业相关的代码。
Branch By Abstraction
假如要替换掉一个正在使用的库，先引进抽象层，兼容新旧两个库的接口
Code Review时重构
和原作者一起结对编程，经过CR进程中提出的重构主张，进步代码的质量。
何时不应该重构
- 代码不需求被了解和修正时。
- 重写比重构简略时。
重构的挑战
推迟新功能开发？
重构的仅有意图就是让我们开发更快，用更少的作业量创造更大的价值。
有时分需求取舍，增加的功能很小但是需求做很大规模的重构时，能够先增加新功能。
代码所有权
推荐团队代码所有制，而不是细粒度的强代码所有制。
版本操控问题
怎么处理在阻隔的分支，集成回主线，需求处理很多抵触的问题。
选用继续集成（CI），基于骨干开发的办法，每天至少向主线集成一次，保证主线随时处于健康状况。
测验
“不会改动程序可调查的行为”，要求代码应该有一套齐备的测验套件，而且运转速度要快，能在一步小的重构后，立刻验证程序的正确性。
重构、架构和YAGNI
一开始就完结完美的架构规划是不可能的，当具有重构的时分，我们能够做简略规划（也称增量式规划或许YAGNI）。
只依据当时的需求来结构软件，一起把软件的规划质量做得很高。随着对用户需求的了解加深，我会对架构进行重构，使其能够应对新的需求。
重构与软件开发进程
灵敏开发的三大实践
- 自测验代码
- 继续集成
- 重构
重构与功能
短期看来，重构的确可能使软件变慢，但它使优化阶段的软件功能调优更简略，终究仍是会得到好的作用。
功能优化的进程：度量->发现功能热门->去除热门。
大多数程序的功能都消耗在一小部分的代码上，要先对程序有清楚的了解，不要经过臆想进行功能优化。
