程序员修炼之道读后感(二)

重复的危害
DRY原则（Don't reapeat youorself）：系统中的每一项知识都必须具有单一，无歧义，权威的表示
四种重复：
加强的重复（impsed duplication）：环境似乎要求重复（信息多种表示，注释，文档与代码，语言问题）
无意的重复（inadvertent duplication）：没有意识到信息的重复
无耐性的重复（impatient duplication）：开发者偷懒，似乎那样更容易
开发者之间的重复（interdeveloper duplication）：大家重复同样的东西
复用是解决重复一个最好的方法
Make it easy to Rease.让复用变得容易

正交性
如果两个或多事物中的一个发生变化，不会影响其他事物，这些事物就是正交的。
Eliminate Effect  Between Unrelated Things.消除无关事物之间的影响。
自足（self－contained）的组件：独立，具有单一，良好定义的目的。
正交的好处：提高生产效率，降低风险。
经常问问自己：如果我显著地改变某个特定功能背后地需求，有多少模块会受影响。
编码：让代码保持解耦，避免使用全局数据；避免编写相似地函数

可撤销性
如果某个想法是你的唯一的想法，在没有什么比这更危险的事情了。
一个灵活的框架随时适应变化的需求。
“薛定谔的猫”——任何结果都是可能的。
需求随时在变，而软件就变不起了，如果连软件框架都变来变去，那软件一定会失败。

曳光弹
做软件的时候可以时不时地抛出一个曳光弹，看看打中目标没有。
Use Tracer Bullets to find the Target.用曳光弹找到目标。
曳光弹代码并非用过就扔的代码，你编写它是为了保留它。
曳光弹代码有点：
用户能够及早看到能工作的东西；
开发者构建了一个他们能在其中工作的结构；
有一个集成的平台；
有了可用于演示的东西；
能感觉到工作的进展；
原型制作生成用过就扔的代码；曳光弹虽然简约，但却是完整的，最终构成系统骨架一部分。

原型与便笺
为工作流和应用逻辑等动态事物制作原理，便笺是一个很好的选择。
应制作原型的事物：
1.架构；2.已有系统中的新功能；3.外部数据的结构或内容；4.第三方工具或组件；5.性能问题；6.用户界面；
怎样使用原型：
在制作原型时可忽略的细节：正确性，完整性，健壮性，风格；
用一些“胶合剂”把组件粘起来
用便笺、索引卡片在白板上将系统建模；
原型嘛，又不是曳光代码，用完就扔了它。

领域语言
语言的界限就是一个人的世界的界限；
用业务的语言去描述业务问题，而不用编程语言，这样就不会钻牛角尖。
举个例子：在一组X.25线路上侦听由ABC规则12.3定义的交易，把它们转译成XYZ公司的43B格式，在卫星上行链路上重新传输，并存储起来，供

分析使用将来。
剪裁后的小语言：
From X25Line1 (Format=ABC123){
  Put TELSTAR1 (Format=XYZ43B);
  Store DB;
}
用户又添加一个需求：不应存储余额为负的交易，而应以原来的格式在X.25线路上发送回去：
From X25Line1 (Format=ABC123){
  if (ABC123.balance<0){
    Put X25Line1 (Format=XYZ43B);
  }
  else{
    Put TELSTAR1 (Format=XYZ43B);
    Store DB;
  }
}
Program Close to the Problem domian（靠近问题领域编程）
使用小型语言扩展现有语言

估算
Estimate to avoid surprise（估算，以避免发生意外）
130工作日和6个月，哪个显得更精确呢？
估算来自：
理解提问内容，注意问题域的范围；
建立系统的模型；
把模型分解为组件；
给每个参数制定值；
计算答案；
追踪估算能力；
Iterate the Schedule with the Code.（通过代码对进度表进行迭代）