前段时间抽空阅读了程序员修炼之道的第一章。从书中充满哲学的小故事，以及作者的领悟，受到了许多的启发。所以对这本书的兴趣便更加浓烈，静下心来仔细阅读。这两周，认真的阅读了此书的第二章：注重实效的途径。在软件开发的各个层面中，有多的提示和诀窍。有些想法已经几乎成为公理，另一些过程大家都在使用。可是没有人将这些系统的总结。而这一章，作者便将这些想法和过程集中在一起。下面是我阅读这一章的一些读书笔记
头两节：“重复的危害”，“正交性”关系十分紧切。“重复的危害”提醒我们不要再系统各处对知识进行重复。“正交性”提醒我们不要把任何一项知识分散在多个系统组件中。
重复性的危害：
DRY原则：系统中的每一项指示都必须具有单一，无歧义，权威的表示。这个原则让我们对于软件开发更易于理解和维护。这是 注重实效的程序员的工具箱里最重要的工具之一。
重复大体可以分为下列几种： 强加的重复、无意的重复、无耐性的重复、开发者之间的重复。强加的重复可以通过编写代码生成器，针对文本生成不同语言平台的代码。 尽量让低级的知识放在代码中，将注释保留 给其他高级的说明。建立文档到代码的生成机和语言问题解决。无意地重复原因来自信息结构的不规范。无耐性的重复究其原因就是一个字 懒。开发者之间的重复可以通过高层设计避免。
正交性：两条直线相交成直角，两条直线互不相依，沿着某条直线移动，投影到另一直线上的位置不变。在计算机中，这个术语用来表示某种不相依赖性或是解耦性。如果两个或多个事物中的一个发生变化，不会影响其他食物，这些事物就是正交的
正交性可以提高效率，降低风险
下一节可撤销性 ：不存在最终决策。为了达到可撤销性，需要灵活的架构，使用项CORBA技术能够讲项目某些部分与语言分割开
接下来的两节也是相关的，“曳光弹”中讨论了一种开发方式，能让我们同时搜集需求、测试设计、并实现代码。“原型与便笺”告诉我们在曳光弹开发不适用的情况下，怎样使用原型来测试架构、算法、接口以及各种想法。
曳光弹：先动手，然后观察各种反馈，立即改进。曳光弹方法适用于新的项目。注重实效的程序员往往更喜欢使用曳光弹。曳光开发与项目永不会结束的理念是一致的：总有改动需要完成，总有功能需要增加 这是一个渐进的过程。
曳光代码方法有许多优点：用户能够及早看到能工作的东西、开发者构建了一个他们能在其中工作的结构、你有了一个集成平台、你有了可用于演示的东西、你将更能够感觉到工作进展。但是曳代码不能百分之百确定该去往何处的情形下使用这项技术。
原型与便笺：原型制作与完全的制作对比成本低很多，举例轿车制作商可以为某种新车设计不同的原型，目的是测试轿车的具体方面-空气动力学，结构特征等。同样道理，软件产品也可以使用原型制作，利用不同材料制作原型，可以是白板上的图形、绘图工具绘制的产品图等等。但是，如果发现自己处于不能放弃细节的环境中，需要问自己是否采用该方法而转而使用曳光弹方法。
应制作原型的事物：
- 架构
- 已有系统的新功能
- 外部数据的结构或内容
- 第三方工具或组件
- 性能问题
- 用户界面设计
原型制作中可忽略的细节：- 正确性：虚设数据
- 完整性：提高有意义的事物
- 健壮性：错误检查
- 风格
制作架构原型：
- 主要组件的责任是否得到良好定义？是否适当？
- 主要组件间协作是否得到良好的定义
- 耦合是否得以最小化
- 你能否确定重复的潜在来源
- 接口的定义和各项约束是否可接
- 受每个模块再执行中能否访问其所需的数据？是否在需要时进行访问
领域语言中作者给了一些关于计算机语言的适度的建议
估算：学习估算，并将此技能发展到你对事物的数量级直觉的程度，你就能展现出一种魔法般的能力，确认他们的可行性。在进行估算的过程中，将会加深对程序所处的世界的理解。所有的估算都以问题的模型为基础，任何估算练习的第一步都是建立对提问内容的理解。理解提问的内容、建立系统的模型、把模型分解为组件、给每个参数指定值、计算答案、追踪自己的估算能力、估算项目进度，便是估算的大体步骤。
以上便是这几周阅读的笔记与感受，接下来的阅读相信作者能给我带来更多的启发与感悟。