作者在 IT 业从业多年,翻译过多本技术图书,对英语的学习方法也有颇多积累。在本文中,他更是敞开心扉,分享了自己压箱底的三大绝技。
总的来说,程序员算是英语水平比较好的群体,因为在这个行业,英文资料是最全面、最及时、需求也最迫切的。因此,据我观察,即便刚入门不久的程序员,面对陌生的问题,一般也能查阅英文文档,找到需要的信息。但同时,我也发现,经常阅读英文文档的程序员,英语水平许多时候却并不像“经常阅读英文” 的样子。下面我列几点自己的学习心得,供大家参考。 读文档不能只读代码
读文档只读代码,是很多程序员的习惯,也是导致程序员虽然读了很多英文资料,英文水平却没有相应提高的原因之一。以前曾在《程序员》上看到介绍 阅读技术图书方法的文章,提出过“先代码后文字”的方法,也就是“先看代码,看不明白再看文字”。这种阅读法能极大提高阅读效率,但如果技术图书只看代码 就足够,还要文字干什么呢?很多时候,代码只是冰山一角,代码背后的思维和逻辑才是真正的重头戏,只有写成文字才能解释,也只有阅读文字才能理解。
比如,代码都是“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,许多人往往直接读作['fəkɑ:d],其实这个词来自法文,正确的读音其实是[fə'sɑ:d];再比如伪代码的“伪”pseudo,正 确的读音是['su:dəu],但我很少遇到程序员能把它读对,许多人干脆不会发这个音。
也许有人说,这些问题不重要,大家“将错就错”,约定俗成就得了,但事情没有这么简单。最近我参加某个技术聚会,有一位嘉宾(技术高手)把框架 名 chameleon(变色龙)读成了['t∫əmiljən],而正确的读音是[kə'miljən],因为没有文字资料,许多人听了半天才知道他说的是 什么,一些不熟悉 chameleon 的听众更是到结束也没明白。中国人聚会尚且如此,如果有机会参加中外技术交流,读错造成的问题就更大了。
要解决这个问题,有一个非常好的办法,就是学习美国大学的公开课,耶鲁、斯坦福等学校的计算机系都放出了许多高质量的公开课,学习其中的一些精 品课程,不但能夯实基础,还能顺带学会许多每天都要遇到但不会或者读错的术语。比如我就从中学到,数据类型 char 的读音是[kɑ:],而不是[t∫ɑ:]。