梦想风暴

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

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

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

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

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

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

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

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

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

作为一个有理想、有追求的程序员，你成天被各种名词包围着，你对其中一个叫做敏捷的东西特别感兴趣，因为它特别强调人的作用，这听着都让做程序员的你感到舒服。为了让自己早日敏捷起来，你从众多的敏捷实践中选择了一个叫做测试驱动开发（Test Driven Development，TDD）的作为你的起始点。因为它对你周遭的环境要求是最低的：它不像结对那样，要求其他人和你一起合作；也不像采用Story那样改变你所在团队的做事方式……你所需要做的，只是在你编写业务代码之前，把测试先写好。这完全是一种润物细无声的做法，根本无需告诉你之外的任何人。就在别人忙碌的找bug时，你便开始享受敏捷带给你的快乐了。顺便带来的好处是，下次在那里和别人争论敏捷的时候，你可以以一个实践者的姿态出现，而不是在那里信口开河。

你不会打无准备之仗，于是，你通读了Kent Beck的那本薄册子。通读之下，你对TDD更是充满了信心。因为“红——绿——重构”的步骤实在是简单得令人发指。好吧！总而言之，你已经信心十足的准备开始TDD，步入敏捷的康庄大道了。

理想很美好，现实很残酷。

当你着手在实际项目中体验TDD的时候，一切变得并不像最初看起来的那样美好。虽然你努力的坚持着TDD的原则，但你经常就会发现某些东西不好测，比如你遇到了数据库，比如你遇到了GUI，比如你遇到了计时器（Timer）。敏捷并非教条，当某些事不可为的时候，你完全可以不那么坚持。于是，你告诉自己，不好测的东西可以不测，这样，至少从心理上来说，你觉得舒服多了。随着工作的继续，你发现，你不能测的东西越来越多，单元测试的覆盖率随着开发的进行正在逐渐降低，一丝恐惧涌上心头。回过头来，再去看Kent Beck的书，你突然觉得，你似乎被骗了，因为Kent Beck的例子貌似全都是逻辑，如果只是逻辑，当然好测了，但现实从来就不是这样。

难道TDD只是看上去很美？

显然，你不愿意就这样放弃，放弃你苦心学来的软件开发秘籍，那些传说中的高手极力推崇的TDD必然有一定道理，TDD确实能够让你感觉很好：能测试的那部分代码确实极大的增强了你对软件质量的信心，而且出错了也确实好找，每次修改代码之后运行测试出现的绿条也确实让你身心愉悦。

那问题到底出在哪呢？你陷入了沉思。

信马由缰，你翻开了自己写过的代码。看着自己写的这些代码，你忽然意识到一个问题，自己遇到的问题并不属于TDD，而是属于单元测试。正如你之前所想到的那样，TDD做法本身的结果是让你感到快乐的。对，一定是单元测试本身出了问题。那单元测试出了什么问题，很显然，一大堆不能测试的部分让单元测试变得很难写，降低了单元测试的覆盖度。那是不是这会是一个无解的问题呢？你显然不愿意就此放弃，所以，顺着这个思路继续向前。

TDD之所以让你安心，主要是每次编写代码之后，运行测试会出现一个绿条，告诉你测试通过。这样，你可以放心大胆的向前继续，因为你的代码并没有破坏任何东西。究竟是什么让你感到不安，显然是那些测试没有覆盖到的代码。你又仔细翻看了一下那些没有测试覆盖的代码，你的思路一下子清晰起来。之所以这部分让你不安，因为里面除了那些确实不好测试的部分之外，里面还有一些逻辑。如果只是那些真正不好测试的部分没有被测试覆盖到，你会觉得心里还有一些安慰。你确定了，真正使你不安的就是与不好测试的代码共存亡的这些逻辑部分。

如果测试可以覆盖到这些逻辑的部分，至少从感情上来说，就可以接受了。那怎么才能让这些部分被测试覆盖到呢？你仔细观察着那些没有测试的代码，如果这样做，这个部分就可以测试了，如果那样做，那个部分也可以测试了，一来二去，这些貌似不可测试的代码可以分解出许多可以测试的部分。

