关于重构（二）
最近在看《重构改善既有代码设计》这本书，有些感悟分享给大家！！此感悟均自己瞎想，说的不对请见谅！！
这本书我已经看到第6章了，前5章可以简单的总结为：“为何重构？怎么重构?(重构的方法、原则)”
书中提及“事不过三、三则重构”，意思就是一个方法、函数用过3次或是多次就应该考虑重构了。
何时重构？
- 添加功能时：因为在某个功能基类可能在多个地方被用到，但客户有了写的需求，需要添加新的功能，但是你又不确定在基类中修改会不会影响其他的功能点，此时就应该重构。
- 修补错误时：这个情况和上述情况差不多，在修补这个错误时，你无法确定在修改之后会不会引起其他的错误，此时就应该重构
- 复审代码时：复审代码在许多公司在交付项目时都会对代码进行复审（可能大公司才不会有吧，至少我暂时没有遇到过），因为代码不可能是复审人员写的（这个应该说是一定不是开放人员去自己复审自己的代码），可能对某些代码段无法理解其功能，就应该重构。
为何重构？可以说重构的好处、优点在哪？
- 改善软件的设计：应为软件在最初设计时，没办法将所有的事情想的面面俱到，所以在后续的开发中就应该用重构来弥补软件设计的不足。
- 使软件更容易理解：重构可以让计算机明确你“要他去做什么”，更能让后来者读懂它，“后来者”？这是有人会问：“后来者，是何许人也？”这里可以明确的告诉你，一个项目、一个功能点不可以永远满足需求，后期肯能要有改动，可能是你、也可能是另一个程序员，你自己能不能保证自己以前写的程序，现在拿过来就知道其中某个方法的功能呢？这时有人会说：“能”，（我靠大哥不要来抬杠行不，我不太清楚别人，但对于我自己来说，是很难一下理解的，（这时有人说那是你笨，我只能说我比较懒），我身边的大多数程序员都比较懒）感觉有些跑题了，咱们把思路拉回来，接着说重构的优点，重构大部分是为了“后来者”去更容易去理解代码的
- 帮助找到BUG：因为一些代码在一起可能无法一眼看出其中的BUg或是隐藏在深处的潜在BUg，我们需要去重构
- 提高编程速度：大家看到这会说，上面可以理解，重构怎么会能提高编程速度呢？书上说了一套书面话，我用大白话将它“翻译”了一下，是因为我们在最初设计软件时没办法设计的非常合理，在后期可能添加新功能，我们会化大把的时间花在调试、修改、调试、修改上，首先我们要花费很长时间去了解系统、理解代码，工期就会被拖长，(时间长领导就对经理说： 怎么搞的搞了这么长时间还没弄好？这时经理就找你了说： “就一个简单的问题搞了这么长时间，还没弄好？”，你心情不好，工作带有情绪，你辞职了，又来一新员工接着做你没做完的问题，形成恶性循环，当然我们抛出公司领导的管理问题，经理的管理能力、技术能力，我们单单站在程序员的角度去看问题)
说了这么多？有人就会问什么是重构啊？要知故事如何且待下回分解！！
