周末没得闲，因为参加了一次CodeJam。

CodeJam，是公司组织的一个编程活动，就是要在周末两天时间内开发出一个东西，据说此类的活动在其他的办公室举办过。这是我第一次参加类似的活动，参加这次活动的Dev都是公司内比较优秀的程序员，平时很难把这些人都放到一个团队里面，有机会和这些人在一起工作，本身就是一件令人期待的事。

这次活动的目标是为一个支援乡村教育的组织开发一个分享平台。在活动开始之前，我们对需求一无所知，所以，几乎就是看两天内能够写出多少东西。因为这个项目要开发的是一个Web应用，从生产率的角度来看，我们当仁不让的选择了Rails作为开发工具，这也是我最近在学习Rails的原因之一。

万事开头难，这次CodeJam也不例外。在一群Dev准备甩开膀子大干一场的时候，我们发现了一个问题，没有需求。需求，是冰云（BA）和QQ（QA）在之前一天和我们的客户谈好的。QQ在离开办公室之前，把从需求整理出的Story卡片锁到了自己的抽屉里，结果，第二天，她闹肚子了。好在冰云临危不惧，顶着我们的巨大压力，把部分Story重写了出来。直到QQ重新归队，打开宝箱，需求问题才得到了彻底的解决。

正式开工，场面那是相当壮观。一群ThoughtWorker，一群快手，一帮人抢着提交代码。做用户登录部分的高喊着，他们应该是第一个提交数据库表的，结果，更新代码时，已经有了数据库版本已经到了3。那是我和WPC干的，因为我们俩负责搭建开发环境，所以，先下手为强了。不过，我们高兴得有些过，用scaffold生成的代码出现了一个拼写错误。这时我们才发现，修改这些生成代码是多么痛苦的一件事。

在这里，我们用的典型的ThoughtWorks工作方式，一对Pair，拿到一张Story卡，然后，小步前进：测试、编码、重构、提交。正是因为步幅很小，所以，就出现了大家争抢着提交代码，因为稍微慢一点，就会更新下来一片代码，这种时候，便要重新运行测试。运气不好的话，破坏了别人的测试，还要帮别人修复。其实，在一个大的开发团队中，这种现象很常见，尤其是测试多到不能很快运行完，比如有集成测试的时候，常常是运行测试之后，又来了新代码。

典型的ThoughtWorks工作方式，还有另外一个含义。一群人一边写着代码，一边互相开着玩笑。在我的印象中，ThoughtWorks开发团队从来就不缺少笑声。其实，这次参加CodeJam的人，有很多我并没有直接在一起工作过，所以，这也是一个很好的了解大家的机会。比如，在我的印象中，WPC一直是闷着头写代码的家伙，和他Pair才知道，他原来也是那么有才，可以让人笑得肚子疼。至于像徐X和gigix这种平日里就给大家很多欢乐的家伙（也许也包括我自己）就更不用说了。当然，也有比较安静的，亮亮和来自加拿大的Ricky被我评为“最安静的Pair“。

两天下来，从无到有，一个具备基本功能的网站就建立了起来。showcase的时候，看着这个小网站，心里还是很有一丝满足的。对我而言，这是我第一次做Rails项目，第一次尝试用TextMate去开发。

这次CodeJam，是在公司内部进行的，希望将来有机会把这个面扩大一些，让其他公司的人来和我们一起来做，一方面我们可以从其他人身上学习到一些东西，另一方面，也让别人了解一下ThoughtWorks是如何工作的。我相信在如何进行软件开发这个问题上，ThoughtWorks做得足够好。

UPDATE
其他的ThoughtWorker也有对这次活动发表了自己的看法。
冰云：Beijing Code Jam - 2 days agile development project
Ricky：CodeJam@Thoughtworks Beijing

是的，我在学习Rails。

我所了解到的，大多数人是因为Rails而学习Ruby，像我这种了解Ruby却对Rails一窍不通似乎是异类。道理上来说，传统的途径应该是先学语言，再去了解相关的开发框架，像Rails这样喧宾夺主的情况，也算是异类了。当然，也正是因为Rails的喧宾夺主，才让人们有了更多的机会认识Ruby，了解Ruby的优雅。

趁着我还不那么了解Rails，把Rails留给我的初印象记录在这里，算是一个初学的记录。

