程序员学英语三部曲

openkk 12年前
     <p> <strong>文 / 余晟</strong></p>    <p> <strong>作者在 IT 业从业多年,翻译过多本技术图书,对英语的学习方法也有颇多积累。在本文中,他更是敞开心扉,分享了自己压箱底的三大绝技。</strong></p>    <p> 总的来说,程序员算是英语水平比较好的群体,因为在这个行业,英文资料是最全面、最及时、需求也最迫切的。因此,据我观察,即便刚入门不久的程序员,面对陌生的问题,一般也能查阅英文文档,找到需要的信息。但同时,我也发现,经常阅读英文文档的程序员,英语水平许多时候却并不像“经常阅读英文” 的样子。下面我列几点自己的学习心得,供大家参考。</p>    <p> <strong>读文档不能只读代码</strong></p>    <p> 读文档只读代码,是很多程序员的习惯,也是导致程序员虽然读了很多英文资料,英文水平却没有相应提高的原因之一。以前曾在《程序员》上看到介绍阅读技术图书方法的文章,提出过“先代码后文字”的方法,也就是“先看代码,看不明白再看文字”。这种阅读法能极大提高阅读效率,但如果技术图书只看代码就足够,还要文字干什么呢?很多时候,代码只是冰山一角,代码背后的思维和逻辑才是真正的重头戏,只有写成文字才能解释,也只有阅读文字才能理解。</p>    <p> 比如,代码都是“x = 5;”,有时的说明是x should be not more than five,有时的说明是x should be no more than five。不查词典,你能弄清楚两种说法的区别吗—前者是“x必须小于等于5”,后者是“x应当只有5”,意思不同,应用的方法与场合也不相同。</p>    <p> 这些年来经常有希望翻译技术文档的程序员来找我讨论翻译问题,希望了解一些句子应该如何表达。一开始,我也认为这是中文表达的问题,但后来逐渐发现,其实更多的问题出在英文阅读上,所以我的回答经常是:你觉得作者这里说的是什么意思?引导对方把原文的意思逐步表达出来,其实这时候,真正的译文已经浮出水面了。</p>    <p> 最近的例子来自这句话:“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 通常并不适用要求极低延迟的提示。</p>    <p> 要解决这个问题,首先要做的是改变“只看代码不看文字”的习惯,至少要做到“阅读文字之后,认识到它的意思与代码是一致的”;其次是通过阅读纯文字的英文资料来学习某些新的知识(比如关于深入原理的细致讲解),这个方法我推荐给许多朋友,非常有效。</p>    <p> <strong>注意读音</strong></p>    <p> 以前总听人说,中国人学了很多年英语,其实是哑巴英语。不知道现在的情况有多少改观,但就我所见,不少程序员虽然阅读了大量英文资料,也会加入英文的讨论组,也敢开口说,但还会在读音上出现许多问题。这里说的“读音”,并不是字正腔圆的口音,而是一些术语的读音。</p>    <p> 众所周知,计算机科学的术语来源非常广泛。例如设计模式里,有一种模式叫 Facade,许多人往往直接读作['fəkɑ:d],其实这个词来自法文,正确的读音其实是[fə'sɑ:d];再比如伪代码的“伪”pseudo,正确的读音是['su:dəu],但我很少遇到程序员能把它读对,许多人干脆不会发这个音。</p>    <p> 也许有人说,这些问题不重要,大家“将错就错”,约定俗成就得了,但事情没有这么简单。最近我参加某个技术聚会,有一位嘉宾(技术高手)把框架名 chameleon(变色龙)读成了['t∫əmiljən],而正确的读音是[kə'miljən],因为没有文字资料,许多人听了半天才知道他说的是什么,一些不熟悉 chameleon 的听众更是到结束也没明白。中国人聚会尚且如此,如果有机会参加中外技术交流,读错造成的问题就更大了。</p>    <p> 要解决这个问题,有一个非常好的办法,就是学习美国大学的公开课,耶鲁、斯坦福等学校的计算机系都放出了许多高质量的公开课,学习其中的一些精品课程,不但能夯实基础,还能顺带学会许多每天都要遇到但不会或者读错的术语。比如我就从中学到,数据类型 char 的读音是[kɑ:],而不是[t∫ɑ:]。</p>    <p> <strong>锻炼英文表达</strong></p>    <p> 如果你背过单词,大概听到过“被动单词”和“主动单词”的说法,前者是指“看到了能认出来”的单词,后者指“表达时能主动应用”的单词。据我观察,许多程序员掌握的大多数英语,都属于“被动英语”——看到了能认识,但要表达同样的意思,未必说得出来。</p>    <p> 平时这样似乎没有问题,但如果要查阅资料,不会表达就造成了大的障碍。相比中文技术资料世界中“无责任/不负责转贴”泛滥的情况,英文技术资料的质量要高得多,Google 搜索资料的准确性也远高于百度;但要能够顺利应用英文资料,需要“主动”输入信息,描述问题,这时候“被动英语”就成了大问题。</p>    <p> 我遇到过很多次这样的情况:即便答案近在咫尺,输入正确的关键词,Google 的第一条结果就是答案,但程序员就是一筹莫展——因为他不知道计算机的“嘟嘟”声是 beep,不知道搜“多线程”资料应该用 concurrency,也不知道“死机”是 system halt,“黑屏”是 blank screen……</p>    <p> 要解决这个问题,最好的办法是在阅读资料时多用心,记住这些说法;另一方面,没事的时候多浏览 stackoverflow 之类的网站,不要因为问题与自己无关而忽略,要多留心这些问题到底是什么,是如何表达的。这样,在自己遇到问题时,才能迅速找到可能的解决方案,节省时间。</p>    <p> <strong>结束语</strong></p>    <p> 有人说,以汉语为母语的程序员,学习英语已经是迫不得已,不但要会阅读,还要会表达,真是难上加难。这种说法有一定道理,但在目前并没有更好的解决方案的情况下,学会阅读、认准读音、锻炼表达,确实可以给自己带来好处。长远来看,要改变这种情况,需要中文技术圈的所有人员努力贡献高质量的资料(原创和翻译都可以),如果只是“无责任转贴”,既不亲自验证,也不整理格式,中文技术资料的整体质量只会持续恶化,反向逼迫更多的人把英语学好。</p>    <p> <strong>作者余晟,曾任盛大创新院高级研究员,现任广州某电商和物流公司技术负责人。关注技术如何解决实际的问题。业余翻译、审校过若干本技术书籍,并撰写了一本讲解正则表达式的书。</strong></p>    <div id="come_from">     来自:     <a id="link_source2" href="/misc/goto?guid=4958332112000316681" target="_blank">www.programmer.com.cn</a>    </div>