原则14：把相关的定义放在一起。设计代码结构时，确保高度相关的部分放在一起，有可能放在同一个类中。这是面向对象设计方法在封装方面的一条标准原则。理想情况下，某个类之外的所有代码不需要知道内部运行的细节。有些开发人员喜欢将细节分散在多个文件中，以便按不同方式加以组织：比如为了把所有相同的数据类型放在一起，或者按字母顺序进行组织。比方说，把一个类中所有常量放在与使用它们的包不同的另一个包当中，就会增加不必要的程序复杂性。指导原则应该是按相关性进行分组，那样可以隐藏复杂性。

    原则15：始终在签入代码之前运行测试。这条准则会帮助你满足“千万不要破坏编译版本”的准则。

    原则16：仓促优化是万恶之源。程序教父Don Knuth的这句名言今天依然适用。应当精心编写代码，避免微观层面出现不必要的浪费，但应该等到基于实际的最终用户用例对整个程序进行压力测试，再进行单个方法层面之外的优化。要是仅仅基于对代码的静态了解，就凭直觉判断什么对整体性能来说很重要，几乎肯定出错。相反，要度量整个系统的行为，找出真正影响性能的那1%的代码，并关注这部分代码。

    原则17：尽量减少积压下来的没有完成的编码任务。开发人员开始编写某个用例时，所有已被修改、但没有完成及测试的代码会发生成本。没有完成的变更积压几天或几周，会大大增加因改写而导致浪费的风险。设想一下有三个任务，每个任务估计需要一天。同时开始这三个任务，同时工作三天就需要累计9个“单位”的成本。但如果按顺序处理每个任务，一个任务完成后开始下一个，那么只需要3个“单位”的成本。这并不直观。直觉告诉我们：我们在处理任务时，最好还是同时做三件事。但软件不像实体构造。短小、快速、完整的任务不但可以减轻认知负荷，还能减小未完成工作与另一个人的未完成工作发生冲突的可能性。

    原则18：千万不要过于强调代码的通用性。这就是有名的YAGNI，即“你不会需要它”。程序员在编写某个特定类时，喜欢认为：只要稍加改动，该类可用于另外几个用途。如果当前用例需要这些用途，那很好；但是程序员通常会考虑还没有发明出来的用途，或者是实际上根本不需要的用途。（这个话题老是让我想到宣传某款产品既是地板蜡、又是甜食配料的搞笑电视节目。）

    原则19：能用两行代码，就坚决不要用三行。每当别人要读代码时，简单的代码总是一目了然。但也不要把代码简化到人家很难读懂的地步。与冗长代码相比，简洁代码更容易维护，也更容易发现其中的错误。始终要尽量简化，但避免简化过头。

    原则20：千万不要用行数来度量代码。就完成特定任务所需的代码行数而言，不同的程序员和编程风格会造成很大的差异。代码行数说明不了代码有多全面、质量有多好。代码质量有可能千差万别；与代码质量相比，代码行数显得没有太大的意义。而是应统计切实可行的用例有多少。

    原则21：持续不断地重新设计和重构。运用这条原则要慎重，因为有些代码很脆弱、很难改变，但一般而言，你用不着害怕更改代码以符合实际用例。某个数据成员过去可能是整数，但是当用例要求它是浮点数时，不要害怕更改。

    原则22：删除无用代码。说到并不完全了解的大段代码，人们往往采取“别惹事生非”的做法。一个例子就是，为某个类增加一种新方法以替换另一种旧方法，而开发人员往往让旧方法留在那里，仅仅为了“以防万一”。应当花一番工夫，看看需不需要该方法；如果没有证据表明需要它，就删除。最糟糕的做法莫过于注释掉了大段代码，却任由这些注释代码留在原处。一旦你知道测试完毕，就应当删除注释代码，当然要在签入之前。随时添加代码很容易，随时删除代码却很难。因此，如果你清楚不需要某部分代码，那么只需下一点力气，核实并消除此代码就能让代码库维护起来更容易。

    原则23：不要发明新语言。程序员喜欢让驱动功能的文本文件在运行时可以灵活配置。有好多配置文件在不重新编译的情况下能够改变程序的行为。XML的出现让一批专门定制的“脚本语言”层出不穷：有了这些语言，最终用户不必编译，就能够“编程”以实现功能。这种推论的缺陷在于，要是离开了具体实现的环境，就几乎根本无法明确规定操作行为的精确定义；而这些类型的脚本语言主要只适用于那些对相应代码的内部运行有深入了解的人。因此，并不详细了解内部运行的实际最终用户永远不可能知道如何才能预料到复杂的命令组合会带来什么影响。脚本语言是有用，也不能被抹杀，但是设计者必须采取一种极其保守的态度，尽可能使用现有语言，避免发明新的语言。

    原则24：等准备好了实现并测试实现代码，再进行设计。你应该总体上对工作方向有一些了解，并大致了解争取建立的系统架构。但在进入到可以实现及测试该设计的开发迭代阶段之前，不要做详细设计，也不要编写功能实现的详细描述。详细设计应当只涉及处理当前用例所需的那部分。软件开发中造成浪费的最主要根源在于，把时间花在设计不需要、或者因为设计方面某些错误的假定而需要重新设计的部分上。

    原则25：设计是可塑的。不像实体构造，软件可以轻而易举地进行重大改变。事实上，有许多证据可以证明：软件比描述软件的设计规格更容易改变。此外，软件比规格更有效地传达了设计思想。因此，你应当把时间花在直接实现设计上，以便客户能看到设计的具体细节。如果你缺少某些功能、因而要改变设计，改变软件会比改变规格来得容易。但最重要的是，客户看到代码运行后，你就能非常清楚地知道客户想要什么。

    原则26：花些时间编写代码来完整描述发现和报告异常情况的代码中的问题。程序员往往很懒惰，对抛出的异常情况只给出简单肤浅的描述，说明哪里出了错。以为只有他们自己才会看到这个问题；只要借助含糊笼统的描述，就会记得该问题的意思。但实际上，因错误报告不准确或不完整而浪费在客户支持情景上的时间比其他任何原因都要多。要编写每一个错误消息，就好像你向刚走入房间、对代码毫无经验的某个人说明情况。毕竟，客户以及客户支持团队对代码是毫无经验的。