你的心情一下子好了许多，因为这么做终于可以让测试的覆盖度达到让你心理上可以接受的范围。不过，新的问题也随之而来。我在做什么？拆来分去，这不就是设计吗？怎么走到这里来了。我不是在分析单元测试的问题吗？对了，我最初的问题是TDD，怎么一路跑到设计上来了？

TDD？设计？

你突然发觉自己对TDD的理解有一些偏差。TDD，并不代表不需要设计。读过很多书的你突然想起了Robert Martin那本著名的《敏捷软件开发》，上面有一个关于数据库访问的例子。那个例子里面，前后两个版本的差异正好就是考虑设计的结果。通常，在设计中考虑测试，会很容易找到设计中僵硬的部分，让程序更加灵活。再进一步，如果在开始动手之前，稍微进行一些设计，这些问题还是可能注意得到的。你突然觉得，正是因为TDD本身过于强调测试的价值所在，让你忽略软件开发中很重要的部分：设计。

思路一下子清楚起来，TDD其实不只是“红——绿——重构”，它还是与设计相关的：在动手之前，还是要有一定的设计，而且，在设计中要考虑测试的问题。终于解开了心中的困惑，现在的你，对于TDD有了一个新的认识，虽然这个认识不见得是什么终极真理，但至少是通过自己的思考得来的，这让你更加相信实践出真知的道理。

理清思路后，你更加坚信TDD本身的价值所在，也坚定了在日后开发中继续使用TDD的念头，当然，目光远大的你已经盯上了其它的敏捷实践。

Lucene是什么？下面是官方回答。

Apache Lucene is a high-performance, full-featured text search engine library written entirely in Java.

简而言之，它是用来做搜索的库。提及搜索，我们的思绪就会情不自禁飞到串匹配上。没错，串匹配确实是一种搜索，但对于不同的应用，搜索的方法不一样，对于在一篇文档中进行搜索这种小规模应用而言，串匹配足够了，而Lucene为我们向大规模搜索铺上了一条大道。大规模？是不是想到了搜索引擎，事实上，Lucene就是被很多人用来构建搜索引擎。

关于搜索引擎的实现，很多人或多或少的听说过一些，比如网络爬虫，比如分布式的架构，比如PageRank。抛开其它其它复杂的部分，最关键的步骤便是建立索引，然后进行搜索。不妨让我们Lucene是如何实现这最关键的部分。

import java.io.File;
import java.io.FileReader;

import org.apache.lucene.analysis.standard.StandardAnalyzer;
import org.apache.lucene.document.Document;
import org.apache.lucene.document.Field;
import org.apache.lucene.index.IndexWriter;

public class Indexer {
    public static void main(String[] args) throws Exception {
        File indexDir = new File("index");
        File dataDir = new File("data");

        IndexWriter indexWriter = null;
        try {
            indexWriter = new IndexWriter(indexDir, new StandardAnalyzer(), true);
            for (File file : dataDir.listFiles()) {
                if (file.isFile() && file.getName().endsWith(".txt")) {
                    Document document = new Document();
                    Field pathField = new Field("path", file.getCanonicalPath(),
                        Field.Store.YES, Field.Index.TOKENIZED);
                    document.add(pathField);
                    Field contentField = new Field("contents", new FileReader(file));
                    document.add(contentField);
                    indexWriter.addDocument(document);
                }
            }
            indexWriter.optimize();
        } finally {
            if (indexWriter != null) {
                indexWriter.close();
            }
        }
    }
}

这段代码很容易理解，遍历数据目录下的文本文件，为每个文件生成索引。

这里有一个Document的概念，它在Lucene表示的是索引和搜索的单位，也就是说，建立索引，是以Document为单位的，搜索也是以Document为单位的。Document中有一堆的Field，我们可以把它们理解为Document中一个一个小节。有了Field，我们可以为Document添加一些属性，比如这里，我们就添加了路径（path）和内容（content）两个属性。这样，搜索之后，我们可以利用这些属性提供更多的信息，比如，告诉别人搜索的词出现在哪个文档中。

上面的代码中，我们可以清楚看到，建立Document，并向其中插入Field的过程。有了Document，我们就可以把它借助IndexWriter将它们写入索引中，至于最后的optimize，显然是为了让搜索更有效率而存在的。

