最近读了《卓有成效的程序员》，感觉收获颇大。这是一本写给程序员的难得的好书。书中大都是一些浅显的道理，但作者将这些东西加以收集、归纳、总结，并最终成书。作者为了收集各种提高效率的工具和方法，东奔西走，可谓费了一番苦心。
我觉得此书第一部分总结的一些法则非常好，我提取了一下：
法则：
1.加速法则
关注本质，而非形式
一个应用程序列表的有用程度与它的长度成反比
程序员的很多时间都浪费在找东西上
华而不实的东西中看不中用
键盘输入总比导航快
首选键盘而非鼠标
地址栏是Windows资源管理器界面中最高效的部分
花点时间来学习你手边的所有隐藏的快捷键
环境切换会消耗时间
成批复制粘贴要比反复多次复制粘贴快
忘记历史就意味着你得再输入一遍
嵌入图形化工具的命令提示符让你鱼与熊掌兼得
在上下文中学习IDE快捷键，而不要去背长长的列表
当你第二次输入一个复杂结构时，将它做成模板
如果要对多行文本做同样的操作，就应该找出其中的模式，并把它记录为一个宏
不要总是重复输入相同的命令
每天花一点点时间来使每一天都更高效
2.专注法则
精力越集中，思维越缜密
排除干扰：隔离策略，关掉不需要的提示，创造安静时间
草堆越大，从中找到一根针就越难
不要问文件树，要搜索
使用多显示器
虚拟桌面可以让原本杂乱无章的一大堆窗口变得整洁
3.自动化法则
不要重新发明轮子
用Selenium浏览网页
不要浪费时间动手去做可以被自动化的事情
用Windows Power Shell替代批处理文件
驯服Subversion命令行
以创造性的方式解决问题，有助于在将来解决类似的问题
是否应该自动化的关键在于投资回报率和缓解风险
研究性的工作应该放在时间盒里做
别给牦牛剪毛
4.规范性法则
对于任何你不自己去构建的东西，只在版本控制中保存一份副本
使用标准的构建服务器
通过复制粘贴来复用是邪恶的，不论你复制粘贴的是什么
利用虚拟平台使项目依赖标准化
不要让对象 - 关系映射工具（O/R映射器）违反规范原则
通过扩展。开放类（open class），或者部分类（partial class） 来为生成的代码增加行为
始终保持代码和数据结构的同步
过时的文档比没有文档更糟，因为它会主动误导你
任何需要费劲创造的东西，都让它的创造者欲罢不能
白板 + 数码相机强过任何CASE工具
尽量生成所有技术文档
重复是软件开发中最大的阻力
工具：
书中，还提到了大量的提高效率的工具，都是非常不错的。相信很多人都有自己的一个列表，下面是我电脑中必不可少的几款软件：
1. FireFox 及其各类插件
2. Launchy启动加速器
3. Total Commander
4. ClipX多重剪切板
5. EmEditor文本编辑器
6. Vistual Studio的VA插件
7. Search And Replace
8. Everything
9. Miranda IM
10. ....
感触：
1. 愤怒的猴子
在书中的第二部分，提到了很多实践相关的内容。让我感触最深的是“愤怒的猴子”的故事：
“早在20世纪60年代（那时候科学家们可以做任何疯狂的事情），行为科学家们进行了一项实验。他们把五只猴子和一架活梯放在一间屋子里，并在天花板上挂了一串香蕉。这些猴子很快就想到它们可以爬上梯子去吃香蕉，但每当它们靠近活梯的时候，科学家们就用冰水浸满整个屋子。我想你能猜到会发生什么：一群愤怒的猴子。很快，再没有一只猴子会去靠近那个梯子了。
之后，科学家们将其中一只猴子替换成另一只没有忍受过冰水折磨的新猴子。这只新猴子所做的第一件事就是直奔那架梯子，但当它这么做时其他所有猴子都痛打它。它不明白为什么，但很快就学乖了：不要去靠近那架梯子。科学家们逐渐将最初的那些猴子都替换成新猴子，直到这群猴子中谁都没有被水浸泡过，然而它们还是会去攻击任何靠近梯子的猴子。
这说明了什么？软件项目中许多惯例之所以存在，就因为”我们一直是那样做的“。换句话说，是因为愤怒的猴子。”
我们小组在制定C++相关的代码规范时就遇到过无数类似的问题。比如，在制定变量的命名规范时，我们针对是否采用匈牙利命名法争论了很久。有的人认为， 几乎以前看到的所有C++代码都采用了匈牙利命名法，甚至，微软定义的所有API都使用了此类命名法。刚开始，我也是有同样的疑惑。
后来，我们经过仔细分析C++匈牙利命名法由来，渐渐感觉我们就是那些愤怒的猴子，盲目跟从前人的方式，缺乏打破传统的勇气。C++有着其特殊的历史原因，很多标准一直沉淀下来并很少改变。我们再看看后来新生的那些编程语言，C#, Python…… 都抛弃了匈牙利命名法，同时再看看现在C++前沿的C++ 0x以及现在出版的一些书中，也渐渐放弃了对匈牙利命名法的使用。因为类型的意义在对象模型中越来越弱化。因此，最后我们放弃了匈牙利命名法这个老古董。
2. 敏捷开发
这本书带有强烈的ThoughtWorks色彩，敏捷的思想贯穿全书，包括测试驱动设计，白板，结对编程。这也让我对敏捷产生了更加强烈的兴趣。 其中有一段测试驱动开发TDD的一段故事：
“记得第一次和一些已经习惯于单元测试的开发人员一起动手开始修改代码时，我也是非常紧张，因为大量的修改往往会破坏很多东西，但他们看起来丝毫没有犹豫。逐渐地，我也放下心来，因为我慢慢地认识到：有了测试的保证，完全可以放心大胆地去修改代码。”
3. 有趣的故事
书中还有一些有趣的故事，比如作者的一个朋友在和别人结对编程时，为了养成同伴使用快捷键的习惯，每当同伴未使用快捷键时，他都会要求将操作撤销，然后要求使用快捷键再重复操作3次。然后，在其凶狠的眼神中，同伴很快掌握了快捷键。
总结：
这本书很薄，蕴藏的道理却不少，相信每个读过它的人都会从中收获。读过之后，我们不应该局限于书中提到的某些小技巧， 或是书中某一个细节，毕竟，提供效率的方法有很多很多，法则也有很多很多，一本书很难将其穷举完。我们应该从书中吸取其思想，并在实际工作和学习中不断总结，做一个真正的“卓有成效的程序员”！