Convention over Configuration（CoC），这是Rails广告给我留下的最深印象。这是一种改变业界对软件开发认知的思想。如同Spring让我们认识了Dependency Injection（DI），进而改变了我们的设计方法。Rails让我们认识到，原来有时候程序设计并不需要那么灵活。一片惊呼之后，效仿者蜂拥而至，人们纷纷尝试把这个想法带到自己熟悉的平台，其场面与Spring当年带来的DI容器热如出一辙。

如果Spring只有DI，它并不会带来真正的变革，同样，Rails也不是只有CoC。在我看来，CoC之外，Rails还集成了Web开发的实践。

Web开发实践有哪些？首当其冲的自然是MVC的架构，所以，在Rails中，明明白白的在目录结构上就把MVC分得清清楚楚。不过，我们还是抛开MVC这种路人皆知的答案，看一些具体的东西吧！

用Java写Web方面的应用时，我最担心的问题是如果一不小心上了某个框架的贼船，比如Servlet，结果就是为了看到自己程序能够正确运行，不得不把应用部署到服务器上。一旦出现了问题，解决问题就变成了一个非常低效的过程，因为我们不得不一次又一次的进行部署，大好的年华便随风而逝了。所以，对我而言，做Java应用的设计时，一个指导性原则就是尽量不依赖于任何框架，这样，就可以把真正的逻辑剥离出来进行测试了。初涉Rails，我也有类似的疑问。但我发现，原来Rails框架本身已经替你考虑好这个问题，它把测试的考虑也内建到框架之中，这样便可以很容易的针对每个Controller编写测试，而又不必理会部署的消耗。

Rails在测试方面有很多的考虑，它清楚的分出为Model而写单元的测试，为Controller而写的功能测试和跨越Controller的集成测试，而Fixture这个概念的存在，让我们很好解决测试数据的问题。这一切实际上都是一些优秀的软件开发实践。实际上，像这样的实践，Rails开发框架中还有很多，比如，如何处理页面布局、如何使用Ajax、如何管理数据库的迁移、如何让自己的应用Restful等等。使用Rails，不经意间，我们便可以走上一条正确的路。同许多开发实践一样，单独来看，这些做法本身并看不出多大的价值，但放到整个软件开发过程之中，便可以极大的提高开发生产率，尤其是在后期维护阶段。

不同于之前用过的一些框架，需要在实践中摸索正确的用法，Rails是第一个让我强烈的感受到开发实践内建其中的框架。只要走在Rails的道路（Rails Way）上，那么无论如何都不会偏离正确的方向太远。正确的道路何在？不得不提起《Agile Web Develpment with Rails》（中文版《Web敏捷开发之道》）。技术，常常是养在深闺无人识。其实，这个世界上一点都不缺好的想法，好的做法。我们经常会看到一些新东西让我们感慨，原来还可以这么做，但是，大多数时候，我们并不知道这些东西的存在。这本书的出现，恰到好处的向人们展示了Rails的优秀，比如前面提到的那些实践。不同于很多板着面孔教育人的计算机书，这本书轻松愉快的把一个完整的开发过程展现在人们面前。大多数人几乎是同时认识这本书和Rails框架的，所以，几乎一开始，Rails一族便走在正确的道路上。

不过，Rails还很年轻。年轻的结果就是不稳定。《Agile Web Develpment with Rails》第一版和第二版之间号称有70%的变动，而Rails 2.0又让第二版中的程序遭遇起步停车，一开始便会有差异。有些时候，这会打击初学者的积极性，也会让希望采用Rails的企业望而却步。

这便是我对Rails的初印象。

不知道算是幸运，还是不幸，我参与的多数项目，如果不是从头开始，我也是最开始加入的几个人之一，所以，我通常对项目的来龙去脉都比较清楚。这次，我有机会尝试一下在一头雾水的情况下开始一个项目。

这个项目已经进行了超过一个月，因为客户需要在赶在最近的一次发布之前，增加一些功能。老板按照目前的进度估算了一下，如果不加人，这个任务很难完成，于是客户很合作的同意增加两个人。就这样，我成了临时工。事实上，在这个阶段进入，项目早就过了最初的阶段，远远望去，没有几百也有几十的程序文件屹立在那里。虽然有最熟悉项目的人为我们介绍了项目的背景和架构，但这些宏观层面上的东西，对于编写代码这样“微观”的操作而言，几乎是没有任何直接的帮助。作为一个新人加入到项目，除了发呆，我还能做什么呢？

