1.我的源码让猫给吃了——不要找借口，要负责。
2.软件的熵——不要容忍“破窗户”（低劣的设计、错误决策或是糟糕的代码），见一个修个。
3.石头汤与煮青蛙——做变化的催化剂，避免“启动杂役”；记住打图景，温水煮青蛙。
4.足够好的软件——使质量称为需求问题；避免过度修饰。
5.你的知识资产——定期为你的知识资产投资（最简单的就是买书）；批判地分析你读到的和听到的。
6.交流——被打量比被忽略要好（这个深有体会）；你说什么和你怎么说同样重要。
7.重复的危害——DRY
8.正交性——消除无关事物之间的影响。
9.可撤销性——如果某个想法是你唯一的想法，在没有什么比这更危险的事情了；不存在最终决策；灵活的架构。
10.曳光弹——原型制作生成用过就扔的代码。曳光弹代码虽然简约，但却是完整的，并且构成了最终系统的骨架的一部分。
11.原型与便笺——任何带有风险的事物。以前没有试过的事物或是对于最终系统终端极端关键的事物。原型并不一定要编写代码，有时用便笺就可以。
12.领域语言。
13.估算——多准确才足够准确
时长 报出估算的单位
1-15天 天
3-8周 周
8-30周 月
30+周 在给出估算前努力思考一下
14.纯文本的威力。
15.shell 游戏——利用命令shell的力量。
16.强力编辑器——（vim 或 sublime text）。
17.源码控制——（git或svn）。
18.调试——最容易欺骗的人是一个人自己；不要恐慌；调试的思维方式。
19.文本操纵——学习一种文本操纵语言。
20.代码生成器——编写能生成代码的代码（《黑客与画家》中也提到这一点）。
21.按合约设计。
22.死程序不说谎——早崩溃；检查每一个可能的错误。
23.断言式编程——如果它不可能发生，用断言确保它不会发生。
24.何时使用异常——将异常用于异常的问题。
25.怎样配平资源——要有始有终。
26.解耦与得墨蕊耳法则——模块之间的耦合减至最少。
函数的得墨忒耳法则规定，某个对象的任何方法都应该只调用属于以下情形的方法：class Demeter{public: void example(B &b);private: A *a; int func(){}}void Demeter::example(B &b){ C c; int f = func(); <------------------1. 它自身 b.invert(); <----------------------2. 传入该方法的任何参数 a = new A(); a->setActive(); <------------------3. 它创建的任何对象 c.print(); <-----------------------4. 任何直接持有的组件对象}得墨忒耳法则缩小了调用类中的响应集的规模，结果以这种方式设计的类的错误也往往更少。 |
27.元程序设计——要配置，不要集成；将抽象放进代码，细节放进元数据。（有所体会）
28.时间耦合——分析工作流，以改善并发性；架构、并发、接口、部署。
29.它只是视图——发布/订阅；MVC。
30.黑板——用黑板协调工作流。
31.靠巧合编程——编写自己能控制的代码，不要靠巧合编程。
32.算法速率。
33.重构——早重构，常重构。
34.易于测试的代码——单元测试；构建测试窗口。
35.邪恶的向导——不要使用你不理解的向导代码。
36.需求之坑——不要搜集需求，要挖掘他们；用户；文档。
37.解开不可能解开的谜题——什么时候坚持，什么时候改变。
38.等你准备好——什么时候准备，什么时候开始。（要有良好的判断）
39.规范陷阱——对有些事情“做”胜于“描述”。
40.圆圈与箭头——不要做形式的奴隶。
前面这七章是对个人而言，第八章对团队而言（后面再看）
关键词：重构 单元测试 没有解不开的难题 交流 曳光弹 元程序设计 DRY 正交性 对代码负责 ”等你准备好“