有了索引，那就该进行下一步的工作，搜索。

import org.apache.lucene.document.Document;
import org.apache.lucene.index.Term;
import org.apache.lucene.search.Hits;
import org.apache.lucene.search.IndexSearcher;
import org.apache.lucene.search.Query;
import org.apache.lucene.search.TermQuery;

public class Searcher {
    public static void main(String[] args) throws Exception {
        String type = "contents";
        String key = "game";
        String path = "index";
        
        IndexSearcher searcher = new IndexSearcher(path);
        Term t = new Term(type, key);
        Query query = new TermQuery(t);

        Hits hits = searcher.search(query);
        for(int i = 0; i < hits.length(); i++){
            Document document = hits.doc(i);
            System.out.println("File: " + document.get("path"));
        }
    }
}

IndexSearcher是用来在索引中进行搜索主要帮手，前提是我们要告诉它到索引在哪。Term表示文本中的一个词，它说明了我们要在哪个Field（type）中找什么（key）。然后，我们用Term做成一个Query，表示我们要进行搜索了。做好准备，接下来，就是搜索了。搜索的结果叫做Hits。遍历这个Hits，便可以将搜索结果一一展示出来。如前面所说，这里利用路径这个属性报告搜索的结果。

有了Lucene做基础，能做的事就很多了，比如搭建一个搜索引擎。事实上，已经有了这样的开源项目，比如与Lucene同出一门的Nutch，比如比Nutch年纪更大的Compass。

大多数人都愿意与高手共事，因为他们指望着从高手身上可以学到很多东西。在ThoughtWorks，因为要pair，所以，我们可以有更多的机会与高手近距离一起工作。

如果真的有机会和高手一起工作，有时，你会发现，从具体做的事来说，这些高手做的事并不像想象的那么高深，甚至可以说很简单，简单到换了谁都能做。于是，心中的高手形象逐渐开始动摇，难道令N多人景仰的高手就是这个样子。

不知道你有没有想过这样一个问题，同样的事，如果没有高手的参与，换你来做，结果会怎样呢？

老大给我讲了一个他当年和Ward Cunningham在一起工作的故事。每天做的工作就是日常的测试驱动开发，写测试、写代码，所有的一切都是异常简单，下午从不会耽误喝咖啡的时间，到点也就正常下班。一个月后，要做的事情做完了，没有觉得有什么特别之处。不过，回想了一个月前对于这个项目的看法，老大突然发现，这一个月里原来做了许多事情：一个月前，他还觉得这是一项不可能完成的工作。

我最近的一个项目里，和我一起工作的是有我们中国区的CTO。这个项目的前期是一个类似于可行性论证的工作，项目最初，他为整个项目的结构订下了一个基调，让整个项目的结构显得特别清晰，准确的说，应该是很简单，简单到让人觉得理所当然。单从工作的具体内容来看，他并没有在这个项目里面做太多的事情，但从另外一个层面来说，正是他做的前期所做的工作，让后面的工作变得容易了许多。

这么一说，是不是有一种高手形象顿失的感觉。其实，高手通常不会觉得自己是高手。多年积累下的，只是良好的工作习惯而已。他们知道，自己是普通人，自己不能应付过于复杂的东西，于是，把自己要做的事分解成一些非常简单的小事。只要把这些微不足道的小事做好了，所谓的大事便也做成了。

我很喜欢读的书中，有几本书出自贝尔实验室，比如《程序设计实践》、《Unix编程环境》、《C程序设计语言》等等，每一本都是那么轻薄。这些书里面的内容读起来都是那么轻松，每一步做的事都让人觉得太过简单，但回过头来，可能你才发现，原来一些貌似很复杂的工作已经完成了。

曾有一段时间，我一直觉得自己掌握的东西不够复杂，为此，我总是惴惴不安。后来发现，但凡我学过的东西本质上都很简单，于是我想，到底怎么才能让自己复杂起来。读过那几本书之后，我释然了：做事本就该是做简单的事。如果你觉得复杂，多半是走错了路。

与高手共事，技术之外的东西，也许更值得学习。