回想在以前公司的情形，大多数新进项目的人多半是得到一大堆文档，然后，有人语重心长的说，先把文档看了吧！且不说这些文档这种东西几乎写出来就过时，单单读完这些文档就需要花费很多时间。运气好的话，还有代码可以对应，但千万不要指望你能够一下子读懂这些代码。也许，你会想找别人来问，如果不出意外，大多数人都会不明就里的非常忙，忙到有时间上网聊天却没有时间给你讲这些东西。事实上，很多人即便自己做了很多东西，也不一定能够清晰的描述出来，所以，即便找到一个“闲”人，成功从他那弄明白这些东西的概率也很低。其结果是，我们经常会看到一些人在那对着电脑上的文档发呆。

在ThoughtWorks，我也恨不得找到一堆这样的无聊文档来打发时间，以此来享受偷懒的时光。遗憾的是，完全没有这种机会。因为那些“文档”会被视为浪费，这在以消除浪费为己任的敏捷来看，是无论如何不能接受的。于是，我在找不到任何借口的情况下，进入项目的第一天，就开始写程序了。不了解项目，怎么写程序？这是个问题。

敏捷实践中，有一个叫做Pair Programming的，从字面上来看，就是两个人一起开发。对于ThoughtWorker们来说，Pair是一种常态。所以，我在开发时也会有一个Pair，虽然我对项目一头雾水，但我的Pair已经在这个项目上工作了很长一段时间，所以，他很清楚这个项目的一切，差不多一切，因为代码是集体所有，所以，他在开发过程中会接触到各个部分。

拿到我们要做的Story，我的Pair会结合这个Story给我介绍上下文，并结合代码大致描述一下我们要做的事情。虽然在这个项目上我是新手，但我并不是对编程一无所知。有了这些基本的信息，我至少对我们要做什么，以及如何来做，在心里已经形成了一个大致的印象。刚开始时，基本上是我的Pair在主导开发，一边做一边告诉我，我们已经走到了哪里。渐渐的，我已经对我们在做的代码有了一些认识，开发也开始由一个人主导转向两个人讨论。随着开发的深入，我也发现了现有做法的一些不足，于是，我提出对代码进行重构，并给出了自己的分析和建议。我的Pair在听了之后，认为这是一个可行的建议，于是，我们毫不留情的将那段大家看着不舒服的代码改掉，这段代码从此清净了。

这就是在加入项目前几天所做的事情，虽然我目前还不能对整个项目有个很好的把握，但是，我相信，我已经开始在这个项目中起作用了。我想，Pair Programming是主要原因。正如前面所说，虽然我对项目很无知，但我的Pair很好的弥补了我的不足。正是两个人的协调工作，让我可以在对项目没有完整认识的情况下，可以很快入门，以最快的速度融入到开发之中。

曾几何时，我对Pair Programming的认识还停留在大家一起写程序和知识分享上，原来它对半路出家的人帮助也很大。虽然《人月神话》教导我们说，加人起不了很大的作用，但Pair的方式至少可以在相当大的程度上发挥新人的价值，削弱加人带来的负面影响。

使用Java实现内部领域特定语言
One Lair and Twenty Ruby DSLs
Implementing an Internal DSL

上面几个文章都是关于DSL的，不过，在这里，我并不是太关心DSL的话题，我更感兴趣的是代码的写法。按照这几篇的分类方法，直接用程序设计语言编写的DSL算是内部DSL，也就是说，所谓内部DSL，也就是一种标准的程序代码。

Kent Beck在他的《Implementation Patterns》的第三章《A Theory Of Programming》中，谈到了编程的价值观（Value）：Communication（沟通）、Simplicity（简单）和Flexibility（灵活）。如果说简单和灵活很容易理解的话，那么把沟通放在价值观中，尤其排在所有价值观的第一位，则显现出Kent Beck对于编程的深刻。在这个软件开发越来越需要协作的年代，写代码的时候，多站在让别人理解的角度考虑一下，会极大提升代码的可读性。在ThoughtWorks的招聘流程中，有一个Code Review的环节，拜这个环节所赐，我看过很多人的代码，不在少数的应聘者其代码唯一的优点就是完成了需求。以沟通为标准进行衡量，这显然是不够的。

