重构-改善既有代码的设计(Refactoring: Improving the Design of Existing Code)

https://book.douban.com/subject/4262627/

重构是这样一个过程：“再不改变代码外在行为的前提下，对代码做出修改，以改进程序的内部结构.重构是一种有纪律的，经过训练的，有条不紊的程序整理方法，可以将整理过程中不小心引入错误的几率降到最低。本质上说，重构就是在代码写好之后改进它的设计.什么时候进行重构?如果你发现自己需要为程序添加一个特性，而代码结构使你无法很方便做的时候，那么就先重构那个程序，使特性的添加比较容易进行，然后再添加特性.重构之前，首先检查自己是否有一套可靠的测试机制。这些测试必须有自我检验的能力(self-checking)

任何一个傻瓜都能写出计算机可以理解的代码。惟有写出人类容易理解的代码才是优秀的程序员（或许优秀的程序员还要精通英语，不然怎么写出所有人类容易理解的代码，或许像我英语这么差的人，一辈子都不能成为优秀程序员）

当然，很多经理嘴巴上说自己质量驱动，其实更多的是进度驱动。这种情况下我会给他们一个较有争议的建议：不要告诉经理你在重构.这是在搞破坏马？我不这样想。软件开发者都是专业人士。我们的工作就是尽量创造高效软件。经验告诉我.对于快速创造软件，重构可以带来巨大的帮助。 受进度驱动的经理要我竟可能快速完事，至于怎么完成，那就是我的事情了。我认为最快的方式就是重构，所以我就重构.

“事先设计”(upfront design)可以帮助我节省回头工的昂贵成本。于是我很快加强这种预先设计风格。许多人把设计看作软件开发的关键环节，而把编程看作只是机械的低级劳动，但是你要知道，软件和真实机械有很大的差别。软件的可塑性很强，而且完全是思想的产品。正如Alistair Cockburn所说的:”有了设计，我们可以思考更快，但是其中充满小漏洞”

优秀程序员肯定会少花一些时间来清理自己的代码。这么做是因为，他们知道简洁的代码比杂乱无章的代码更容易修改，而且他们知道自己几乎无法已开始就编写出简洁的代码。

在对象设计的过程中，“决定把责任放在那里”即使不是最重要的事情，也是最重要的事情之一。我使用对象技术已经十多年了，但是还不能一开始就保证确

明天，或者后天，或者下个月，甚至可能明年，灵感总回来的。为了等待进行一项重构的后一半所需要的灵感，我最多曾经等过9个月。你可能会明白自己错在哪里，明白自己对在哪里，总之都能使你想清楚下一步应该如何进行。然后你就可以像最初一样自信地跨出一步。也许你羞愧地想：我太笨了，竟然这么久都没有想到这一步。大可不必，每个人都是这样。

这有点像在悬崖峭壁上的小径行走：只要有光，你就可以前进。虽然谨慎却仍然自信，但是一旦太阳下山，你就应该停止前进。夜晚你应该睡觉，相信明天太阳依然升起。(该吃饭时就吃饭,该重构时就重构)

两个家伙的车子在山顶附近抛锚了，于是他们走下车，一人走到车的一头，开始推车。经过半个小时但是却毫无成果，车头的那家伙开始说道：“我从来不知道把车子推下山这么难”。另一个家伙答到：“你说推下山是什么意思，难道我们不是想把车子推上山吗？”我猜你一定不想让这个故事在你的团队中重演吧！ 进行大规模重构之前，有必要为整个开发团队建立共识。