唠嗑唠嗑
相信做过项目的朋友多多少少都会有一种经历，项目做到一半，从头再整理一遍，如果平时就写写函数接口的朋友应该是无缘体验啦。
当然，因人而异，有的人喜欢重构，有的人不喜欢。我写一个项目，一般会重头整理两三遍才最后提交，有些朋友那就是一遍过，个人有个人习惯吧，可能不喜欢重构的朋友觉得是在浪费时间吧。
那，没事儿，喜欢重构的朋友呢，下面的内容应该会有更多共鸣，不喜欢重构的朋友呢，希望通过这篇文章能对重构有所改观。
我也会分享一些我喜欢且习惯的重构方式，大头还是放在后续文章里。
统一定义：重构？是什么
对项目内部结构的一种调整，目的是在不改变成品可观察行为的前提下，使项目更加亲切，通俗易懂，高效。
喔，亲切排第一位，然后是通俗易懂，然后是高效。
为什么我喜欢重构？
首先那肯定得是重构使得项目更容易理解
怎么说更容易理解，大家心照不宣。
项目拿到手上，经过前期的立项、分析，分工之后，首先想的自然是赶紧实现功能吧，如果有哪位大神已经通篇规划之后再像填空一样填代码，我服。我目前还没有那么深厚的功底，所以当功能实现之后，我的项目就像是鸡啄米一样，混乱不堪但是暂时还是尽在掌握的。这时候就需要第一波重构了。
这一波重构啊，主要是拿着项目书，和团队再对接进度，然后把那鸡啄米一样的项目整理成那种豆腐块儿的样式，哪个功能，属于哪个类，哪些继承关系需要拓展，哪里需要换成虚函数，哪些公共部分需要独立出一个公用文件等等，最重要的是，注释该写的写全面。这次重构，就是将你手上那些“尽在掌握”的东西落实，省的过两天忘了点啥，那就凉凉了。
在整个项目功能完工时，还要进行一波重构，这波重构主要内容和第一次一样，不过我会把文件的排列方式改成我喜欢的风格，我会按照文件被使用的先后顺序对文件进行从上到下排列，这个山人自有方法。这样只要对整个项目的脉络清楚，就可以在最快的时间内找到那个文件，里面的那个特定函数，或者一堆函数。
因为，当工程文件多起来的时候，那也是真的多啊。
最后，还需要一波优化重构。
当我们在努力使得程序运转的时候，不会想到未来还会有人在看吧，现在还有朋友在看我的代码，我很庆幸我当时有将代码重构了好几遍。
当然，未来那个开发者多半是我们自己看自己的代码。。。。
重构提高编程速度！！
有的人可能不同意这一点啊，感觉像是在开玩笑，毕竟重构一次需要不少时间，这也不是开玩笑的。我一般，第一波重构要花个一两天，当然，我是个对自己有要求的人，所以我现在控制在一天。第二波重构也就花个半天，然后还能歇个半天，最后那波优化就比较久了。
但是，曾经一个亲身经历让我明白，重构所花费的时间都不算什么。那是我刚开始做项目时候的事情了，刚开始还好，代码之间的联系不多，写了几天之后，各个功能需要串在一起了，这时候麻烦来了。首先是函数接口不明朗，有的功能函数，单独的测试demo都好好的，但是一接起来就各种不适应出来，好不容易串起来了，又出现那种牵一发而动全身的状况，陷入泥潭之后，又发现有些细节的东西就忘了，不知道某些地方为什么要那样写，那样写的优势和意义在哪里？之前明明记得很清楚，这才几天咋就忘了。。。然后，然后···心照不宣，一把辛酸泪。
后面还是学不聪明，但是，栽了几次跟投就学聪明了。。。
重构帮助找到BUG
这个情况是比较少碰到啦，因为一些主流的bug存在的话测试都过不了哈哈，但是就怕有些隐患，测试的时候没测出来，重构的时候对整体，脉络的把控会有一定程度的加强，也就更加容易找出那些潜藏的bug，这是实在的，但是，看运气咯。
什么时候重构
什么时候重构上面也提到了一点，但是我还是要再说说，不然这篇短了点啊。
什么时候重构？什么时候想重构那就什么时候重构嘛。
事不过三
一般重构也不用重构很多次，三次差不多，做到中间的时候、做完的时候、优化的时候。
少了不好，多了确实浪费时间。
大改的时候重构
比方说要添加一些重要功能的时候，特别是那种后期会牵一发全身抖一抖的那种，这时候需要对项目又足够的把控的时候。
不行不行，手累，先到这儿吧，明天见。