同样，以沟通为标准，那么内部DSL显然在这方面做得更好，因为DSL本身就是为了让人更容易理解而存在的。这几篇文章中提供了很多内部DSL的手法，比如Method Chaining、Expression Builder等等。抛开DSL这样的BuzzWord，这些方法应该属于增强程序本身表达能力的方法。

JDK有一个很好的Method Chaining的例子：StringBuffer的append方法。

StringBuffer sb = new StringBuffer();
sb.append("log1").append("log2").append("log3");

这样的写法显然比下面的写法更为简洁，尤其是需要往StringBuffer中添加很多内容的时候。

StringBuffer sb = new StringBuffer();
sb.append("log1");
sb.append("log2");
sb.append("log3");

在我看来，这些内部DSL技术为我们打开了一扇窗，它让我们在编写代码，尤其作为API提供的代码时，有了一个新的思考方向。当然，并不是一味的应用这些内部DSL技术就会写出好代码，作为一个有经验的软件开发人员，我们需要一定的鉴别能力，分辨出究竟怎样做才会真正的提高代码的“沟通”能力。

之前写过两篇关于程序设计语言表达的blog（1、2），虽然这篇不像那两篇一样讨论语言的差异，但也算是在语言表达能力上的探讨吧！

Weka，是一个用Java编写的数据挖掘软件。数据挖掘，从字面上来看，它是一个从数据中找寻有用信息的过程，不过，它涉及的内容很多，所以，这里借用“分类”这一面来说事。

分类，从名称上来看，再简单不过了，给你一样东西，给它分个类。你如何知道怎么分类呢？显然，这是基于你已有的经验。对于计算机而言，这种经验从何而来呢？只有让人来告诉它，也就是说，我们要拿一批数据训练计算机，经过训练的计算机，便具备了一定的识别能力，就可以完成一些简单的分类工作。现实中，可以用到分类的机会有很多，比如我之前，曾经参与过的一个项目就是用这种方法来做车辆的识别。

下面便是一段使用Weka完成一段分类程序。

import weka.classifiers.Classifier;
import weka.classifiers.bayes.NaiveBayesMultinomial;
import weka.core.Attribute;
import weka.core.FastVector;
import weka.core.Instance;
import weka.core.Instances;
import weka.filters.Filter;
import weka.filters.unsupervised.attribute.StringToWordVector;

public class Main {
  private static final String GOOD = "G";
  private static final String BAD = "B";
    
  private static final String CATEGORY = "category";
  private static final String TEXT = "text";
    
  private static final int INIT_CAPACITY = 100;
    
  private static final String[][] TRAINING_DATA = {
    {"Good", GOOD},
    {"Wonderful", GOOD},
    {"Cool", GOOD},
    {"Bad", BAD},
    {"Disaster", BAD},
    {"Terrible", BAD}
  };
    
  private static final String TEST_DATA = "Good";
    
  private static Filter filter = new StringToWordVector();
  private static Classifier classifier = new NaiveBayesMultinomial();
    
  public static void main(String[] args) throws Exception {
    FastVector categories = new FastVector();
    categories.addElement(GOOD);
    categories.addElement(BAD);

    FastVector attributes = new FastVector();
    attributes.addElement(new Attribute(TEXT, (FastVector)null));
    attributes.addElement(new Attribute(CATEGORY, categories));

    Instances instances = new Instances("Weka", attributes, INIT_CAPACITY);
    instances.setClassIndex(instances.numAttributes() - 1);
        
    for (String[] pair : TRAINING_DATA) {
      String text = pair[0];
      String category = pair[1];

      Instance instance = createInstanceByText(instances, text);
      instance.setClassValue(category);
      instances.add(instance);
    }
        
    filter.setInputFormat(instances);
    Instances filteredInstances = Filter.useFilter(instances, filter);
    classifier.buildClassifier(filteredInstances);

    // Test
    String testText = TEST_DATA;
    Instance testInstance = createTestInstance(instances.stringFreeStructure(), testText);

    double predicted = classifier.classifyInstance(testInstance);
    String category = instances.classAttribute().value((int)predicted);
    System.out.println(category);
  }
    
