程序员修炼之道

  身为一名程序员，当一本叫做《程序员修炼之道》的书出现在面前，又怎能忍住不去看呢？于是，出现了下边的读书笔记。
 该书确实博大精深，包含了很多内容，但很多都是点到为止。那种心中有剑的感觉，跃然纸上，或许高手都是如此吧。根据多年武侠观摩经验，一定要把不懂的记下来，以后肯定大有用处。那就记。
 第一章：注重实效的哲学（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）
 注重实效的团队，再次祭出了第一章的那几个原则。
 足够好的软件。
 无处不在的自动化。
  项目编译（生成代码，回归测试）；
  构建自动化；
  自动化管理（网站生成，批准流程）；
 无情的测试

 该书没有太多的代码，应该作者是在一个哲学的高度来教授自己的经验。可以归类为到软件方法学，只是他的方法没有明确的定义，只有一个原则：实效。