如果真的有机会和高手一起工作，有时，你会发现，从具体做的事来说，这些高手做的事并不像想象的那么高深，甚至可以说很简单，简单到换了谁都能做。于是，心中的高手形象逐渐开始动摇，难道令N多人景仰的高手就是这个样子。
不知道你有没有想过这样一个问题，同样的事，如果没有高手的参与，换你来做，结果会怎样呢？
老大给我讲了一个他当年和Ward Cunningham在一起工作的故事。每天做的工作就是日常的测试驱动开发，写测试、写代码，所有的一切都是异常简单，下午从不会耽误喝咖啡的时间，到点也就正常下班。一个月后，要做的事情做完了，没有觉得有什么特别之处。不过，回想了一个月前对于这个项目的看法，老大突然发现，这一个月里原来做了许多事情：一个月前，他还觉得这是一项不可能完成的工作。
我最近的一个项目里，和我一起工作的是有我们中国区的CTO。这个项目的前期是一个类似于可行性论证的工作，项目最初，他为整个项目的结构订下了一个基调，让整个项目的结构显得特别清晰，准确的说，应该是很简单，简单到让人觉得理所当然。单从工作的具体内容来看，他并没有在这个项目里面做太多的事情，但从另外一个层面来说，正是他做的前期所做的工作，让后面的工作变得容易了许多。
这么一说，是不是有一种高手形象顿失的感觉。其实，高手通常不会觉得自己是高手。多年积累下的，只是良好的工作习惯而已。他们知道，自己是普通人，自己不能应付过于复杂的东西，于是，把自己要做的事分解成一些非常简单的小事。只要把这些微不足道的小事做好了，所谓的大事便也做成了。
我很喜欢读的书中，有几本书出自贝尔实验室，比如《程序设计实践》、《Unix编程环境》、《C程序设计语言》等等，每一本都是那么轻薄。这些书里面的内容读起来都是那么轻松，每一步做的事都让人觉得太过简单，但回过头来，可能你才发现，原来一些貌似很复杂的工作已经完成了。
曾有一段时间，我一直觉得自己掌握的东西不够复杂，为此，我总是惴惴不安。后来发现，但凡我学过的东西本质上都很简单，于是我想，到底怎么才能让自己复杂起来。读过那几本书之后，我释然了：做事本就该是做简单的事。如果你觉得复杂，多半是走错了路。
与高手共事，技术之外的东西，也许更值得学习。
在ThoughtWorks待了大半年，听的见的经历的最多的当然是敏捷。圣诞之夜，不妨整理一下现时心目中的敏捷。
提及敏捷，主要是两种反映，济世良药或是洪水猛兽，当然，也有人置身事外。其实，敏捷只不过是一种软件开发方法而已，与传统软件开发方法开发方法并无本质区别：敏捷也需要知道到底软件要干什么，所以，分析需求不可或缺；敏捷最终也是把软件提交给客户，所以，也要一行行把代码写出来；敏捷出的软件也会有错误，所以，测试阶段是不可缺少的；敏捷出的软件业务也会变化，所以，代码也需要维护；敏捷的情况下，为了在给客户展示，所以，偶尔也要加班……
如此说来，敏捷是不是和传统软件没有分别了呢？显然不是，任何事物一旦拉高到本质的高度，恐怕都没有区别了，就像“人”可以涵盖人这个物种，但事实上，人还有男人、女人、好人、坏人……等等众多区别手段。
相信大多数人有这样的感觉，念书的时候，总有那么一些怪物，看起来，玩得不比别人少，书读得不比别人多，但考试成绩总比别人。这样的怪物是怎样炼成的呢？说起来，很简单，他们懂得了一些学习的方法，所以，他们可以在同样的时间内，取得比别人高许多的结果。
做事，是有方法的。
好的做事方法绝对是大幅度的提高效率的。相对来说，敏捷就是一种好的工作方法。
敏捷重视人在软件开发中的价值，所以，在敏捷团队中，开发者在团队中地位很高，这让我们在心理上得到了极大的满足，于是乎，心情很是愉悦。在很多强调传统软件工程的团队中，开发者不过是一颗螺丝钉，一个可有可无的角色，受重视程度自然很一般，除了自力更生，心情上与敏捷团队不可同日而语。两种团队，我都经历过，差异极大。其实，无论在什么样的团队中，我们都要完成类似的工作——编写代码，但是，想必人人都清楚，心情对于一个人工作的影响。
除了完成工作，我们需要的还有发展。专业技能上的成长，除了自己摸索，更重要的还有吸收来自别人的营养。在传统的方法团队中，除了读书，只有偶尔大家的交流才能让人得到向别人学习的机会，大多数情况下，我们所能做的就是单枪匹马的孤军奋战。幸运的话，也许能够走上的正确的道路，大多数人必然会绕很大的圈子，更不幸者，也许就此失去了对软件开发的兴趣，或默默忍受编程带给自己的痛苦，或干脆离开这个是非圈。
在敏捷团队中，过程本身采用的一些方法就是前人经验的总结，比如测试驱动开发。结对编程可以让人有机会观察别人是如何工作的，从中吸取养分，这些细节是几乎不可能从书本或是课堂学到的，比如，在ThoughtWorks工作之前，我从未意识到快捷键对工作的帮助如此之大，当看到其他人按键如飞后，我决定在今后的开发中，尽可能多的使用快捷键。在两个人共同开发的过程中，我们有机会看到自己同伴对于一个问题思考的过程，这对于我们的提高绝对是有益的，特别是和一些高水平的人合作。良性循环和恶性循环显然不是一回事。
软件是为人服务的。软件开发是为了将软件创造出来，而不是为了为难开发团队。如果你曾经在传统开发团队工作过，提到这一点，脑子中多半会浮现出“文档”这两个字。敏捷团队也会写文档，但我们写的是那些对客户有价值的文档，而不是把时间浪费在那些为了过级而编写而且完成之后便会束之高阁的文档。不给自己找麻烦是很必要的。
敏捷和某些传统软件开发过程可以说是殊途同归，比如，CMM到了最高的级别，会向自适应的方向发展，而敏捷本身也是在过程中不断的进行自我调整，做到兵来将挡。当然，走到一起之前，二者的差别显得还是很大。
以上这些都是站在我——一个开发者——的角度体会的敏捷，显然，并不全面。某些人提到敏捷，还会有更加伟大的角度，比如，业务之类的，那不是我所擅长的。
既然敏捷如此之好，为什么敏捷团队还是如此有限？回到最初那个读书的比喻上，优等生的方法不见得是每个人都知道的。即便知道了，相信、学习到掌握还要有一个过程。敏捷是不是终极解决方案，我想不会，天外总有天，如果哪一天，我知道更好的方法，我愿意接受。
写下这些文字的时候，
Ruby 1.9.0发布了，感谢Ruby开发团队带给大家的圣诞礼物！
Away Day，字面的意思是，一个离开办公室的日子，鉴于今年刚刚搬进新办公室，出于对新办公室的喜爱，今年Away Day第一天的活动就放在了办公室里。
Away Day，公司一下子变得很热闹。原来驻扎西安的大部队来到的北京办公室，原本分散在北京和西安两地的中国区员工终于团聚在一起。ThoughtWorks Studio的两个团队——CCE和Mingle也在北京扎根。此外，还有不少从其他办公室来参加Away Day的同事和已经签约明年准备加入公司的毕业生。当所有人坐到一起的时候，我才第一次觉得ThoughtWorks在中国已经有很多人了。依稀记得我当初面试时，二三十个人围坐在桌边的情景。不到一年，我们壮大了许多。老大在讲话中回顾了当年和黄亮谈offer时的情景，颇有些忆往昔的感觉。
第一天的session内容很丰富，技术、招聘、公司策略、创新等等，应有尽有，甚至有人还组织了一个世界发展的话题。虽然是一次内部活动，但内容一点都不含糊，而且，讲者与听众通常很熟悉，所以，常常会有一些精彩的问答。据说，Jon Tirsen在介绍Erlang的session上，问到讲演者不得不说自己还不是太熟悉。我也亲见了一个session里面，一个“why not”让讲演者沉默了半天。
我也同样做了一个session，话题是关于招聘中的code review。因为在ThoughtWorks工作这段时间，除了写代码，干得最多的就是招聘了，而code review做得尤其多，几百个总是有的，所以，略有心得。原本我考虑讲一个技术的话题，但后来一想，Away Day是一个轻松的日子，讲生涩的技术会让大多数头疼的。事实证明，在Away Day中，技术讲座的听众相对来说会少一些，比如，徐X那个关于用Ruby做interpreter的话题，只有为数不多的人在场。:)
对我而言，做session并不是一个最好的选择。因为当天我还是花了不少时间在准备上，所以，我只听了很少的内容，有些遗憾。我的session是当天的最后一个，因为前面人的超时，我不得不用绕口令的速度进行快速讲解，否则，耽误了大家的晚饭，后果会很严重。
结束了session，就彻底进入到一个交流的环节。无论是当天的晚饭，还是第二天的出游，感觉自己几乎一直在和不同的人说话。在ThoughtWorks，我们是鼓励和不熟悉的人进行交流的，因为指不定哪天大家可能就会在一起工作，即便是简短的交流，也会为未来奠定一个良好的基础。
虽然是第一次参加Away Day，感觉不错！
我写blog，4年了。
4年，300篇，平均一年75篇，接近5天一篇。如果除去骁勇的第一年完成100篇，后面的是差不多5天半一篇。
印象中的自己，是一个少有长性的人。总有些三分钟热血，却很难坚持。随着自己年纪的增长，热血的次数，少了许多，坚持倒是比原来多了一些。blog，便是我的坚持之一。
回顾是一件有趣的事情。在ThoughtWorks工作，回顾是项目中的一种经常性行为。对于敏捷项目而言，回顾是一个必然，因为敏捷意味着需要根据情况的变化，及时进行调整，而回顾就是为调整寻找方向。
下面是我对自己blog人生的回顾。
做得不错的地方
* 一直坚持着blog。
* 写blog提高了自己的写作能力和表达能力。
* 为了不让自己胡说八道，强迫自己进行思考。
* blog给我带来很多朋友和不少机会。
* 逐渐形成了自己特有的blog风格。
做得不好的地方
* 更新频率越来越低，最初几天一篇，后来一周一篇，最近一段时间，更是延长到10天到半个月一篇。
* 风格很单一，尤其是最近一段时间，几乎都是一些技术性的文字。
* 评论比较少，这一点与写作风格有关，技术性的blog留给别人发言的机会比较少。
通常，回顾中还应该有一个项，叫做“改进的方向”。给自己订下一个方向，无疑于一个承诺。考虑到自己的惰性，承诺着实不是一个好的选择，于是我选择对自己放任自流。
坚持下去，既然自己觉得不错。
http://blogs.msdn.com/jaybaz_ms/archive/2007/11/09/parting-words-for-dear-friends.aspx
InfoQ的报道：
http://www.infoq.com/news/2007/11/criticism-from-microsoft-devlead
InfoQ China的报道：
http://www.infoq.com/cn/news/2007/11/criticism-from-microsoft-devlead
有一段时间，我一直想不明白一件事，软件开发中，是算法和数据结构那些实现技能更重要，还是软件设计和编写干净代码的能力更重要。前者的代表应该是微软和Google，后者的代表应该是ThoughtWorks。公司的侧重，在这些公司的招聘过程中，体现得尤为明显。
所以，我们经常看到一群人为了证明某一个方面的重要性，举出无数的理由试图证明另一方面不重要，这样的争论有如语言之争一样，没有任何一方可以说服另一方，结果便是一群人争论半天，回去各自做各自的事去了。实际上，甚至可以说两者都不重要，因为有为数不少的程序，是在没有太多技术难度，也深入考虑设计和架构的情况下完成的。这也是很多人抱怨自己的工作没有技术含量的原因。
在我看来，两者都很重要。
过分强调某一个方面，导致的结果就是另一方面的欠缺，这一点尤其容易出现在有着很强实现本领的人身上。当我们说某人很牛时，多半指的是他能实现出一些别人无法轻易实现的东西，显然，没有人愿意称一个只会写“Hello, World”的人为牛人。所以，一旦不小心被当成了牛，很容易就真的以为自己是牛了，所以，忽略了另一个方面，对于工程很重要的方面。
有一种说法是，某人牛到写出的代码别人看不懂，这一方面是这个人实现本领过强，另一方面也说明，这个家伙着实不好合作。当然，某些算法初读起来确实令人费解，但大多数情况不是这样。我着实见过一个被周围的人当作牛的人写的代码，一份让我觉得愤慨的代码，除了实现功能之外，一无是处。在工程中，设计出良好的结构，编写出很好的代码，对后续的开发和维护都是一种重要的基础。当某人因为点灯熬油成功修复一个bug而受到大家吹捧的时候，请别忘了，多半这个bug就是因为他自己没有良好工作习惯而埋下的。
微软开发主管的临别赠言为这种情况添加了一些注脚，微软是一个大家认为的牛人集合体，出现这种情况，只能说明，他们软件开发的另一面重视不够。
反方向的情况似乎并不明显，没有人会因为自己有良好的设计功底而忽略了自己的实现技能，毕竟，有高超实现技能的人，才是“牛人”。
不过，强调实现技能这点也有好处的。随着微软和Google对实现技能重视的宣传，大家越来越重视这些基础的东西，这让很多人，尤其是还没有明确自己努力方向的学生们看到了一丝曙光，因为这至少不会让他们一无是处。
我一直喜欢程序设计是一种艺术的说法，所谓艺术，必然会有一些美的东西在里面。无论是实现了一个精巧的算法，还是搭建出一个宏伟的架构，这些无不是体现程序设计之美的地方。想要体会程序设计之美，那就势必要两手抓，且争取两手都要硬。
《探索Antlr》是两年前写的一篇文章，如今，Antlr 3.0已经发布了，有了一些变化，为了反映这些变化，我决定重写这篇《探索Antlr》。
探索Antlr（Antlr 3.0更新版）
简介
Antlr（ANother Tool for Language
Recognition）是一个工具，它为我们构造自己的识别器（recognizers）、编译器（compiler）和转换器（translators）提供了一个基础。通过定义自己的语言规则，Antlr可以为我们生成相应的语言解析器，这样便可以省却了自己全手工打造的劳苦。
目标
如同程序设计语言入门大多采用“Hello
World”一样，编译领域的入门往往选择计算器。而这里迈出的第一步更为简单：一个只能计算两个数相加的计算器，也就是说，它可以计算“1+1”。
基础知识
先来考虑一下如何下手，如果你曾经接受过编译原理的教育，权当忆苦思甜了。这个计算器工作的前提是有一个需要计算的东西，不管我们是以文件的形式提供，还是手工输入，至少我们可以让我们的计算器知道“1+1”的存在。
有了输入之后，我们要先检查输入的正确性，只有对正确的输入进行计算才是有意义的。如同写文章有形式和内容之分，这里的检查也要细分一下，率先完成的检查当然是面子功夫——形式上的东西，看看是否有错别字的存在，我们要做的是数值相加，结果人家给出了一个字母，这肯定不是我们希望得到的，所以我们有权力拒绝这个不合法的东西。对于程序员来说，如果在自己的程序里写了一个语言不接受的标识符，比如在Java里用“123r”做标识符，那编译器肯定会罢工，拒绝让程序通过编译的。在编译原理里面，这个过程叫做词法分析。在我们的计算器中，我们只接受整数和加号，其它的一概不理。这里我们说的是“整数”，而非
“1”、“2”……，对我们来说，它们代表着同一类的东西，编译原理教导我们把这这种东西叫做token，那些数字对我们来说，都是一样的token，不同的仅仅是它们的值而已。
形式说得过去并不代表内容就可以接受，南北朝时期许多骈体文让我们看到了隐藏在华丽的外表下的空虚灵魂。你可以说
“我吃饭”，如果说“饭吃我”，除非是在练习反正话的场合，否则没有人会认为它是有意义的，因为显然这不是我们习惯的主谓宾结构。只有在闯过了词法分析的关口，才能到达这里，在编译原理里面，我们把这个阶段叫做语法分析。如果说词法分析阶段的输入是字符流的话，那么语法分析阶段的输入就是token流——词法分析的输出。我们这里接受的合法语法是“整数
加号 整数”。
编写语法文件
好了，制订好自己的语言规则之后，我们需要以Antlr的语言把它描述出来。下面便是以Antlr的语言描述的语法：
grammar Calculator;
expr: INT PLUS INT;
PLUS : '+' ;
INT : ('0'..'9')+ ;
Antlr的语法文件通常会保存在一个“.g”的文件中，我们的语法文件叫做“Caculator.g”。
我们来看看这里的定义：
expr: INT PLUS INT;
这条语句定义了expr，它等价于“:”右边的部分，也就是说，
* 一个INT，后面跟着一个PLUS，后面再接着一个INT。
至于INT和PLUS，它来自后面的定义：
PLUS : '+' ;
INT : ('0'..'9')+ ;
* PLUS定义的token，就是一个单一的“+”
*
INT定义的token，由从'0'到'9'之间任意的数字组成，后面的加号表示它是可以重复一次到多次
如果你曾经与Antlr 2.x有过一面之缘，你会发现，这个语法文件与Antlr
2.x的语法文件有着些许不同。首先，我们没有区分词法分析和语法分析，由上面的代码可以看出，二者在形式上是一致的，不同的是，对于词法分析的输入是字符，而语法分析的输入是词法分析的结果，也就是token。Antlr
2.x必须显式的区分这二者，而在Antlr
3.0之后，Antlr会替你料理这一切。再有，这里的语法文件名必须与grammar定义的名字保持一致，对于Java程序员，这是一个顺其自然的选择。
编译语法文件
如同不编译的程序是无法发挥其威力一样，单单语法文件对我们来说，并没有很大的价值。我们的工作就是使用Antlr提供工具对我们的语法文件进行编译，不同于日常的编译器输出可执行文件，这里的输出是程序语言的源文件。Antlr缺省目标语言是Java语言，它也可以支持C，C#和Python语言，其他的语言尚在开发之中，从3.0发布包结构来看，Ruby的支持很快就会加进来。
将Antlr提供的JAR文件加入到classpath中，其中包括Antlr 2.7.7，Antlr
3.0与其runtime，stringtemplate。你没看错，除了3.0，这里还包含着2.7.7。原因很简单，Antlr
3.0是基于之前版本开发的。
然后把语法文件的名称作为参数传给语法编译器：
java org.antlr.Tool Caculator.g
在确保命令正确执行，且语法文件编写正确的情况下，Antlr为我们生成了几个文件：
* CalculatorLexer.java
* CalculatorParser.java
* Calculator__.g
* Calculator.tokens
正如前面说过的，Antlr替我们料理好了词法分析和语法分析，其中，
CalculatorLexer.java就是我们的词法分析器，而CalculatorParser.java中包含了语法分析器，它们是我们这里关注的主要对象。至于另外两个文件，Calculator__.g是一个自动生成的lexer语法文件，而Calculator.tokens则是列出了我们定义的token，我们并不会在程序中和它们直接打交道，所以，让我们暂时忽略它们的存在。
运行程序
生成代码之后，就是如何使用这些生成的代码。下面就是我们的主程序，它负责将词法分析部分（Lexer）和语法分析部分（Parser）驱动起来：
public class Main {
public static void main(String[] args) throws
Exception {
ANTLRInputStream input =
new ANTLRInputStream(System.in);
CalculatorLexer lexer =
new CalculatorLexer(input);
CommonTokenStream tokens
= new CommonTokenStream(lexer);
CalculatorParser parser
= new CalculatorParser(tokens);
try {
parser.expr();
} catch
(RecognitionException e) {
System.err.println(e);
}
}
}
从这段代码中可以清晰的看出，Lexer的输入是一个字符流，而Parser则需要Lexer的协助来完成工作，用Lexer构造出的Token流作为其输入。一切就绪，我们让它跑起来，尝试输入一些内容，看它是否能够通过验证。事实证明，我们的程序可以轻松识别“1+1”，而对于不合法的东西，它会产生一些抱怨。
计算结果
还记得我们的目标吗？我们的目标是计算出“1+1”的结果，而现在这个程序刚刚能够识别出“1+1”，我们还要继续前进。
熟悉XML解析的朋友对于SAX和DOM一定不陌生，二者之间差别在于SAX属于边解析边处理，而DOM则是把所有的内容解析全部解析完（在内存中形成一棵树）之后，再统一处理。Antlr也有与之类似的两种处理方式，SAX的朋友是在Parser中加入处理动作（Action）处理将随着解析的过程进行，而DOM的伙伴则是解析形成一棵抽象语法树（Abstract
Syntax Tree，简称AST），再对树进行处理。
加入Action
先来看看SAX的朋友。因为处理动作是加在expr上，其它部分保持不变。下面是修改过的expr：
expr returns [int value=0]
: a = INT PLUS b =
INT
{
int aValue = Integer.parseInt($a.text);
int bValue = Integer.parseInt($b.text);
value = aValue + bValue;
}
;
看到常用的字符串转整数的方法，熟悉Java的朋友想必已经露出了会心的微笑。没错，这里定义Action的方法采用就是Java语言，因为我们生成的目标是Java，如果你期待另辟蹊径，那这里的代码就要用你的目标语言来编写。
仔细看一下不难发现，action完全是在原有的规则基础上改造的来。首先用returns定义了这个Action的返回值，它将返回value这个变量的值，其类型是int，我们还顺便定义这个变量的初始值——“0”。接下来，我们用a、b拿住了两个token的值，我们前面说过，在检查的过程中，我们并不关心每个token具体的内容，只要token的类型满足需要即可，但在action中，我们要计算结果，那必须使用token具体的内容，所以，我们用变量拿住了token。这里我们用$a.text获取这个token的具体值。剩下的动作就很简单了，把文本转换为数字，进行加法运算。
再给旧版本一些忆苦思甜的时间，Antlr 2.x写法有一些细微差别。首先，Antlr 2.x用“a :
INT”将一个Token赋给一个变量，而这里用的是“a = INT”。再有，我们用$a.text获取token的值，而在Antlr
2.x中，我们会用a.getText()，当然，在Antlr
3.0中，我们也可以这么写，不过，a.getText()这种写法显然太过于Java。
是不是对我们的计算器有些迫不及待了，那就挥动工具生成全新的Parser。不过，在新的体验之前，我们还要稍微修改一下主程序，以体现我们的劳动成果。
public class Main {
public static void main(String[] args) throws
Exception {
ANTLRInputStream input =
new ANTLRInputStream(System.in);
CalculatorLexer lexer =
new CalculatorLexer(input);
CommonTokenStream tokens
= new CommonTokenStream(lexer);
CalculatorParser parser
= new CalculatorParser(tokens);
try {
System.out.println(parser.expr());
} catch
(RecognitionException e) {
System.err.println(e);
}
}
}
好了，让这个计算器来为我们求证“1+1”吧！
AST
SAX的朋友表演完了，下面就是DOM的伙伴登场了。
建立AST的方式很简单，只要我们加上一个AST的选项即可，不过，同DOM的处理方式一样，前面的解析只是为了后面的处理做准备，所以，这里我们要修改一下之前编写的语法文件，下面就是我们的新语法文件：
grammar Calculator;
options {
output=AST;
ASTLabelType=CommonTree;
}
expr : INT PLUS^ INT;
PLUS : '+' ;
INT : ('0'..'9')+ ;
稍微有些不同的地方是，我们加上了两个选项，告诉Antlr，我们要输出的是一个普通的AST。再有，在PLUS上面的“^”，这个符号用来告诉Antlr创建一个节点，以此作为当前树的根节点。
你也许会有些疑问，怎么没看到计算的加法的地方？正如前面所说，这里只描述了语法结构，这是为了后面的处理在做准备，那么后面如何处理呢？别急，大戏要压轴。下面登场的是Antlr整个故事最后一个大角，TreeParser：
tree grammar CalculatorTreeParser;
options {
tokenVocab=Calculator;
ASTLabelType=CommonTree;
}
expr returns [int value]
: ^(PLUS a=INT b=INT)
{
int aValue =
Integer.parseInt($a.text);
int bValue =
Integer.parseInt($b.text);
value =
aValue + bValue;
}
;
Antlr
可以接受三种类型语法规范——Lexer、Parser和Tree-Parser。如果说Lexer处理的是字符流、Parser处理的是Token流，那么TreeParser处理的则是AST。前面Action的处理方式中，我们看到，规则同处理放到了一起，显得有些混乱，而采用了AST的处理方式，规则同处理就完全分离了：在Parser中定义规则，在TreeParser中定义处理，如果我们需要对同样的语法进行另外的处理，我们只要重新
TreeParser，而不必在规则与Action混合的世界中苦苦挣扎。
有了前面Action的基础，再来看TreeParser也就简单许多，需要说明的就是：
^(PLUS a=INT b=INT)
除去变量的说明，简化一下这段代码
^(PLUS INT INT)
第一个符号PLUS对应了表示着根节点，两个INT则分别代表了两棵子树，这样刚好与前面生成的语法树对应上。
再来看看重新打造的主程序：
public class Main {
public static void main(String[] args) throws
Exception {
ANTLRInputStream input =
new ANTLRInputStream(System.in);
CalculatorLexer lexer =
new CalculatorLexer(input);
CommonTokenStream tokens
= new CommonTokenStream(lexer);
CalculatorParser parser
= new CalculatorParser(tokens);
try {
CommonTree t = (CommonTree)parser.expr().getTree();
CommonTreeNodeStream nodes = new CommonTreeNodeStream(t);
CalculatorTreeParser walker = new
CalculatorTreeParser(nodes);
System.out.println(walker.expr());
} catch
(RecognitionException e) {
System.err.println(e);
}
}
}
结语
体验过最简单的Antlr程序，我们就有了让它更为丰富的基础，接下来便是自己动手的时间了。
参考资料
《ANTLR入门》 2004年第三期《程序员》
《ANTLR Reference Manual》
《The Definitive ANTLR Reference》
写程序的时候，经常遇到这样的代码。处理之前，先检验一下一些参数，之后再进行处理。下面是一段这样的Java程序。
public class Service {
public void approve() {
Target[] targets = getTargets();
if (targets.length == 0) {
reportNoTarget();
return;
}
actualApprove(targets);
}
public void reject() {
Target[] targets = getTargets();
if (targets.length == 0) {
reportNoTarget();
return;
}
actualReject(targets);
}
...
}
这段代码不够漂亮，这是显然的，因为其中存在重复代码，参数检验的部分是完全相同的，这两个函数的真正的差别只是在检验后的处理。但是在
Java中，想简单的解决这种重复并不是一件容易的事情。我脑子里想到的方案包括用异常和接口，不过，这两种方法都不够优雅，其主要原因还是因
为Java的函数并不容易操作。如果你有什么好的解决方案，不妨告诉我。
如果我们用的是C#，这段代码可以这样来写。
public class Service
{
private delegate void ActualOperationDelegate(Target[]
targets);
public void Approve()
{
OperateOnTarget(ActualApprove);
}
public virtual void RejectTrades()
{
OperateOnTarget(ActualReject);
}
private void OperateOnTarget(ActualOperationDelegate
operation)
{
Target[] targets = GetTargets();
if (targets.length == 0) {
ReportNoTarget();
return;
}
operation(trades);
}
...
}
这段C#代码用delegate轻松的解决了重复代码的问题。
如果用Ruby，我们可以让程序更为优雅。
class Service
def approve
operation_on_target { |targets| actual_approve
targets }
end
def reject
operation_on_target { |targets| actual_reject
targets }
end
def operation_on_target
targets = get_target
if (targets.length == 0)
report_no_target
end
yield targets
end
...
end
之前写过一篇关于程序设计语言表达的blog，这篇算是它的一个例子吧！
people.collect(&:name)
这段代码实际上等价于
people.collect { |p| p.name }
但是，从Ruby的语法上来看，这行代码看上去是很难理解的，主要就是&:name。把这行代码当作Ruby脚本直接运行，你会发现，Ruby会向你报错，错误是：
wrong argument type Symbol (expected Proc) (TypeError)
那么为什么这样的代码遍布于Rails，却能正常运行呢？
最初困扰人的可能主要是&:name的写法，这看上去根本不像正常的Ruby语法，但只要将它进行适当的分解，我们就豁然开朗了。在Ruby中，“&”通常用来表示后面跟的是Proc，而:name在Ruby中表示一个Symbol。把二者结合在一起，矛盾变产生了，”&”要的是一个Proc，而我们给的一个Symbol，这就是前面错误的来源。
知道了错误的来源，接下来的问题是，Rails里究竟变了怎样的魔术，让这段代码通过呢？
其实，“&”后面如果跟的不是一个Proc，那么它会试图找寻一个Proc，在Ruby中，这意味着它会调用to_proc方法。这是Ruby中的一种标准协议，关于这种转换协议，可以参考《Programming Ruby》中《Duck Typing》一章相关的介绍。
由于后面的是一个Symbol，结合前面的说法，只要为Symbol类提供一个to_proc方法，至少在语言层面上，就会变得正确起来。事实上，Rails正是这样做的。
class Symbol
def to_proc
Proc.new { |*args| args.shift.__send__(self, *args) }
end
end
(activesupport/lib/active_support/core_ext/symbol.rb)
如果说to_proc仅仅是让这个魔术在语言层面上通过，那么上面这段代码也解开了其余部分的神秘面纱。不妨再进一步，看看它究竟是如何做到的。
通过开始的代码等价对比，我们已经知道了这行的代码意义，主要也就是调用了一个对象的方法。将它对应到Proc.new所附带的block上，我们便不难看出这段代码的意义所在了。
这里的*args是block的参数，在前面的例子中，p就是这个参数，我们要调用p的name方法，所以，p是作为receiver的，而args.shift正是将p提取了出来。通过__send__，我们就可以调用receiver的方法，而__send__需要一个Symbol指定要调用的方法，别忘了，我们正是在一个Symbol类中定义方法，于是self成为了一个自然的选择。至于剩余的参数（对*args调用shift之后），就作为参数传给方法了。实际上，大多数用法中，只有一个参数，所以，剩余的部分会是一个空数组。
通过这种变换，p.name就等价于args.shift.__send__(self, *args)了。
关于这段代码的实现，也许Ruby Extensions的实现更加清楚一些。
def to_proc
proc {|obj, *args| obj.send(self, *args) }
end
这段代码将receiver分拆出来，所以，更加容易理解。当然，严格的说，二者还是稍有差别，这种实现必须要有一个参数。但是，在大多数情况下，这种实现已经足够了。
有好长一段时间，这个列表没再更新过，中间虽然我也读了很多书，也学到了很多东西，但却没有哪本书如这几本书一样给我带来巨大触动。新近加入我这个列表的书是《修改代码的艺术》，英文名是《Working Effectively with Legacy Code》。
对于很多软件开发人员来说，加入一个公司，通常意味要面对一大堆之前留下的代码。而面对沉重的负担，大多数人的感觉都是无可奈何。让无奈成为往事，也就是这本书的价值所在。
在我看来，这是一本讲解如何编写测试的书。之所以遗留代码让人头痛，除了复杂的逻辑，改动会带来怎样的后果是一件让人心里没底的事，而测试的存在可以大幅度降低这种恐惧。但是，许多代码在开发时并不考虑测试，这样做的结果就是让测试几乎成为一件不可能完成的任务，一个常见的例子就是代码中访问数据库。即便写出测试代码，漫长的测试过程也会让它失去一部分应有的作用，我们希望得到的是快速的反馈。所以，对于
无测试而言，知道编写测试是一种境界的提升，写好单元测试则是一种更高的境界。如果能够让测试驱动开发，从开发之初便考虑测试，并懂得如何写好测试，开发者应该不会陷自己于一种难为的境地，这也应该成为专业程序员应该具备的基本技能。
至于这本书的具体内容，我的评价是实用。具体的手法，很难在这里一一列举，但是，以我的开发经验来看，
许多似曾相识的代码不断的出现在书中，而作者举重若轻的处理手法，正是让我有拍案惊奇的地方。实际上，回味起来，每个手法都不是什么很高超的技法，但正是因为见识过类似的代码，才能体会到这种手法的价值所在。所以，相对于程序新人，它更适合有经验的人。
之所以说这本书更适合有经验的人还因为，这本书中谈及的内容涵盖设计、测试、重构等诸多方面：通过重构，解开代码内的耦合，让其可测。这恰恰是前面提到的那三本书所讲的内容。也只有懂得了这些基本内容才能体会到那些具体手法的价值所在。依然记得当年读《重构》时，在提取和内联之间迷茫了好久，直到后来经过了许多开发实践才体会到这些做法的真正含义。
如果说不足，那么，这本书缺乏一个列表，就像Martin Fowler为《重构》所做的那样，出什么样的问题，应该采用怎样的手法进行处理。
关于中译本，总的来说，翻译得很流畅，读起来比较舒服。不过，制作上还是有一些不太让人满意的地方。
* 译注太多，而且有些是低估读者智商的译注。
* 页边标有页码，似乎是为了与英文版对照，但文中的参考页码又是以中文版为准，显得有些乱。
* 书的装订不是特别令人满意，我一直担心从中间断开。
在InfoQ China发了一篇介绍XRuby的文章。其实，对于之前听过我介绍XRuby的人来说，这篇文章的内容并不新鲜，因为基本上，这篇文章的内容脱胎于之前介绍XRuby的讲稿。虽然讲了几次，但还是应该把这篇文章写出来。一来，到场听介绍的人毕竟是少数，写出来看到的人应该可以更多，也让更多的人有机会了解XRuby，再有，内容写成文章需要比演讲时有更多的思考。所以，整体来说，内容叙述应该会更加准确。
这是一篇早就该写的文章，至少最初答应霍泰稳写这篇文章还是5月份的时候，7月份录我 InfoQ访问的时候，又答应了Floyd完成这篇文章，可真正发布已经是十月份了。不过，这样一拖再拖也不是完全价值。在这段时间里，我在Agile Day讲了一次Ruby on JVM，让我对这个方面有了些新的思考，特别是把Ruby放在 JVM上的价值，这一点已经体现在这篇文章里了。另外，XRuby自身在这段时间中也发生了很大的变化，特别是Annotation的加入，让代码在表现形式上得到很大的进步。至少在我看来，最终体现在文章中的示例代码是可以接受的。
我希望，这篇文章可以成为一个起点。一方面，它可以作为让更多人了解XRuby的起点；另一方面，XRuby团队把它作为一个起点，向其它人展示XRuby中非常优秀的一面。当然，XRuby现在已经有了不少不错的文档。
已经有朋友给我建议，写一些更深入的东西，这也是我所希望的，只探讨一些比较浅的东西不过瘾。在XRuby开发过程中，有很多有趣的思考，我很愿意与人分享那种开发中的快乐。再有，写东西会促使人思考，随之而来的往往是发现不足，这也是有益于XRuby进一步改进的。
如果你希望了解或参与XRuby，不妨告诉我们，你希望了解什么，也许，我们之后的文章会满足你！