最近一年，我做了一些咨询工作，对于语言的认识又有了些新的看法，对于传统型的大团队，静态语言或许是个更好的选择。因为在这样的团队里面，成员的整体素质不是很高，开发习惯也不是特别好，动态语言对他们来说，实在有些勉为其难。我就是在这种情况下开始关注Scala的。

除了与Java互操作和静态类型之外，Scala实际上还给我们提供了更多，尤其是函数式编程。随着多核时代的到来，函数式编程已经越来越多的关注。而我们也越来越多从函数式编程中发掘出一些广泛适用的编程法则，比如，编写无状态函数。Scala尝试着把面向对象和函数式编程整合起来，这是两种风格的整合，也是一种有益的尝试。对于普通开发人员而言，即便忽略函数式编程，仅仅把它视为简化代码一种方式也是好的。

断断续续的了解了Scala，我一直想相对全面的认识一下Scala，除了做项目，翻译也是个不错的选择。当年学习Ruby时，就是通过翻译《Ruby Hacking Guide》了解Ruby的运行机理。想了一下，今年还没有好好学哪门语言，就把Scala当作我今年要系统学习的语言吧！

我并没有太多的翻译经验，只是玩票一般参加过《ThoughtWorks文集》的翻译。好在还有小刀，作为InfoQ中文站的编辑和几本书的译者，他的翻译经验堪称丰富。有他和背后的编辑，我的英语应该不会造成太大障碍。

开了个Scala的头，今后，可以多一些关于Scala的讨论。

• 一眼就能看明白，不值得测
• 单元测试粒度太细
• 单元测试要写好多，耽误工作量
• 单元测试不稳定
• 人员能力有限，写不好单元测试

正是因为这样的原因，在他们看来，系统测试也许是一个更好的选择。我不否认系统测试的重要性，但是，单元测试才是他们最应该做好的。

程序员和程序员之间的差异很大程度上是由开发习惯决定的。Kent Beck曾自我评价，“我不是什么伟大的程序员，我只是一个有着很多好习惯的程序员”。单元测试就是一个好习惯。它等于要开发人员在编码的时候就要验证代码的正确性，而不是向后拖。软件开发最基本的一条规律是，越往后做，代价越大。正确性总要验证，那当然是越早验证越好。

如果你做过单元测试，你就会发现，一旦开始考虑验证，很多之前不曾考虑过的问题就会浮出水面，比如，一些边界条件。单元测试给了我们一个更仔细的关注质量的机会。虽然我们不能说经过单元测试的代码就是100%的完美，但是，我们至少给出了力所能及的验证。而事实上，一旦到更高层面的验证，比如系统测试，比如测试人员的测试，这些所谓的细枝末节是很难覆盖到的。而这些地方又恰恰是很多开发人员认为简单的，不值得测的地方。一旦遗漏，就会成为产品的缺陷，随时可能爆发。

有人曾给过我们这样一个数据，他们的产品中有15%的bug源自像变量赋值这样非常简单的错误。从这个数据可以看出，很多人还做好自以为很简单的事。程序员有自信是好事，但前提是要有自信的本事。单元测试给了开发人员一个一步一个脚印，踏踏实实走路的机会。当每个构造快都经过验证的之后，把它们组合在一起，我们只要验证他们之间组合就好了。这样的做法，每一步心里都是有底的。而现在的很多开发给人的感觉是在撞大运。

时至今日，还有很多程序员把开发完成理解成“编码完成”。行百里者半九十，这句话就是给这样的程序员预备的。他们以为自己代码写到90%的时候，其实，后面还有一大半的验证工作等着他们。这些程序员只不过在用有另外一个名字——比如集成——的时间去做他们份内的工作，而某些愚笨的老板居然认为这是天经地义的，所以，他们会压缩编码时间，给后面的验证留下更长的时间，于是，开发人员的时间更紧张了，他们更倾向于前期少验证，一个恶性循环就此形成。

对于很多人来说，单元测试有问题，但实际上，真正有问题的是代码。为什么测试不好做，因为代码的耦合太大了。为什么单元测试不稳定，因为设计不稳定。谈到这里，我得承认一点，想把这一切都做好，人是关键。不是所有人都能拆解好代码的，但这里真正的问题是，不是所有人都有意识去拆解代码的，那些代码里面的垃圾就是从这里产生的。很多自以为是建设者的人，实际上，是添乱的。

或许你会说，有很多高手都认为单元测试不是必要的，确实如此，但你光看见贼吃肉了，那些高手个人能力超强，基础扎实，思维缜密，先跟人家比这些东西吧！对于软件开发人员来说，单元测试就是基本功，通过它，可以让人在很多方面得到很多锻炼。先把基本功打扎实再琢磨别的吧！

