身为一名程序员，当一本叫做《程序员修炼之道》的书出现在面前，又怎能忍住不去看呢？于是，出现了下边的读书笔记。
该书确实博大精深，包含了很多内容，但很多都是点到为止。那种心中有剑的感觉，跃然纸上，或许高手都是如此吧。根据多年武侠观摩经验，一定要把不懂的记下来，以后肯定大有用处。那就记。
第一章：注重实效的哲学（A Pragmatic Philosophy）
说实话，第一遍看完这章，我只记住了“破窗户理论”和两个寓言--石头汤和煮青蛙，却不知道注重实现的哲学到底长什么样-_-!，没办法，天生愚钝，再找一遍吧，找到如下关键字：
一. 负责，也就是咱们所说的干一行爱一行，也就是职业素养；
二. 变化，就是所谓的大局观；
三. 合理，就是做“做够好的软件”。完美，只存在于梦里，或许梦里也没有完美；
四. 学习，不断的提供自己；
五. 交流，这里说的不是和计算机交流；
爱岗敬业，注重实效，注意方法，积极进取，以人为本，这是做事的基本准则吧？这一章充分体现了哲学的普适性。
第二章：注重实效的途径（A Pragmatic Approach）
这章的内容涵盖了软件开发的各个方面，包括编码、架构、项目管理、开发方式、估算等。
这章的实质，是介绍软件开发的公理。
公理一. DRY原则
话说一天，一个叫Rails的小孩来到世界最牛的武馆--java武馆，用DRY(Don't Repeat Yourself)和CoC(Convention over Configuration)技压群雄后，他的两大绝技，便为世人所追捧。
那么，何为DRY？就是拒绝重复，可重复真的那么好决绝吗？那还得先看看重复的伎俩。
强加的重复（imposed duplication）。包括信息的多种表示，注释，文档，语言问题。
无意的重复（inadvertent duplication）。
无奈性重复（impatient duplication）。
开发者之间的重复（interdeveloper duplication）。
公理二. 正交性
降低各模块的耦合性（解耦性），也就是spring的本质，具体表现为面向接口编程，AOP。
减少团队组织的重叠。
公理三. 可撤销性
有容乃大。具体表现为灵活的架构。
领域语言（DSL？）
第三章：基本工具（The Basic Tools）
工欲善其事，必先利其器，没什么好说的。文本编辑器，shell，源码管理，文本操作，代码生成。。。总之，人之所以为人，是因为人懂得创造工具，使用工具。
第四章：注重实效的偏执（Pragmatic Paranoia）
按合约编程。于DDD有何联系？这应该就是rails和grails里领域类的约束吧？有一个叫contract4j的DBC项目，由于不太喜欢annotation的contract方式，也没有时间过多研究。看来这块东西需要好好补充下。
断言式编程--如果它不可能发生，用断言确保它不会发生。
正确使用异常。
配平资源。程序的因果报应说，为了来世（程序上线后）的美好，一定要确保写程序时有始有终。所幸，我们的世界已经不那么原始了，spring里的模板类，动态语言(ruby/groovy)里的文件操作闭包，都可以帮助我们往升彼岸。
第五章：弯曲，或折断（Bend,or Break）
解耦与得墨忒耳法则（google了下Demeter，介绍如下：德墨忒耳是希腊奥林珀斯十二主神之一，罗马名字刻瑞斯(Ceres)。她是宙斯的姐姐，掌管农业的女神，给予大地生机，教授人类耕种，她也是正义女神，感觉这里说的不是这个人。。。）
函数的得墨忒耳法则：某个对象的任何方法都应该只调用属于一下情形的方法：
它自身
传入该方法的任何参数
它创建的任何对象
任何直接持有的组建对象
元程序设计,一个古老而又时髦的词，很多内容，暂且不表。
时间耦合--关于程序的时间--并发和次序。
第六章：当你编码时（While You Are Coding）
这章主要介绍了一些编码时的经验，包括：算法速率（big O）,重构，测试，对向导的警惕。可以看作是对最新的编程方法的一个选择和总结。
第七章：在项目开始之前（Before The Project）
挖掘需求，挖掘，说明需求分析的复杂。需求文档是对需要完成的某些事情的陈述（会保持抽象），它不是和用户的聊天记录。商业政策经常会改变，所以我们并不想把它们硬性的写入需求。那么怎么办呢？把需求文档和策略文档分开，并用超链接吧两者连接起来。需求应该深入到商业逻辑的本质，而不能知其然，不知其所以然。也就是确定DDD里的模型。
当遇到不可能解开的谜题时，考虑它是否是真正的约束。
构建原型比空谈更有实效。
作为注重实效的程序员，应该倾向于把需求搜集、设计、以及实现视为用一个过程--交付高质量系统--的不同方面。
不要做任何形式的奴隶。
第八章：注重实效的项目（Pragmatic Projects）
注重实效的团队，再次祭出了第一章的那几个原则。
足够好的软件。
无处不在的自动化。
项目编译（生成代码，回归测试）；
构建自动化；
自动化管理（网站生成，批准流程）；
无情的测试
该书没有太多的代码，应该作者是在一个哲学的高度来教授自己的经验。可以归类为到软件方法学，只是他的方法没有明确的定义，只有一个原则：实效。