读《程序员修炼之道——从小工到专家》
在没有足够的实践之前，总觉得“知易行难”，然而实践多了，却忘了规矩，转变成“知难行易”。就像驾驶，刚开始学习，怎么打方向怎么配合油门刹车，知道是知道，总不协调；但学会后，各种不遵守道路交通的规章制度，不系安全带还非法超车，导致事故频发后果严重。我读这类方法论的书就是这种感觉，她站在很高的角度去总结实践，所以随着实践的积累，每次阅读总能获益更多。 注重实效的哲学 负责，不要容忍破窗户。做变化的催化剂。定期投资自己的知识资产。学习交流的方法，说什么和怎么说同样重要。让质量成为需求问题。 “Broken Windows”理论，讲及时改正错误，就好像撒一个谎后面就得用无止境的谎言来圆。石头汤和煮青蛙是一体两面的问题，可以用好的希望让村民往煮石头的汤锅里加各种好食材，最终all-win；相反，如果青蛙在加热的锅里，它会因为没注意到渐变的环境而被煮熟。 注重实效的途径 Don’t repeate yourself 不要重复自己。让事物正交以消除相互影响。要灵活可撤销。用曳光弹、原型、便签来验证。靠近问题领域编程。估算。 DRY是非常出名的法则了。正交是独立和自给自足的属性。曳光代码是完整的并构成最后系统骨架的一部分，原型则用过就扔，便签只用几张小卡片去模拟系统。估算，“养成在开始猜想之前先思考范围的习惯”，“使用的单位会对结果的解读造成影响”，比较一下——半小时到家vs.如果不塞车30分钟到家。 基本工具 纯文本。学习一种文本操纵语言。shell。用好一种编辑器，让它成为双手的延伸。源码控制。编写代码生成器。调试。 调试，修正问题而不是指责，首先不要恐慌，到达bug现场，重现bug，让数据可视化，追踪它，使用隔离，不要假定要证明。还有橡皮鸭调试法。 注重实效的偏执 按合约设计。早崩溃，不要破坏。断言，异常。配平资源。 按合约设计，如果调用者满足了例程的所有前提条件，例程应该保证在其完成时，所有后条件和不变项将为真。配平资源，分配某项资源的例程或对象应该负责解除该资源的分配，以相同的次序分配，以相反的次序解除。 弯曲，或折断 解耦。元程序设计，要配置，不要集成，将抽象放进代码，把细节放进元数据。时间耦合，并发。视图模型分离。利用黑板，模块匿名异步地交换数据。 解耦，得墨忒耳法则：某个对象的任何方法都应该只调用属于以下情形的方法——它自身，传入该方法的任何参数，它创建的任何对象，任何直接持有的组件对象。 当你编码时 不要靠巧合编程。算法速率估算。重构。编写易于测试的代码。不要使用不理解的代码向导。 重构，Martin fowler，不要试图在重构的同时增加功能；在重构之前确保你拥有良好的测试；采取短小、深思熟虑的步骤。 怎样深思熟虑地编程：总是意识到你在做什么，不要盲目地编程，按照计划行事，依靠可靠的事物，为你的假定建立文档，不要只是测试你的代码还要测试你的假定，为你的工作划分优先级，不要做历史的奴隶。 在项目开始之前 挖掘需求，“找出用户为何要做特定事情的原因，而不只是他们目前做这件事情的方式”，管理需求增长。“你所需要的只是真正的约束，令人误解的约束，还有区分它们的智慧”，面对棘手问题，不要先入为主地忽略一些看似不可能的解决方案。有“启动恐惧症”症状的时候，可以开始构建原型了。“编写程序规范就是把需求规约到程序员能够接管的程度的过程”。形式方法有用，但不一定能制作出更好的设计。 注重实效的项目 注重实效的团队：质量只可能源于全体团队成员都做出自己的贡献；团队无需拒绝无法控制的变化，你只需注意到它们正在发生；创立品牌以帮助与外界交流；指定项目资料管理员，管理不要重复自己；按照功能划分团队。 自动化——编译，测试，构建。早测试，常测试，自动测试。把代码和文档紧密地结合在一起，代码注释，可执行文档。文档的表现形式应该独立于其内容。"项目的成功是由它多大程度上满足了用户的期望来衡量的”，只能温和地超出用户的期望。为在自己的作品上签名而自豪。