  private static Instance createInstanceByText(Instances data, String text) {
    Attribute textAtt = data.attribute(TEXT);
    int index = textAtt.addStringValue(text);

    Instance instance = new Instance(2);
    instance.setValue(textAtt, index);
    instance.setDataset(data);

    return instance;
  }
    
  private static Instance createTestInstance(Instances data, String text) throws Exception {
    Instance testInstance = createInstanceByText(data, text);
    filter.input(testInstance);
    return filter.output();
  }
}

这个程序分成两个大部分，前半部分用以训练分类器，后半部分则是测试这个分类器。

训练分类器，我们要做的包括，选择分类算法和准备训练数据。在Weka中，每一种分类算法都是Classifier的一个子类，这样的话，就可以在不改变其它部分的情况下，很容易的修改分类算法。

其实，稍微了解一下这方面的知识的人，都会知道，分类算法固然重要，但真正决定一个分类器本事大小的，是用以训练的数据。想要得到一个好的分类器，少不了不断调整训练数据和不断的训练。这同人类认识问题是一样的，经得多，见得广，才有更好的分辨能力。

在Weka中，用以训练的数据就是Instances，顾名思义，这是Instance的复数，显而易见，单独的一个训练数据就是Instance，而Instances这个类的存在，可以把Instance的一些公共的属性放到一起。在这里，我们可以看到，为了用文本作为训练数据，我们会把文本转换为Instance。同样，测试分类器的时候，我们也会把文本转换为一个Instance，然后再进行分类。

除此之外，这里还有一个Filter的概念，同常见的filter概念类似，它给了我们一个进行正式处理之前，对数据进行处理的机会。在这里，主要是对Instance做一些相关的变换。

当我们得到一个分类器之后，就可以利用这个分类器进行分类了，其中，最关键的代码是
    classifier.classifyInstance(testInstance);
这段代码返回的是根据分类算法计算结果得到的一个相似度，我们可以利用这个值来估计我们测试用的数据应该属于哪个分类。

从代码上来说，这段代码本身并不复杂。正如前面所说，一个好的分类器是需要让数据帮忙的。所以，换几个测试数据，你就会发现，这段代码中实现的分类器一点都不强大。如果希望它强大起来，扩展训练数据是一个必然的结果。不过，对于这篇blog而言，这不重要，因为我们只是要和Weka问个好，进一步的工作，还需要进一步的努力。

Fluorida是一个Flash的功能测试工具。如果你听说过Selenium，那么可以把Fluorida理解为它对应的Flash版本。

前不久，gigix对我说，他打算做一个Flash的功能测试工具。我说，从语言的角度来说，我不喜欢Action Script，因为它缺乏美感，但我喜欢这个方向，所以，我觉得这件事靠谱。

上周末的Open Party，听了Michael Chen一个关于Rich Client的session，顺便清理了一下关于Rich Client发展的思路。C/S年代，最大的问题在于部署，升级起来很困难，进入到B/S年代，浏览器的广泛存在解决了部署的问题，不过，简单的页面表现力受到了极大的限制，所以，才有Ajax这样技术的流行。把部署和UI表现力一下子都解决了，那么服务器和客户端的威力就可以得到极大的提升。显然，一些公司看到了这方向，比如MS，它们祭出了Silverlight，不过，从目前的状况来看，在这个领域的领跑者无疑是Adobe的Flash。因为几乎所有拥有浏览器的计算机都安装了Flash Player，这是一个压倒性的优势。

最初的Flash，是为设计者而存在的，所以，谈到Flash，人们首先想到的是“炫”，显然，这不是程序员的强项，所以，大多数开发人员并不会和Flash太亲近。Adobe认为Flash应该扮演更重要的角色，比如成为前面提到的新一代C/S结构的领军人物，但是，想做到这一点，必然需要大量开发人员的支持，所以，Adobe不断的让Flash进化着，比如，Action Script从2到3，发生了巨大的变化，用Action Script 3加入了面向对象，用它写程序，感觉和用通常的程序设计语言并无二致。Adobe甚至更近一步推出了Flex，实际上，它就是为开发人员提供的Flash。再在Eclipse的基础上，打造出Flex Builder，所有这一切都是为了亲近开发人员。Adobe AIR的推出，让Adobe在这方面野心显现无疑。可以看到的是，Adobe的脚步并未停止，它还打算让更多的语言运行在Flash上，显然，它们要提供的是一个新的平台，用以抗衡.NET和Java。