• Away Day是放松，我们可以逃离办公室
• Away Day是学习，有各种各样的session等着大家
• Away Day是聚会，外国同事千里甚至万里迢迢来参加，出差在外的同事也会回来
• Away Day是交流，不同人不同思想在一起碰撞
• Away Day是……

遗憾的是，去年因为经济的原因，Away Day取消了，一年之后，当Away Day再次有机会重现江湖的时候，我充满了期待。不同于两年前在办公室里“Away”，这次我们真正意义上的Away。

Away Day中一个重要的安排当然是一大堆的session，这是一个非常好的学习机会。我的immersion同学Ola Bini这次来到中国，参加Away Day，他的session是关于下一代JVM，也就是JDK 7的一些发展和变化。对于经常关注业界新闻的人来说，语言层面上的东西没有太多新鲜的内容，倒是Ola对低层实现方面的一些讨论，让人可以更系统的了解JVM的发展。徐X一个关于Scala的session居然听不出和Scala有什么关系，实在是有些过份。徐X借着这次机会，表达了一些他对几种程序设计语言的喜爱，比如Smalltalk，Haskell等等。倒是结束之后，我和我们CTO麦罗聊了一会Scala，我建议他弄个Scala的项目，让大家感受一下。

这次个人感觉收获最大的一个sesion来自我们的老大郭晓，他的主题是关于认知偏见的。我开玩笑的把这个session总结为，如何防止被忽悠以及忽悠别人。自从开始成为咨询师，我就开始对心理学感兴趣，这个session中所讲的东西，我可以很好的映射到我的咨询工作之中，所以，内心会产生出极大的共鸣。事实证明，这不是个别现像，我们后来玩杀人游戏的时候，这些内容左一次右一次的出现在我们面前，于是，杀人游戏又变成了这个session的延续。

好久没有见到我们创始人Roy了，不过，一般情况下，Away Day他都会出现的，这次也不例外。更大的惊喜是，他的老母亲也出现在北京。我们几个同事在交流咨询经验的时候，Roy走了过来，加入了我们。我们把自己之前的一些工作告诉给他，饶有兴致的听完我们的介绍，他认为我们的工作很有趣，建议我们写一本书，把这些经验介绍出来，同时，也建议我们写一个介绍，发给其它办公室的ThoughtWorker，让有兴趣的人也加入到中国这边的咨询工作中来。

Away Day的狂欢出现在我们盛大的Party。这些平时已经很能出彩的家伙还是能玩出更多花样。恶搞了很多人“专业”视频；一群新ThoughtWorker表演《唐伯虎点秋香》；把最喜闻乐见的pair拿出来展现反模式；让Sponsor和Sponsee体验默契；用十分钟创作一个小节目……

Away Day总是让人快乐的！

• 有一个很大的项目，负责与客户接口的有三个人，大多数需求都是从一个人那里进来的，因为这个人是最好说话的。结果是，本来可以顺畅运行的项目，由于需求的暴增，导致不得不加班，一个原本运转正常的项目，怨声载道。
• 一个计划20个点的迭代，迭代结束后，待开发的点居然超过30个。这些需求都是从这个项目负责人那里直接走到待开发的状态，因为每个提需求的人告诉项目负责人的都是这个需求是很重要、很紧急的。结果是，项目组的进度并没有因需求的增加而加快，反而士气受到了打击。
• 有一个人很好的PM，总是把满足客户需求看作很重要的事，所以，他倾向于接受客户的所有要求。结果是，组内其他有经验的人据理力争，顶住了PM接受客户需求的倾向，项目组一直顺利运转。

这些都是真真切切发生在我的身边，或是我亲历，或是对周边项目的所见所闻。

客户是上帝，让客户高兴很重要。但让客户高兴，并不等于一味的接受客户所有的要求。事实上，你真的这么做了，客户不会领你的情。他会认为你接受他的要求是一件天经地义的事，所以，他会变本加厉的提出更多的东西。一旦成了客户眼中的软柿子，他就会不断的“欺负”。在第一个例子里面，其他两个人不那么好说话，于是，第三个人成了突破口。人都愿意做容易的事，所以，捏软柿子也就再正常不过了。

或许很多人并不承认自己是“软柿子”，但当他们听到“紧急”、“重要”、“有价值”这样的词汇时，他们便迷失了方向，就像第二个例子里面那个负责人一样。但是客户为了强调重要性时，他肯定会这么说。只有剥离这些形容词，才能淘尽黄沙始见金。

团队中的“软柿子”真正伤害的是团队。一般能够和客户打交道的，在团队中都会扮演比较重要的角色。因为他是团队和客户的接口，他在团队内部受到的置疑相对会少一些，所以，他一旦接受客户的要求，多半就意味团队接受了客户的要求。像上面最后一个例子中那样的情况，其实并不多见，这需要团队中有经验更丰富的人。

