《重构》语录

《重构》语录

Updated on Sunday, October 17, 2004

Amassed by Allen Lee

0.0 ...一开始只需概略浏览名录&＃xff0c;看看其中有些什么&＃xff0c;不必理解所有细节。一旦真正需要实施某个准则&＃xff0c;再详细阅读它&＃xff0c;让它来帮助你。名录是一种具备查询价值的章节&＃xff0c;你也许并不想一次把它全部读完。...

1.0 ...一开始介绍某个东西时&＃xff0c;首先应该大致讲讲它的历史、主要原理等等。可是每当有人在会场上介绍这些东西&＃xff0c;总是诱发我的瞌睡虫。我的思绪开始游荡&＃xff0c;我的眼神开始迷离&＃xff0c;直到他或她拿出实例&＃xff0c;我才能够提起精神。实例之所以可以拯救我与太虚之中&＃xff0c;因为它让我看见事情的真正行进。谈原理&＃xff0c;很容易流于泛泛&＃xff0c;又很难说明如何实际应用。给出一个实例&＃xff0c;却可以帮助我把事情认识清楚。

1.1 即便如此&＃xff0c;这个程序还是能正常工作。所以这只是美学意义上的判断&＃xff0c;只是对丑陋代码的厌恶&＃xff0c;是吗&＃xff1f;在我们修改这个系统之前的确如此。编译器才不会在乎代码好不好看呢。但是当我们打算修改系统的时候&＃xff0c;就涉及到了人&＃xff0c;而人在乎这些。差劲的系统是很难修改的&＃xff0c;因为很难找到修改点。如果很难找到修改点&＃xff0c;程序员就很有可能犯错&＃xff0c;从而引入“臭虫”&＃xff08;bugs&＃xff09;。

1.2 你的态度也许倾向于“尽量少修改程序”&＃xff1a;不管怎么说&＃xff0c;它还运行得很好。你心里头牢牢记着那句古老的工程学格言&＃xff1a;“如果他没坏&＃xff0c;就别动它”。这个程序也许还没坏掉&＃xff0c;但它带来了伤害。它让你的生活比较难过&＃xff0c;因为你发现很难完成客户所需的修改。这时候就该重构技术粉墨登场了。

1.3 如果你发现自己需要为程序添加一个特性&＃xff0c;而代码结构是你无法很方便地那么做&＃xff0c;那就先重构那个程序&＃xff0c;使特性的添加比较容易进行&＃xff0c;然后再添加特性。

1.4 更改变量名称是值得的行为吗&＃xff1f;绝对值得。好的代码应该清楚表达出自己的功能&＃xff0c;变量名称是代码清晰的关键。如果为了提高代码的清晰度&＃xff0c;需要修改某些东西的名字&＃xff0c;大胆去做吧。

1.5 任何一个傻瓜都能写出计算机可以理解的代码。惟有写出人类容易理解的代码&＃xff0c;才是优秀的程序员。

2.0 从许多角度来说&＃xff0c;所谓程序设计&＃xff0c;便是与计算机交谈。你编写代码告诉计算机做什么事&＃xff0c;它的响应则是精确按照你的指示行动。你得及时填补“想要它做什么”和“告诉它做什么”之间的缝隙。这种编程模式的核心就是“准确说出吾人所欲”。除了计算机外&＃xff0c;你的源代码还有其他读者&＃xff1a;数个月之后可能会有另一位程序员尝试读懂你的代码并做一些修改。我们很容易忘记这位第二位读者&＃xff0c;但他才是最重要的。计算机是否多花了数个钟头进行编译&＃xff0c;又有什么关系呢&＃xff1f;如果一个程序员花费一周时间来修改某段代码&＃xff0c;那才关系重大——如果他理解你的代码&＃xff0c;这个修改原本只需一小时。

2.1 ...很多时候那个“未来的开发者”就是我自己。此时重构就显得尤其重要了。我是个很懒惰的程序员&＃xff0c;我的懒惰表现形式之一就是&＃xff1a;总是记不住自己写过的代码。事实上对于任何立可查阅的东西我都故意不去记它&＃xff0c;因为我怕把自己的脑袋塞爆。我总是尽量把该记住的东西写进程序里头&＃xff0c;这样我就不必记住它了。

2.2 一开始我所作的重构都像这样停留在细枝末节上。随着代码渐趋简洁&＃xff0c;我发现自己可以看到一些以前看不到的设计层面的东西。如果不对代码做这些修改&＃xff0c;也许我永远看不见它们&＃xff0c;因为我的聪明才智不足以在脑子里把这一切都想象出来。Ralph Johnson把这种“早期重构”描述为“擦掉窗户上的污垢&＃xff0c;使你看得更远”。

