看文档看不懂只读代码看文档看只读代码是很多程序员的习惯，也是程序员看了很多英文资料却没有提高英语水平的原因之一.之前在《程序员》上看到一篇介绍阅读技术书籍方法的文章，提出了“先代码，后文字”的方法，即“先看代码，不懂再看文字”它”。这种阅读方式可以大大提高阅读效率，但如果技术书籍只够看代码，何必还要文字呢？很多时候，代码只是冰山一角，代码背后的思考和逻辑才是真正的亮点。写出来才能说明，读起来才能明白。比如代码都是“x=5;”，有时候解释是x应该不超过5，有时候解释是x应该不超过5。不查字典，你能搞清楚这两种说法的区别吗——前者是“x必须小于或等于5”，后者是“x只应为5”。含义不同，应用的方法和场合也不同。多年来，经常有想翻译技术文档的程序员来找我讨论翻译问题，希望了解一些句子应该怎么表达。一开始我也以为是中文表达的问题，后来慢慢发现更多的问题其实是英文阅读导致的，所以我的回答往往是：你觉得作者这里是什么意思？引导对方循序渐进地表达原文的意思。其实这时候，真正的翻译已经浮出水面了。最近的一个例子来自这句话：“但与任何基于网络的系统一样，基于原子的解决方案以可扩展性换取延迟，使得原子通常不适合非常低延迟的通知”。这句话难译的原因似乎是，除了句子的主体，前面还有一个Butas...，后面还有一个making...。然而，我终于发现，对这句话有疑问的程序员其实并不理解trade...for...的用法（译为“基于原子的解决方案需要权衡延迟和可扩展性”）。Aftersacrificingxxforxx”，整句话很好理解，也很容易翻译：和所有基于web的系统一样，基于原子的解决方案为了追求可扩展性而增加延迟，因此原子通常不适合需要极低延迟的Hints。解决这个问题，首先要改变“只看代码不看文字”的习惯，至少要“看完文字，体会到其意思与代码一致”；英文资料要学习一些新知识（比如深入原理的详细讲解），我把这个方法推荐给很多朋友，很有效。注意发音。以前听人说中国人学英语很多年，但其实都是哑巴英语，不知道现在的情况改善了多少，但据我所知，虽然很多程序员看了很多英文资料，加入了英文讨论组，敢于发言，有直到很多发音问题。这里所说的“读音”不是字的重音，而是一些名词的读音。众所周知，计算机科学的术语来源非常广泛。比如在设计模式中，有一种模式叫做Facade，很多人经常直接读成blob.png。其实这个词来源于法语，正确读法其实是blob.png；再比如伪代码的“伪”伪，正确的读法是blob.pngblob.pngblob.png，但我很少遇到能正确读出的程序员，很多根本就不会读。也许有人会说，这些问题都不重要，每个人都“犯错就犯错”，约定俗成，但事情并没有那么简单。最近，我参加了一个技术聚会。一位嘉宾（技术达人）将框架名chameleon（变色龙）读成了blob.png，正确读音是blob.png。因为没有文字资料，所以很多人都是听了很久才知道的。他说的话，一些不熟悉变色龙的听众直到最后才明白。华人聚会仍是如此。如果有机会参加中外技术交流，误读带来的问题会更大。要解决这个问题，有一个很好的方法，就是学习美国大学的公开课。耶鲁、斯坦福等学校的计算机系都发布了很多优质的公开课。学习一些这些优秀的课程，不仅可以打下坚实的基础，顺便也可以学到很多每天都会遇到但听不懂或者读错的术语。比如我从中了解到数据类型char的读音是[kɑ:]，而不是[t∫ɑ:]。练习英语表达。如果你背过单词，你可能听说过“被动词”和“主动词”这两个词。.据我观察，很多程序员掌握的英语大多属于“被动英语”——看到就认得，但要表达同样的意思就不一定会说。平时用这种方式好像没什么问题，但是如果要查阅资料，就会表达不出来，就会造成很大的障碍。与中文技术资料世界“不负责任/不负责任的转贴”泛滥相比，英文技术资料的质量要高得多，谷歌搜索数据的准确性也比百度高得多；但要想顺利使用英文资料，你需要“主动”输入信息并描述问题。这时候，“被动英语”就成了大问题。我曾多次遇到这样的情况：即使答案近在咫尺，输入正确的关键词，谷歌的第一个结果就是答案，但程序员却束手无策——因为他不知道计算机的“嘟”声是哔哔，不知道应该用并发来搜索“多线程”的资料，也不知道“crash”是系统死机，“黑屏”是黑屏……解决这个问题，最好的办法是看资料时多加注意，记住这些说法；另一方面，没事的时候浏览一下stackoverflow之类的网站，不要因为与你无关就忽略问题，多关注这些问题是什么以及它们是如何表达的。这样，当你遇到问题时，可以快速找到可能的解决方案，节省时间。
