这个书名看起来似乎有些莫名其妙，因为其实它包含了三本书：

• Practices of an Agile Developer（中文名《高效程序员的45个习惯》，即将出版）
• The Productive Programmer（中文名《卓有成效的程序员》，已出版）
• The ThoughtWorks Anthology（中文名《软件开发沉思录：ThoughtWorks文集》，已出版）

虽然最后一本书的中文标题里包含“沉思”字样，但总体来说其实这三本都是实践性的很强的书，基本上是会告诉你“怎么做”——当然同样也会告诉你为什么。基本上这三本小于等于200页的小册子陪伴了我半个多月来的上下班，上厕所已经睡觉前的时间，也带给了我不少体会和思考。

有人可能会说，大学教育应该加强培养学生的实践能力，不过我的看法正好相反。我倒想说，在学校里就别再生产实践上投入了，这是教不出来的。学校的老师现在基本上都是100%的博士毕业，科研出身，本身工业实践可能就不足，除了照本宣科（而这实践性的“本”可能本身就不怎么样），又能指导学生什么东西呢？记得有段时间我又重新混迹于学校的BBS了，在系版上和讲授Web基础课程的老师争论“标准布局方式”，老师坚持认为布局就该使用table，而CSS只是用来填充样式，而并非用来布局的。但此时已经是2008年了，我想只要简单关心一些业界发展，也不应该出现这个情况。但是对于老师来说，他们的目标是科研，就像那位老师，除了这堂课，又何必了解Web开发的发展动态？而大学里应该为学生以后发展打下坚实的基础，授以“渔”，授以“能力”，至于实践性的内容，自有实践来培养，学校就不要做这些本不擅长的事情了，几乎不可能做好。

我大学读的是软件学院，比较注重“实践”。记得当时大一结束后系里组织项目组，由于我专业成绩比较好于是“光荣入选”。于是近20个人的项目组分为了几个小组，各由1个研究生作PM。还有一个需求分析组。然后我们使用标准的瀑布型开发方式，从需求分析开始，产品设计，用例图，时序图，类图一个一个地画。记得文档的页数，UML的复杂程度（当时叫“专业”程度）都是值得自豪的事情。最后很显然，项目失败了。似乎这样轰轰烈烈的项目开发行动也没有出现过，大一的学生都早早进入各实验室进行有针对性地科研性培养，这点还是让我非常高兴的。

不知道现在的大学教育还有没有这样的情况，不过在我现在看来，似乎在那时我积累了不少误区，而这些误区基本上都产生在“实际生产”方面。例如我被不断教导“语言是没有用的，思想是关键”，但我几年下来我愈发认识到“语言影响思想”；例如我也被不断教导“程序员是没有前途的，要做PM”，导致我当时也总喜欢谈“设计”谈“项目管理”，而现在我坚持认为自己是“光荣的程序员”。还有例如“做作测试没有意义”等等，诸如此类，不一一列举了。总之，我当时学习了许多的“反模式”，这些东西在我接触“敏捷”，接触实际生产过程，接触前人在实际生产过程中总结的经验之后都被一个一个推翻了，几乎一个不留。当时我也很痛苦，认为自己过去浪费了很多时间。但是现在想想，这也是我的积累，至少我知道了什么是错的，我知道某个东西为什么是对的，而并不都是纸上谈兵。还有既然已经经历过一次思维转变，我想我也已经可以坦然接受未来新一轮的革命。想着想着，我也就坦然了。

因此，如果您也有这样的经历，我想也没有任何问题——看准之后，马上改变。在思维改变的过程中我看了很多书，其中有一本值得在现在提起，那就是《The Pragmatic Programmer: From Journeyman to Master》（中文名《程序员修炼之道——从小工到专家》）。这本书完全是实际经验的总结，一条条建议基本上都是精华，现在看来亦有常读常新之感。不过这本书的最大问题就是，说的很多，信息量很大，但相对比较简单（条条扩充就变成另一本《代码大全》了），于是对于没有一定经验的初学者来说，难以引起共鸣。当时我在看这本书的时候的心态也是“好书，讲的是真理，一定要接受”，而并没有进行更多的反思和比较，在我现在看来这种读书方式是很危险的，我的幸运之处也在于“盲从”对了人。

之所以提起这本书，是因为《Practices of an Agile Developer》（中文名《高效程序员的45个习惯》，即将出版）被看作是它的后续，虽然我认为这“后续”并没有达到前辈的高度——不过也正因为如此，我看来它可能更适合初学者，或者说更加实践一些，更贴近普通生产过程，更容易按部就班的干——几乎告诉您应该怎么做，并且需要考虑哪些东西了。这本书关注的是如何敏捷地构建出成功的软件项目，其中涉及到各个方面。如一上来讲的并非如何进行“项目管理”（可能敏捷本身就是淡化传统软件开发的管理，讲究的是“自我管理”），它讲的是“态度”，作为每个开发人员来说该如何在项目中把握自己的做事方法。后来又谈了开发人员的自我发展，如何开发，如何调试，如何交付，如何协作等各个话题。

