注重实效的途径
想法和过程集中在一起，头两节的偏向于“重复的危害”和“正交性”密切相关，前者告诉我们，不要在系统各处对知识进行重复，后者告诉我们不要把同样的知识分散在多个组件中，时代的发展越来越快，我们的应用越来越难使其跟上需求的变化，接下来的两节也是相关的。在“曳光弹”中，讨论一种开发方式，能同时搜集需求、测试设计、并实现代码。这听起来可能不太好、不可能是真的?的确如止曳光弹开发并非总是可以应用。“原型与便笺”将告诉你,在曳光弹开发不适用的性下，怎样使用原型来测试架构、算法、接口以及各种想法。随着计算机科学慢慢成熟,设计者正在制作越来越高级的语言。尽管能够接受它这样”指令的编译器还没有发明出来，在“领域语言”中我们给;一些适度的建议，你可以自行加以实施。
作为程序员，我们收集、组织、维护和利用知识。我们在规范中记载知识、在运行的代码中使其活跃起来并将其用于提供测试过程中所需的检查。但是，知识并不稳定。它变化常常很快。你对需求的理解可能会随着与客户的会谈而发生变化。政府改变规章制度，有些商业逻辑过时了。测试也许表明所选择的算法无法工作。所有这些不稳定都意味着我们要把很大一部分时间花在维护上，重新组织和表达我们的系统中的知识。大多数人都以为维护是在应用发布时开始的,维护就意味着修正bug和增强特性。我们认为这些人错了。
程序员须持续不断地维护。我们的理解逐日变化。当我们设计或编码时，出现了新的需求。环境或许变了。不管原因是什么，维护都不是时有时无的活动,而是整个开发过程中的例行事务。而当我们在嵌在系统中重复的知识方法太多时，到了我们维护的时候，这无疑是我们的噩梦，大范围的修改维护将会是我们挥之不去的困难。
我们要遵循我们的DRY原则：
系统中的每一项知识都必须具有单一，无歧义，权威的表示，不要重复我们自己。
而重复又分为强加的重复觉得无可选择加入进去，也有无意的重复，没有正确意识到自己的重复，无耐的重复，为了偷懒进行信息的重复以及开发者之间互相的重复使用。
正交性
不要把任何一项知识分散在多个系统组件中。在计算技术中，该术语用于表示某种不相依赖性或是解耦性。如果两个或更多事物中的一个发生变化，不会影响其他事物，这些事物就是正交的。非正交的例子:直升机驾驶操作的各个控制器之间就是相互影响的，不是正交的。
正交的好处就是为了可以局部修正，消除无关事物间的影响
用曳光弹找到目标
曳光弹能通过试验各种事物并检查它们离目标有多远让你来追踪目标。这应该是最近比较流行的敏捷开发了吧，快速迭代，在实践中调整目标。
利用shell的力量
当图形用户界面无能为力时使用shell。自从用了Ubuntu,我已经习惯了命令行操作，它能解放你的右手，这种感觉相当舒服，可以帮助我们自动完成一些工作。
要修正问题，而不是发出指责
bug是你的过错还是别人的过错，并不是真的很有关系——它仍然是你的问题，它仍然需要修正。勇于承认自己的过错，这没有什么。