《程序员修炼之道》摘录

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 正交性 对代码负责 ”等你准备好“