站在开发者的角度，我们更关心怎么让自己的开发工作更舒服一点。作为一个ThoughtWorker，没有测试的日子是让人难以忍受的。在之前的一个进行Flash开发项目中，FlexUnit成功填补了Flash开发拼图的单元测试框架这块，而功能测试这块却一直没有很好的做起来，有人尝试过FunFX，但总觉得不爽。

当gigix要写一个Flash集成测试工具的时候，我知道，参与过Selenium开发的他，对于功能测试应该是什么样子，心里应该很有数。事实就是这样，从接口上来看，Fluorida与Selenium如出一辙。

欢迎任何对这个项目感兴趣的人加入，0.0.1意味这个项目中有许多事可做，你可以给出你的建议、意见或是代码，甚至你觉得这个项目的名字不好也可以建议修改。因为这个项目最开始叫做Fluorine，由于与一个Remoting框架相同，gigix把它改成了现在的Fluorida。

俗话教导我们，在家千日好，出门一日难。

最近，因为工作需要，我有一段时间没有在自己办公室，而是在客户现场。按说，在那里，人家对我们客客气气的，尽可能帮助我们解决遇到的问题，而且，一般这种情况下，都是吃得好喝得好的，应该没有什么不舒服的。但是，无论如何，这些日子总是让人感觉很不爽。今天临下班的时候，当大家决定明天都回公司的时候，项目组的同事们几乎欢呼起来。

无论是在西安，还是在北京，甚至是在班加罗尔，只要是在ThoughtWorks的办公室，我都是感觉很放松，因为我是这里的人，在这里，我可以肆无忌惮。到了客户现场，下意识就会绷紧一根弦，无论说什么做什么都要小心翼翼，毕竟在外面，无论你愿意不愿意，你都代表着公司形象，为了不给公司丢脸，做什么都要经过一下大脑。所以，我觉得在客户现场，即便一天什么都不做，都会觉得很累。

其实，我早就知道，在别人的地盘不好玩。离开东软之前的最后一年，我就是被发配到北京的一家公司，进行现场的开发。按理说，那的物质条件比东软要好很多，而且，经常有机会参加那里组织的活动。但那一年，是我最为压抑的一年。在那里，虽然从来没有人故意另眼相待，但我总觉得自己不属于那里，虽然在那里工作将近一年的时间，却从未真正融入那里的圈子。或许，这种心灵上没有归属感坚定了我离开东软的信念吧！

我还听说过另一个关于在外工作的故事。我之前工作的一个部门，派了很多人到美国去做开发。在很多人看来，这些人有机会出国，而且拿着相对较高的补助。而事实是，那些去之前对美国无限向往的家伙，从美国回来之后，都对彻底那里失去了兴趣，甚至闻之色变。当然，这其中有很多故事。

总而言之，在外不如在家好。无论如何，明天要回办公室了！

我的程序人生是从微软的技术起步的。虽然那时已经是Windows的年代，但是目光的局限，让我依然还是在DOS上下了一些功夫。也是因为从DOS出发，后来顺理成章的进入了Windows开发的行列。那时候的我是很努力的，不断的探索着各种各样的技术实现，不断的阅读着各种各样的书刊杂志，也着实记住了一些所谓的技术。不过，有个问题一直困扰着我，我觉得自己记住的只是一些形，而非神，这些形的东西是很容易忘记的，所以，我一直觉得自己并没有真正的理解编程，我甚至一度怀疑适不适合做开发。

真正让我开始觉得心里踏实是以程序员为职业之后。我的职业之路起步于Java，做的是服务器端的开发。跨平台的Java让我的目光不在局限于微软的平台，而服务器端的开发，让我有机会更加关注软件设计本身，而并非花哨的表现形式。随着开发越做越多，我逐渐开始摸索到了一些共性的东西，对自己的程序人生充满了信心。

走不同的路，得到的结果差异会很大。从上面提到的我个人的经历反映出在不同的技术社区内的不同倾向。记得有人说过，微软社区更倾向于探究底层实现，而Java社区更关注设计架构。其实，差别并不只这些，比如，微软的技术社区倾向于追踪新技术，因为几乎差不多每隔几年，微软就要把自己的东西推翻了重来，从DOS到Windows，再到.NET的变化，而Java社区的人则是在一个稳定的基础上不断的发展。微软是为了商业上的发展，所以，它要不断推陈出新，而Java也有变化，比如EJB到without EJB，但决定因素多半是技术上的，而非商业上的。