如果你所在团队有个“软柿子”，你的生活肯定不好受。

改进持续集成

要敏捷，要做持续集成。于是，有人想，如果能够把一些常见的操作（比如编译）替大家做好，省去了每个项目组配置的工作量，那该多好啊！于是，投人投时间，就着CruiseControl改出来一个新版本。

事实是，得到了一个看上去很美的可配置环境，而很多使用这个环境的项目组压根没有一键式脚本，直接把代码提交到进去，交给服务器来处理，顺便说一下，这个持续集成环境几个小时才运行一次，也就是说，写一行代码，也许几个小时以后才知道是不是能够编译通过。持续集成完全起不到应有的作用。

其实，只要把一键式脚本写好，配置持续集成很简单。

编写自动化测试工具

自动化测试很重要。于是，有人想，应该有一个自动化测试工具用来编写自动化测试。于是，投人投时间，编写了一个强大的自动化工具，甚至拥有一个漂亮的IDE。

事实是，这个工具运行起来，基本上需要占据2G内存，而很多开发人员开发人员的机器只有512M内存；编写测试的语言算是一种DSL，很特定于领域，没有人知道怎么用好它；这个为编写测试而生的工具，居然没有常规的Assert，没有setUp和tearDown；开发人员很少愿意用这个工具。

其实，如果用脚本语言封装一下，很多现成的工具和框架都很可以使用。

打造开发框架

重用很重要。于是，有人想，应该构建一个统一的平台，让所有团队采用同样的机制去编写代码，减少开发和维护的工作量。于是，投人投时间，做出了一个开发框架，号称开发团队只要编写少量的代码就可以完成功能。

事实是，一些很适合用B/S结构的应用因为这个框架变成了C/S结构；这个框架采用二进制的格式作为通信协议，让通信过程变得神秘无比；放着许多现成稳定的服务端应用不用，自己编写了一个。

其实，就Web应用而言，太多现成的东西可用了。

• 市场部门只是扔给开发团队一大堆需求和一个不切实际的deadline，不改变，敏捷也没辙。
• 进度压力大，团队成员没有时间和精力去学习和思考，不改变，敏捷也没辙。
• 只关注业务，忽略软件开发技能，不改变，敏捷也没辙。
• 只关注显式成本（比如硬件投入），忽视隐式成本（比如漫长的编译时间），不改变，敏捷也没辙。
• 只给开发团队压活，不给开发团队解忧，不改变，敏捷也没辙。
• ……

你看到了，前面我用了很多“变”。想真正敏捷起来，就要面临改变。

许多团队团队并没有意识到敏捷到底意味着什么，他们指望一成不变，添加几个敏捷实践，就把所有问题都解决了。越是积淀深厚的团队，这几乎就越是一件不可能的事情。

采用一些敏捷实践，也许会让某些团队有一些进步，但我也了解过不少“敏捷”团队，因“敏捷”而痛苦万分，唯一让他们欣慰的是，抛弃了繁重的文档。目前关于敏捷，很多人看到都只是鼓舞人心的一面，也许敏捷的“烟斗”才是最真实的一面。

如果你认为你的团队一切正常，如果你没有准备好承受敏捷带来的改变，别急着敏捷！

• antlr，ANTLR的语法文件
• noop，用noop实现的标准库
• scala，Noop语言的实现

再来看看语言实现，scala/noop目录有几个包：

• grammer，调用ANTLR生成的类实现的解析器
• interpreter，实现了一个基本的解析器
• model，语言的基本模型
• types，一些基本类型，可以理解为Noop的运行时。

从现有的目录和代码，我们可以看到Noop还是非常简单的，它甚至不包含生成JVM字节码的部份，而且类型也是最基本的几个。

最后，让我们实际运行一段Noop程序，在此之前，你需要安装Mercurial（也就是hg）和Buildr，对于Ubuntu而言：
    sudo apt-get install hg
    sudo env JAVA_HOME=$JAVA_HOME gem install buildr

获得Noop的代码
    hg clone https://noop.googlecode.com/hg/ noop

clone成功之后，进入到noop目录，构建整个noop
    buildr

如果是第一次运行，可能它会用一段时间下载所需JAR文件，然后，才会执行编译，运行测试等任务。

打包的命令是这样的：
    buildr package

有了生成的JAR包，我们可以运行Noop程序了，这里我们用了Noop提供了一个HelloWorld的例子程序，它位于examples/noop/helloworld/HelloWorld.noop。
    java -jar target/noop-0.1.0-SNAPSHOT.jar HelloWorld examples/noop/helloworld src/main/noop/stdlib

还是那句话，Noop实在太新了，包括目前的命令行都是那么粗糙，它甚至不能加载自己的标准库，需要指定对应的路径。

Ｎoop刚刚起步，对于希望了解语言实现的人，它可以当作一个起步的阶梯。