“系统中的每一项知识都必须具有单一、无歧义、权威的表示”
“DRY-Don’t Repeat Yourself 不要重复自己”
“代码为什么需要注释：糟糕的代码才需要许多注释。DRY法则告诉我们，要把低级的知识放在代码中，它属于那里；把注释保留给其他的高级说明。否则，我们就是在重复知识，而每一次改变都意味着既要改变代码，也要改变注释。”
“如果你觉得受到诱惑，想一想古老的格言：”欲速则不达”。其中许多问题是由开发者的懒惰造成的。无耐性的重复是一种容易检测和处理的重复形式，但那需要你接受训练，并愿意为避免以后的痛苦而预先花一些时间。”
“在计算技术中，正交性用于表示某种不相依赖或是解耦性。如果两个或更多事物中的一个发生变化，不会影响其他事物，这些事物就是正交的。”
“不要依赖你无法控制的事物属性”
“让你的代码保持解耦；避免使用全局数据；避免编写相似的函数。养成不断地批判对待自己的代码的习惯。寻找任何重新进行组织、以改善其结构和正交性的机会。这个过程叫重构。”
“修正bug也是评估整个系统的正交性的好时候。当你遇到问题时，评估修正的局部化程度。你是否改动了一个模块，或者改动分散在整个系统的各个地 方？当你做出改动时，它修正了所有问题，还是又神秘地出现了其他问题？当你在测试之后、把代码签回时，标记所做的bug修正。随后你可以运行月报，分析每 个bug修正所影响的源文件数目的变化趋势。”
“可撤消性：不存在最终决策”
“有许多人会设法保持代码的灵活性，而你还需要考虑维持架构、部署及供应商集成等领域的灵活性。不确定市场部门想怎样部署系统？预先考虑这个问题，你可以支持单机、客户端-服务器、或n层模型–只需要改变配置文件。无论你使用的是何种机制，让它可撤消吧。”
“曳光弹告诉你击中的是什么。那不一定总是目标。于是你调整准星，直到完全击中目标为止。这正是要点所在。”
“原型制作生成用过就扔的代码。曳光代码虽然简约，但却是完整的，并且构成了最终系统的骨架的一部分。你可以把原型制作视为第一发曳光弹发射之前进行的侦察和情报搜集工作。”
“原型制作是一种学习经验。其价值并不在于所产生的代码，而在于所学到的经验教训。那才是原型制作的要点所在。适当地使用原型，可以帮你在开发周期 的早期确定和改正潜在的问题点–在此时改正错误既便宜、又容易–从而为你节省大量时间、金钱，并大大减轻你遭受的痛苦和折磨。”
“靠近问题领域编程。通过在更高的抽象层上编码，你获得了专心解决领域问题的自由，并且可以忽略琐碎的实现细节。实现小型语言。尽管解析”真正的”语言所需要的代码可能更难编写，但它却容易被人理解得多，并且将来用新特性和新功能进行扩展也要容易得多。”
“通过代码对进度表进行迭代。你必须帮助他们了解团队、团队的生产率、还有环境将决定进度。通过使其形式化，并把改进进度表作为每次迭代后一部分，你将给予他们你所能给予的最精确的进度估算。”
“在被要求进行估算时说什么？你说：我等会儿回答你。如果你放慢估算的速度，并花一点时间仔细检查我们在这一节描述的步骤，你几乎总能得到更好的结果。”
第二章读后感：这一章节讲的内容偏向于需求分析和总体设计方面。重构解耦这些概念不少书籍都会提到，不过我反而觉得无耐性重复这点描述开发者比较到 位，自己就有过这种经历，出于懒，有时候就直接拷贝代码，或没有从设计上考虑避免重复，这样反而容易导致潜在的问题。至于对bug的修正统计，我觉得这样 做很科学，一方面可以对容易出错的知识点进行补充或培训，同时我相信也是对开发者的一种鞭策，但是在国内这些产品压力巨大的情况下，很难做到这一点。其实 我一直想自己实现一门小型语言，这本书的说法反而更肯定了我这个想法，实现小型语言要放到今年的to do list里面。有人说过，“程序的实际开发时间 = 2*程序员估计时间 + 10% 的来历: 一般程序员会过少的估计时间，程序员水平越好，越接近正确值，水平越低偏差越大。考虑到需求变化和其他怪异的情况，常用最好程序员估计时间*2+10%缓 冲。在不系统研究，粗测时间时，比较有效。”，估算考虑到调试、fix bug的时间风险，还要与同类型项目的时间对比，这样可能会容易得到更准确的估算。