这本书把一个实践分为三个部分：“魔鬼（错误的做法）”，“天使（正确的做法）”以及“平衡的艺术”。有趣的事，至少我从自己身上或身边，也可能是工作上，或是社区里发现了几乎一一对应的“魔鬼现象”。例如书中一开始讲的“态度”中提到“对事不对人”，这难道不正是最近博客园的“热点问题”吗？此外，这本书吸引我的另一个原因是书中的许多说法让我非常赞同，或者说“有共鸣”。例如书中说到“持续学习”，“架构师必须写代码”，“用写博客等方式进行总结”，对我来说真可谓“正中下怀”。

这本书最大的问题并非是书中哪里写的不对，而是有些“成功学”的意味——许多“道理”的确都是正确的，但是关键还是要靠“执行”。说到底，不执行，知道再多正确的做法也没有用。而且，在我平时看来，大家不是不知道该怎么做，而是“不愿意去做”。例如谁都知道要对项目负责，但是在别人都不负责的时候，你还愿意负责吗？书中说要交流要分享，但是各位也一定听到过许多声音，例如说“要有保留，否则你就失去了价值”——咋听上去真很有道理，有些更直接就是书中所列举的“魔鬼的诱惑”。书里也谈到一些“平衡的艺术”，但和现在流行的一些“办公室政治”方面来看，算是小巫见大巫了。我是理想主义者，有人说我幼稚，所以您也要对我的说法进行独立思考。:)

《The Productive Programmer》（中文名《卓有成效的程序员》，已出版）一书与前者不同，它的目标是“个人效率”，而不是“项目开发”。

这本书分为两个部分，第一部分主要讲的是工具的使用，其中提到了许多提高开发效率的方式，例如如何使用虚拟桌面，如何使用宏、命令行和快捷键等等——里面的确提到了许多我原本不知道的使用方式（例如把资源管理器的“根目录”固定住）。对于Windows程序员来说，还有相当部分可以帮助我们了解其他平台，如Unix上的一些开发文化（如PowerShell和cygwin的使用。Unix平台是面向程序员的平台，其中总结出了许多开发经验同样可以运用在Windows平台上——即便有些*nix程序员不太相信这点，但是我对此深有体会。而书中的第二部分是“实践”，通俗地说便是“如何写出更好的程序”，其中谈到了单元测试，谈到了设计方式，谈到了代码检查工具等等——说实话，我认为与第一部分相比它并不怎么出彩，有些老生常谈的味道，随便找本讲敏捷编程的书就会谈到这些内容——就好比那《45个习惯》。

既然是在进行“个人效率”的修炼，这更加涉及到“执行”问题了，例如谁都知道快捷键能提高效率，但是你愿意努力去背快捷键，而不是继续自己点菜单的习惯吗？还有便是，这本小册子讲的还是简单了，当您看过了这本书之后，不妨再多关注一下它的提纲（好吧，其实就是“目录”），然后针对其中的每一点再作进一步的挖掘。

最后便是《The ThoughtWorks Anthology》了。这本书是一群乐于思考，善于总结和分享的人的心得体会。其实每个公司都有许多项目，但为什么ThoughtWorks总是给人一种“盛产思想领袖”的感觉呢？我认为这关键还是以Martin Fowler为首的“思想家”们的作用吧。他们在不断地进行“思考”和“总结”，更重要的是不断的分享“分享”——我并不是在夸他们nb，我的目的是想说“其实你我也可以这么做”。当然，我更不是在轻视他们，我也乐于和他们这样的人一起工作。

刨开前言，这本书收录了13篇文章（外国人咋不忌讳这个数字了？），有项目管理方面的：如何走好从“开发完毕”到“交付成功”这最后几步路，如何使用“迭代经理”这个角色等等；也有项目实践方面的内容：如何使用Ant构建项目，如何进行自动化的“一键发布”，如何进行性能测试等等。也有一些编程方面的实践，如DSL构建，多语言开发，对象“健身操”等等。基本上，可以认为是精华，值得一读吧。这本书有些部分的确让我开了眼界，让我了解了不少我原本不太知道的内容（尤其是项目管理方面），这感觉好像我在大学里第一次看到一些项目管理书一样：“原来，这才是专业的做法啊”。但是，现在我比当年要谨慎了许多，很多东西我还是在项目开发过程中尝试一下再发表意见吧。至于其他方面也大都不错，可能这种类型的“总结”还是挺吸引我的。

总之，这三本书都值得一读。但是这有个前提，首先您得主动思考而不是一味地机械吸收，但更重要的可能还是需要有效地“执行”——而这点可能只能靠您自己的，别人很难给予有效的帮助吧

忘说了，这三本书我看得都是中文版，翻译地挺通顺的，没啥读不明白的地方。