如我前面所说，微软社区有很多人关注的是一些细节上的实现，所以，造成的结果是他们不得不在茂密的技术丛林中不断摸索，而无暇顾及其它。我们公司内部，有一个技能列表，上面记录着哪些人会哪些东西，比如Java、.NET、Ruby等等，这样方便做项目时进行资源调配。其中有一个有趣的现象，只拥有一项技能的开发人员大多都属于.NET阵营。而Java阵营的人，经过最初的探索，会发现原来自己学到的东西是可以用在很多其它的地方，于是他们的触角开始伸向其它地方，比如JavaEye这个以Java命名的网站上会有很多关于Ruby的讨论、关于函数式编程的讨论、关于Erlang的讨论，这些东西少有会对Java开发本身产生直接的帮助。

如果已经从最初的阶段突围而出，或许，这些差异并不重要，因为我们做事靠的是自己的方法和一些共性的东西。但对于刚开始成为程序员的人来说，并不知道这些差别的存在，一个人的见识有限时，他会认为自己见到的就是整个的世界，就像我刚开始编程那会儿。

其实，我觉得最适合编程起步的应该是Unix开发。这些年里，很多出自贝尔实验室的书，比如《Unix编程环境》、《程序设计实践》、《C程序设计语言》等等都是在探索软件开发本质的书，而Unix的诞生地正是贝尔实验室。Eric Raymond写过一本《Unix编程艺术》，品味之下，便不难发现，许多随着Unix而生的是做事的方法，而这些方法并不是把人限制在Unix这个具体的平台之上，而更多的是一种通用的软件开发理念，拥有了这些理念，即便进入了一个陌生的领域，只要稍加学习，从前的感觉便会回到身边。

起步固然重要，不过，即便起步并非一帆风顺，如果抱有一个开放的心和一个思考的大脑，最终，都会走上同样的开发之路。

相关文章：

PreferDesignSkills
InfoQ评论英文版： Prefer Broad Design Skills over Platform Knowledge
InfoQ评论中文般： 丰富的设计技能胜过特定于平台的知识

我对程序设计语言有着偏好，所以，我喜欢不断接触各种新语言，喜欢研究语言背后的实现。

最近一段时间，我做的项目用到的几乎都是对我而言的新语言：C#、ActionScript、PHP……，这等价于我要不停的学习自己新语言。

我很享受学习新语言的过程，因为它们会带给我一些不同的体验。每一种语言都有自己不同的适用范围，这一点在学习像ActionScript和PHP这种有很强领域色彩的语言时，体现得尤为明显。运用这些语言写程序的过程中，很容易体会到语言作者在设计时的侧重。

学习新语言，某些情况下也有一些让人难受的地方。经常是，程序出现了语法错误，却瞪眼看不出来，突然意识到错误所在，原来自己用的是熟识语言的语法，不禁莞尔。有时，语言或程序库与自己熟悉的习惯不相一致，经常会被绊住一段时间。

好吧！回到开头，Martin说，设计技能更重要。我想说，设计技能只是很重要的一方面，更多的还是自己做事的方法和习惯。跨越语言时，对此体会会更加深刻。

最近是在写一些PHP代码，我完成一个功能的过程大致如此；弄清楚自己要做的是什么，想一下大概应该如何实现，用PHPUnit编写测试，然后完成功能，运行所有测试，确保这个实现正确以及没有破坏任何已有的东西。把PHP换成其它语言，相信过程是类似的。

如果你有机会像我一样在语言之间穿梭，在度过最初的痛苦期之后，你会发现一切会回到自己熟悉的轨道上。设计、编码、查文档、测试，没有什么不同，所做的一切，都是把自己的想法落实成代码，只不过，由于语言的差别，落实成具体的代码，形式上略有差别而已。

当然，我们不是教条主义者，不只是简单粗暴的知识映射。语言和语言之间是有差别的，所以，学习语言时，我们会注意到语言为我们提供的便利，比如，动态语言的特性，比如，函数的抽象等等，这样我们可以更好更优雅的完成我们的工作。

相关文章：