小到一个函数名的修改，大到整个项目架构的调整，广义角度来讲都可被算做是重构。虽然大多数的理解后者才可被算作重构，前者只能算作修改...
1、如何看待重构
当我看了重构二字的时候，想到的并不是看结构混乱，注释全无的代码的痛苦感觉，修改代码的不堪过程，而是下面的两个故事，我觉得可以反映很多程序员的故事...
1.1 打碎牙往肚子里咽
这是一件发生在中午吃饭电梯里的事情。
A程序员：最近那个需求我想着抽两天“重构”一下，要不然这样下去，之后特别不好改B程序员：重构肯定是要重构的，但排期怎么办A程序员：这也是我担心的事情，重构这个事情不像性能优化，有指标，有数据看得见。我们为重构排了两天 时间，产品肯定不同意，因为看不出产出。这件事就挺闹心...
1.2 自己的排期，自己争取
需求：某页面有块数据看板，现在这块数据看板有些属性不再展示，同时新增加的另一个页面也用到了类似的数据看板，但展示规则，属性不同
我当即决定重构这一块的代码，数据看板组件内的那堆if，else对我而言没有任何帮助，梳理起来还麻烦。数据看板的作用仅仅是展示罢了，我只要弄明白有几种展示形式，便可在正确接收到组件外的数据时候，正确显示，并且将组件提供给他人使用（另一个页面）但是PMO觉得我的排期有些多
PMO：这个数据看版都现成的，你为什么排了这么久我：现如今的展示逻辑和之前完全不一样，我需要重新梳理PMO：我理解的这都是现成的，只是改几个显示的数据我：准确的说，我是将这一块重写...(将之前数据封装在组件内，现在外部传入说了一遍)，而且我封装好这个，另一位伙伴直接可以用，基本不占用排期，同时我们也节省了一部分梳理之前逻辑的时间PMO：那为什么之前就不封装呢我：因为之前不是我写的（有点小狂）
看完上面的故事，不要忙着得出这样或那样的结论。请带着以下的问题
面对一个项目，什么时候你有了重构的想法？
重构是否就意味着代码质量差？
如何避免重构？
如何弱化重构的后果？
2、什么时候应该重构（代码片段）
我们举这样一个例子程序员A
margin-left: 12px;
程序员B
margin-left: 12px;margin-right: 13px;
程序员C
margin-left: 12px;margin-right: 13px;margin-bottom: 14px;
程序员D
margin-left: 12px;margin-right: 13px;margin-bottom: 14px;margin-top: 15px;
假设有A～D四个程序员，每个人写代码，都发现前一个人的功能和自己差不多，都去Ctrl+CV抛开margin对你的思维影响，我们将margin比做一个类或者是代码片段。面对重复率如此高的代码，你会在第几次重构代码。或者指责哪几位程序员。
肯定有人要说A，B程序员的问题。A程序员的代码，没有提前写好可复用性的代码
margin-left: 0 0 0 12px；说一千，道一万，都是根基没打好。但是很多时候，面对一个简单需求根本没必要考虑那么多，费时，费力，可能项目停止维护，都不会再修改这个地方的代码。
B程序员本来是有机会改的。可有时候为了赶项目进度，又或者因为懒，为了代码看起来简单明了，省事省力，如此做，也无可厚非。
这么来看，最后的机会本应该是C，但是他贯彻了一贯的省事省力，将这段代码推向的深渊，纵然C之后的都有锅，但是最应该挽救的人应该是C。
有再一，再二，没有再三。这个理论，我认为代码届依旧适用。不论是别人写的，还是自己写的，一段代码你用修修补补都两次，重构就应该被提上日程。
重构这件事本身没有一个严格的标准，如果非要找一个标准，那么就是一段代码已经被修改了两次，或者一段代码已经被复制了两次。
3、重构未动，测试先行
面对一个需要重构的项目，一段需要重构的代码，而没人去主动去重构。问一圈下来，得到的答案大多都类似于不敢改，没有测试资源，怕改出问题之类。
这更能看出测试这件事的重要性，但是这里指的测试不完全是测试这个职位。相比较于数据，人就显得不是那么可靠。当然了，文档，注释也是数据。但在没有强制性，约束性的制度下，写出的文档，注释质量可想而知。
所以，在一些逻辑复杂，或重要级别高的代码，我们可以推行测试代码随行。这样的话，下一次有人重构这一块代码的时候，测试代码成功，那么就基本不会有大的问题。
当然了，我不得不承认我这个底层程序员才疏学浅，对于自动化测试，工具了解不深，无法给出其他建议。就请看到这篇文章，又有兴趣的其他大佬， 脑补接下来的测试步骤。
4、如何说服非技术人员给你时间重构代码（产品经理，测试，PMO）
一些小模块，影响面比较小的代码的阻碍是测试。但是对于一些重构需要2-3天的中小模块的最大阻碍大概就是“友军”了。排期紧张，PMO只看中项目进度，测试老师只看重运行运行结果，想着重构一个模块，代码更整洁，之后迭代开发更方便，恐怕难遇上天。他人都觉得代码既然很稳定的运行，就不应该动。那么看着代码不爽的我们往往只能趁着这一次有测试资源，挤压自己的时间，加班加点重构代码。偷偷摸摸的义务劳动，很多时候到头来只能感动自己（没人认可）。
所以说，重构从来不是一个人的事情，亦不是一个小组的问题，而是整个研发部分的问题，只有从上到下，各友军单位都认可了这件事，我们就可以将重构这件事摆到明面上。
既然我们有技术评审这个过程，那么完全可以加一个重构评审的过程。
开发人员争取了合法合理的重构时间。
让非开发人员更了解代码
反向推动开发人员代码质量，更加容易避免出现“屎山”项目代码
5、面对屎山项目怎么办
恕我直言，面对屎山项目，与其说是重构，更不如说是重建。面对这样的项目，是重构还是重建，已经不是我能妄言的...
6、总结
这篇文章，通篇没有讲重构的方法论，那是因为我觉得那应该是另一个话题《如何写出优雅的，易扩展的代码》。第一次就写出“好”代码，和将“差”代码改成“好”代码，代码层面来看，这本身就是一件事。所以说，重构这件事，更应该考虑的是
如何展开重构的工作，
如何用最小的代价重构去重构
如何安全的去重构
并且，重构并不是某个程序员，某一段时间的任务。重构贯彻整个项目的生命周期，从发现代码片段有问题，顺手重构；模块有问题，改完走测试用例；没有排期去重构，找leader去协商。
大道至简，重构这件事很重要，很难，但是最主要，最首先的是统一思想，而不是先去学习那些重构的奇淫技巧。
思想统一了，重构这件事就会深入到我们编码的每一个步骤，架构设计，组件分配，编码习惯，项目复盘，才会有动力，有思想支撑重构，支撑代码洁癖。
7、后记
说实话，已经很久没更新了，之前是状态不好忙着调整状态，当时后台还有几位读者留言，问我否继续更新，真的很感动！！！
今晚睡觉前，打开了久违的后台数据，发现自己没有操作的这段事件，读者还增加了不少，感谢各位的厚爱，于是就将这篇不成熟的文章发出来了。
当然了，最后再一次推销自己，如果你感觉对你有帮助，欢迎关注我!!!
