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

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

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

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

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

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

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

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

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

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

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