程序员英语学习三部曲

簡體傳統

读文档不能只读代码

读文档只读代码，是很多程序员的习惯，也是导致程序员虽然读了很多英文资料，英文水平却没有相应提高的原因之一。以前曾在《程序员》上看到介绍阅读技术图书方法的文章，提出过“先代码后文字”的方法，也就是“先看代码，看不明白再看文字”。这种阅读法能极大提高阅读效率，但如果技术图书只看代码就足够，还要文字干什么呢？很多时候，代码只是冰山一角，代码背后的思维和逻辑才是真正的重头戏，只有写成文字才能解释，也只有阅读文字才能理解。

比如，代码都是“x = 5;”，有时的说明是x should be not more than five，有时的说明是x should be no more than five。不查词典，你能弄清楚两种说法的区别吗—前者是“x必须小于等于5”，后者是“x应当只有5”，意思不同，应用的方法与场合也不相同。

这些年来经常有希望翻译技术文档的程序员来找我讨论翻译问题，希望了解一些句子应该如何表达。一开始，我也认为这是中文表达的问题，但后来逐渐发现，其实更多的问题出在英文阅读上，所以我的回答经常是：你觉得作者这里说的是什么意思？引导对方把原文的意思逐步表达出来，其实这时候，真正的译文已经浮出水面了。

最近的例子来自这句话：“But as with any web-based system, atom-based solutions trade scalability for latency, making atom often inappropriate for very low-latency notifications”。这句话之所以难翻译，问题似乎在于，除去句子的主干，之前有一个But as…，之后又有一个making…。然而我最后发现，对这个句子有疑问的程序员其实根本没搞懂trade…for…的用法（翻译为“基于atom的解决方案需要权衡延迟和性扩展性”），如果明白它是“牺牲xx换取xx”之后，整个句子就相当好理解，也非常容易翻译了：与所有基于web的系统一样，基于 atom的解决方案为追求可扩展性，增大了延迟，所以atom通常并不适用要求极低延迟的提示。

要解决这个问题，首先要做的是改变“只看代码不看文字”的习惯，至少要做到“阅读文字之后，认识到它的意思与代码是一致的”；其次是通过阅读纯文字的英文资料来学习某些新的知识（比如关于深入原理的细致讲解），这个方法我推荐给许多朋友，非常有效。

注意读音

以前总听人说，中国人学了很多年英语，其实是哑巴英语。不知道现在的情况有多少改观，但就我所见，不少程序员虽然阅读了大量英文资料，也会加入英文的讨论组，也敢开口说，但还会在读音上出现许多问题。这里说的“读音”，并不是字正腔圆的口音，而是一些术语的读音。

众所周知，计算机科学的术语来源非常广泛。例如设计模式里，有一种模式叫Facade，许多人往往直接读作，其实这个词来自法文，正确的读音其实是；再比如伪代码的“伪”pseudo，正确的读音是，但我很少遇到程序员能把它读对，许多人干脆不会发这个音。

也许有人说，这些问题不重要，大家“将错就错”，约定俗成就得了，但事情没有这么简单。最近我参加某个技术聚会，有一位嘉宾（技术高手）把框架名 chameleon（变色龙）读成了，而正确的读音是，因为没有文字资料，许多人听了半天才知道他说的是什么，一些不熟悉chameleon的听众更是到结束也没明白。中国人聚会尚且如此，如果有机会参加中外技术交流，读错造成的问题就更大了。