2.3 我不是一个伟大的程序员&＃xff1b;我只是个有着一些优秀习惯的好程序员而已。

2.4 ...重构本来就不是一件“特别拨出时间做”的事情&＃xff0c;重构应该随时随地进行。你不应该为重构而重构&＃xff0c;你之所以重构&＃xff0c;是因为你想做别的什么事&＃xff0c;而重构可以帮助你把那些事做好。

2.5 第一次作某件实事只管去做&＃xff1b;第二次作类似的事会产生反感&＃xff0c;但无论如何还是做了&＃xff1b;第三次在做类似的事&＃xff0c;你就应该重构。

2.6 ...系统今天&＃xff08;当下&＃xff09;的行为&＃xff0c;只是整个故事的一部分&＃xff0c;如果没有认清这一点&＃xff0c;你无法长期从事编程工作。如果你“为求完成今天任务”而采取的首发式你不可能在明天完成明天的任务&＃xff0c;那么你还是失败。但是&＃xff0c;你知道自己今天需要什么&＃xff0c;却不一定知道自己明天需要什么。也许你可以猜到明天的需求&＃xff0c;也许吧&＃xff0c;但肯定还有些事情出乎你的意料。

2.7 我们希望程序&＃xff1a;&＃xff08;1&＃xff09;容易阅读&＃xff1b;&＃xff08;2&＃xff09;所有逻辑都只在为一地点指定&＃xff1b;&＃xff08;3&＃xff09;新的改动不会危及现有行为&＃xff1b;&＃xff08;4&＃xff09;尽可能简单表达条件逻辑。

2.8 当然&＃xff0c;很多经理嘴巴上说自己“质量驱动”&＃xff0c;其实更多是“进度驱动”。这种情况下我会给他们一个较有争议的建议&＃xff1a;不要告诉经理&＃xff01;

2.9 受进度驱动的经理要我尽可能快速完事&＃xff0c;至于怎么完成&＃xff0c;那就是我的事了。我认为最快的方式就是重构&＃xff0c;所以我就重构。

2.10 我们知道重构的好处&＃xff0c;我们知道重构可以给我们的工作带来垂手可得的改变。但是我们还没有获得足够的经验&＃xff0c;我们还看不到它的局限性。

2.11 不要过早发布接口。请修改你的代码拥有权政策&＃xff0c;是重构更顺畅。

2.12 重写&＃xff08;而非重构&＃xff09;的一个清楚讯号就是&＃xff1a;现有代码根本不能正常运行。

2.13 将“大块头软件”重构为“封装良好的小型组件”。

2.14 如果项目已近最后期限&＃xff0c;你也应该避免重构。在此时机&＃xff0c;从重构过程赢得的生产力只有在最后期限过后才能体现出来&＃xff0c;而那个时候已经是不我予。Ward Cunningham对此有一个很好的看法。他把未完成的重构工作形容为“债务”。很多公司都需要借债来势自己更有效的运转。但是借债就得付利息&＃xff0c;过于复杂的代码所造成的“维护和扩展的额外开销”就是利息。你可以承受一定程度的利息&＃xff0c;但如果利息太高你就会被压垮。把债务管理好是很重要的&＃xff0c;你应该随时通过重构来偿还一部分债务。

2.15 哪怕你完全了解系统&＃xff0c;也请实际量测它的性能&＃xff0c;不要臆测。臆测会让你学到一些东西&＃xff0c;但十有八九你是错的。

2.16 我发现重构可以帮助我写出更快的软件。短程看来&＃xff0c;重构的确会使软件变慢&＃xff0c;但它是优化阶段中的软件性能调整更容易。最终我还是有赚头。

4.0 当测试数量达到一定程度之后&＃xff0c;测试效益就会呈现递减态势&＃xff0c;而非持续递增&＃xff1b;如果试图编写太多测试&＃xff0c;你也可能因为工作量太大而气馁&＃xff0c;最后什么都写不成。你应该把测试集中在可能出错的地方。观察代码&＃xff0c;看哪儿变得复杂&＃xff1b;观察函数&＃xff0c;思考哪些地方可能出错。

5.0 该在何时发表自己的想法&＃xff1f;发表愈早&＃xff0c;人们愈快能够运用新想法、新观念。但只要是人&＃xff0c;总是不断在学习。如果过早发表半生不熟的想法&＃xff0c;这些思想可能并不完善&＃xff0c;甚至可能给那些尝试采用它们的人带来麻烦。