要提供各种选择，而不是找借口。不要说事情做不到；要说明能够做什么来挽回局面。必须把代码扔掉？给他们讲授重构的价值。

一扇破窗户，只要有那么一段时间不修理，就会渐渐给建筑的居民带来一种废弃感——一种职权部门不关心这座建筑的感觉。于是又一扇窗户破了。人们开始乱扔垃圾。出现了乱涂乱画。严重的结构开始损坏开始了。在相对较短的一段时间里，建筑就被损毁得超出了业主愿意修理的程度，而废弃感变成了现实。

如果你发现自己在有好些破窗户的项目里工作，会很容易产生这样的想法：“这些代码的其余部分也是垃圾，我只要照着做就行了。”

大多数人都以为维护是在应用发布时开始的，维护就意味着修正bug和增强特性。我们认为这些人错了。程序员须持续不断地维护。

系统中的每一项知识都必须具有单一、无歧义、权威的表示。

注释将不可避免地变得过时，而不可信任的注释比完全没有注释更糟。

处理这个问题的最佳方式是鼓励开发者相互进行主动的交流。

你不是在窥探——你是在向他们学习。

养成不断地批判对待自己的代码的习惯。寻找任何重新进行组织、以改善其结构和正交性的机会。

如果在代码中有着糟糕的封装、高度耦合以及硬编码的逻辑或参数，事情也许就是不可能的。

发现了他人的bug之后，你可以花费时间和精力去指责让人厌恶的肇事者。在有些工作环境中，这是文化的一部分，并且可能是“疏通剂”。但是，在技术竞技场上，你应该专注于修正问题，而不是发出指责。

如果有一个错误，就说明非常、非常糟糕的事情已经发生了。

死程序带来的危害通常比有疾患的程序要小得多。

无论何时你发现自己在思考“但那当然不可能发生”，增加代码检查它。最容易的办法是使用断言。

你的第一条防线是检查任何可能的错误，第二条防线是使用断言设法检测你疏漏的错误。

无论是谁分配的资源，它都应该负责解除该资源的分配。

最后，有一种技术可用于更进一步解除模块的耦合：提供一个“聚会地点”，各模块可以在那里匿名和异步地交换数据。

但“羞怯”的工作方式有两种：不向别人暴露你自己，不与太多人打交道。

很早以前我们就被教导说，不要把程序写成一个大块，而应该“分而治之”，把程序划分成模块。每个模块都有其自身的责任；事实上，模块（或类）的一个好定义就是，它具有单一的、定义良好的责任。

对象应该能进行登记，只接收它们需要的事件，并且决不应该收到它们不需要的事件。

不主动思考他们的代码的开发者是在靠巧合编程——代码也许能工作，但却没有特别的理由说明它们为何能工作。

注重时效的程序员批判地思考所有代码，包括我们自己的。

不要让已有的代码支配将来的代码。如果不再适用，所有的代码都可被替换。

当你遇到拌脚石——代码不再合适，你注意到有两样东西其实应该合并或是其他任何对你来说是“错误”的东西——不要对改动犹豫不决。应该现在就做。

时间压力常常被用作不进行重构的借口。但这个借口并不成立：现在没能进行重构，沿途修正问题将需要投入多得多的时间——那时将需要考虑更多的依赖关系。我们会有更多的时间可用吗？根据我们的经验，没有。

最勤勉的开发者如果被派到不在乎质量的团队里，会发现自己很难保持修正琐碎问题所需的热情。

事实上，好的项目拥有的测试代码可能比产品代码还要多。

匿名（尤其是在大型项目中）可能会为邋遢、错误、懒惰和糟糕的代码提供繁殖地。只把自己看作齿轮上的一个齿、在无休止的状况报告中制造蹩脚的借口、而不去编写优良的代码，那太容易了。