接着上次的感悟继续往下走。
第一章 大都是作者的在实践中的深刻的建议，从下面开始，作者开始从一些具体开发实例进行解析。
1、重复的危害
a.给予计算机两项自相矛盾的知识，是James T. Kirk舰长（出自Star Trek，“星际迷航”——译注）喜欢用来使四处劫掠的人工智能生命失效的方法。遗憾的是，同样的原则也能有效地使你的代码失效。
b.可靠地开发软件、并让我们的开发更易于理解和维护的惟一途径，是遵循我们称之为DRY的原则：系统中的每一项知识都必须具有单一、无歧义、权威的表示。
c.重复是代码中最坏的味道，大家可以回想一下，有多少Bug是因为重复代码漏改引起的，修改重复代码又浪费了多少时间。这么坏的东西一定要深恶痛绝！书中归纳了几种常见的重复类型：
1）无意的重复（inadvertent duplication）。开发者没有意识到他们在重复信息。
2) 无耐性的重复（impatient duplication）。开发者偷懒，他们重复，因为那样似乎更容易。
3) 开发者之间的重复（interdeveloper duplication）。同一团队（或不同团队）的几个人重复了同样的信息。
2、时间耦合
a.时间是软件架构的一个常常被忽视的方面，吸引我们的时间只是进度表上的时间。作为软件自身的一种设计要素，时间有两个方面对我们很重要：并发和次序。我们在编程时，通常并没有把这两个方面放在心上。当人们最初坐下来开始设计架构、或是编写程序时，事情往往是线性的，那是大多数人的思考方式——总是先做这个，然后再做那个。但这样思考会带来时间耦合：在时间上的耦合，方法A必须总在方法B之前调用，“嘀”必须在“嗒”之前发生。
b.程序在时序性上的依赖是客观存在的，对不得已的时序依赖一定要写入文档或者标明注释。
3、重构
a.随着程序的演化，我们有必要重新思考早先的决策，并重写部分代码。这一过程非常自然。代码需要演化；它不是静态的事物。
b.无论代码具有下面的哪些特征，你都应该考虑重构代码：重复；非正交的设计；过时的知识（最典型的就是需求已经下线、方案已经改变，但过时代码却还残留甚至运行）；性能问题。
c.重构在实践上的指导
1） 不要试图在重构的同时增加功能。
2） 在开始重构前，确保你拥有良好的测试。
3） 采取短小，深思熟虑的步骤。把整体重构工作认真的分解为独立、轻量的几个步骤，每个步骤完成都可以进行测试，这将有助于快速定位问题。
4、可撤销性
a.（There Are No FinalDecisions）不存在最终决策没有人知道未来会悄怎样，尤其是我们！所以要让你的代码学会“摇滚”：可以“摇”就“摇”，必须“滚”就“滚”。
b.我们不必做出许多关键的、不可逆转的决策。这是一件好事情，因为我们并非总能在一开始就做出最好的决策。我们采用了某种技术，却发现我们雇不到足够的具有必需技能的人。我们刚刚选定某个第三方供应商，他们就被竞争者收购了。与我们开发软件的速度相比，需求、用户以及硬件变得更快。
5、曳光弹
a.这个类比也许有点暴力，但它适用于新的项目，特别是当你构建从未构建过的东西时。与枪手一样，你也设法在黑暗中击中目标。因为你的用户从未见过这样的系统，他们的需求可能会含糊不清。因为你在使用不熟悉的算法、技术、语言或库，你面对着大量未知的事物。同时，因为完成项目需要时间，在很大程度上你能够确知，你的工作环境将在你完成之前发生变化。
b.用曳光弹找到目标（Use Tracer Bullets toFind the Target）
c.曳光开发与项目永不会结束的理念是一致的：总有改动需要完成，总有功能需要增加。这是一个渐进的过程。