看到我厂另一位同事写的“为什么程序员英文要好” https://www.v2ex.com/t/239995 特来呼应一下。
（部分内容曾经发在知乎 http://www.zhihu.com/question/23581913/answer/25023096 ）
类似以下的对话几乎每天都会发生在我们公司——我们公司不是外企，只是民营小企业，也没有国际友人。
“用户报了一个 bug ，我提个 issue 给你”
“好，我 check 下。”
“这个 bug 我 fix 了，代码已经 commit 。”
“那我们下周升级这个 App 。”
这四句话里，有 6 个英文单词，我给它们做个归类，分析下为什么我们会不自觉地选用英文而非相应的中文单词。
首先， bug 这个词已经深入人心，专指计算机软件产生的问题，不仅是专业的工程师用这个词，很多用户也会直接说这个程序有 bug 我用不了。这个从早期计算机教育里就引入的英文单词已经用来专指软件的逻辑故障，比任何单一中文词汇都更加准确；譬如如果改说程序出了故障，大部分人很可能第一反应是硬件问题，如果说程序有了问题，又无法立刻表明究竟是使用产生问题还是程序本身问题。
再看 issue, commit 这两个词，中文可以翻译为“工单”和“提交”，为什么我们要用英文呢，因为我们用的代码和问题管理软件里用的就是这两个词，所以对一个工程师说我给了你一个 issue ，那么他第一反应就会打开管理软件去查看，说的人和听的人脑子里都不用翻译转换。当然，如果用的软件是中文的话，我相信我们肯定会用“工单”而非 issue ，总之怎么省事怎么来。
再看 check, fix ，还有 App ，在中文里是有相对明确的对应词汇的，分别是“检查”，“修复”，还有“应用”。实际上我们也确实有时候会用对应的中文词，但是用英文更多，为什么呢？因为这几个英文词念起来更省力啊。
所以深究起来，想要用语言口头表达一个概念，以及想要理解自己听到的一个概念，都是要付出成本的，前者会涉及到词汇是否好念，是不是能够第一时间想到（从概念转换到词汇），后者会关系词汇是不是清晰（同音字 /词就很讨厌），是不是能迅速理解（从词汇转换到概念）。
在语言学里有一条著名的经验法则, 由哈佛语言学家 Zipf 提出并以他的名字命名，也就是 Zipf 定律。 Zipf 发现，如果把一种语言中的所有的词按照词频从大到小排序，并记录它们的排列位置，那么一个词的词频 f ，和它的位置 r ，近似满足如下关系：
f*r=k 其中 k 是一个常数。
掩藏在这公式背后的意思是，对于同一个概念，说话者期望选择一个出现频率很高，但是词义较含糊的词来表达，而听者则希望接受到一个出现频率很低，相应更精确的词汇。极端情况下，说话者巴不得只用一个词就能表达天下所有的意思，而听者则最好是一个萝卜一个坑，一个概念只有一个词相对应。总之双方都指着对方多担待，自己省点事儿。 Zipf 将此称为最省力原则(Principle of least effort).
对应这个原则的 Zipf 定律就是反映了说者和听者两者间讨价还价最后的折衷，即只有相当少的一些词能够表达很多语义，相应具有很高的出现频率；而绝大多数的词则能较准确的表达特定意思，也就只有较少的出现频率。
虽然 Zipf 定律针对的是同一种语言内部，但是在全球化的今天，很多英文词汇已经因为指向明确（因为很多概念首先来自英文，并且在其他语言还没来得及翻译的时候就已经广泛传播），同时也好念，从而符合最省力原则，在口头交流中被双方接受。
反过来说，如果我和一个非软件行业的人解释我们的工作，我基本不可能用任何英文（当然 bug 这个词例外），因为那时候我很清楚光自己说得爽不行，对方听不懂一问再问更麻烦，不如一开始就用中文。
所以说当我们一群码农在内部交流时不停冒英文，真的只是偷懒，而不是装 B 。
非 IT 行业里，很多情况也类似，很多英文术语会直接对应该领域中某个流程中的特定环节，提高沟通效率。
总之，这些单词就是这个行业的黑话。
另外，传说计算机开发中有两大最困难问题：更新缓存，以及变量命名。英文水平高一些，对于变量命名是非常有帮助的，一个不准确或者含糊的名字，不仅会给阅读者（甚至包括起名字的本人）带来歧义，未来还会妨碍新的命名，实际对程序是一种污染。
我们自己遇到过一个实际例子，打卡被命名为 checkin ，当时虽然感觉不是很准，但是将就用了；等到我们策划签到功能时，发现签到的英文就是 check in ，那怎么办，要改的话，不仅后端代码里有，各种对外 API 里也有，意味着所有移动客户端都要改，还要照顾那些不升级的老客户端；可是不改，就要想一个新名字，可这个不准确的新名字一方面用来别扭，另一方面还可能造成未来同样麻烦。
总体来说，扇贝对工程师的英文水平要求是很严格的，甚至扇贝程序中所有文字，实际上是先写成英文，再翻译成中文。虽然一开始有人觉得浪费时间，但是逐渐大家还是接受了，好处是从工单描述，到变量，再到注释，都能尽可能维持一致性。
我们曾经拿托福阅读题给公司里所有员工都做过一次测试，工程师的平均成绩和大部分是英语专业毕业的内容编辑团队是一样的，还有几个满分。
（部分内容曾经发在知乎 http://www.zhihu.com/question/23581913/answer/25023096 ）
类似以下的对话几乎每天都会发生在我们公司——我们公司不是外企，只是民营小企业，也没有国际友人。
“用户报了一个 bug ，我提个 issue 给你”
“好，我 check 下。”
“这个 bug 我 fix 了，代码已经 commit 。”
“那我们下周升级这个 App 。”
这四句话里，有 6 个英文单词，我给它们做个归类，分析下为什么我们会不自觉地选用英文而非相应的中文单词。
首先， bug 这个词已经深入人心，专指计算机软件产生的问题，不仅是专业的工程师用这个词，很多用户也会直接说这个程序有 bug 我用不了。这个从早期计算机教育里就引入的英文单词已经用来专指软件的逻辑故障，比任何单一中文词汇都更加准确；譬如如果改说程序出了故障，大部分人很可能第一反应是硬件问题，如果说程序有了问题，又无法立刻表明究竟是使用产生问题还是程序本身问题。
再看 issue, commit 这两个词，中文可以翻译为“工单”和“提交”，为什么我们要用英文呢，因为我们用的代码和问题管理软件里用的就是这两个词，所以对一个工程师说我给了你一个 issue ，那么他第一反应就会打开管理软件去查看，说的人和听的人脑子里都不用翻译转换。当然，如果用的软件是中文的话，我相信我们肯定会用“工单”而非 issue ，总之怎么省事怎么来。
再看 check, fix ，还有 App ，在中文里是有相对明确的对应词汇的，分别是“检查”，“修复”，还有“应用”。实际上我们也确实有时候会用对应的中文词，但是用英文更多，为什么呢？因为这几个英文词念起来更省力啊。
所以深究起来，想要用语言口头表达一个概念，以及想要理解自己听到的一个概念，都是要付出成本的，前者会涉及到词汇是否好念，是不是能够第一时间想到（从概念转换到词汇），后者会关系词汇是不是清晰（同音字 /词就很讨厌），是不是能迅速理解（从词汇转换到概念）。
在语言学里有一条著名的经验法则, 由哈佛语言学家 Zipf 提出并以他的名字命名，也就是 Zipf 定律。 Zipf 发现，如果把一种语言中的所有的词按照词频从大到小排序，并记录它们的排列位置，那么一个词的词频 f ，和它的位置 r ，近似满足如下关系：
f*r=k 其中 k 是一个常数。
掩藏在这公式背后的意思是，对于同一个概念，说话者期望选择一个出现频率很高，但是词义较含糊的词来表达，而听者则希望接受到一个出现频率很低，相应更精确的词汇。极端情况下，说话者巴不得只用一个词就能表达天下所有的意思，而听者则最好是一个萝卜一个坑，一个概念只有一个词相对应。总之双方都指着对方多担待，自己省点事儿。 Zipf 将此称为最省力原则(Principle of least effort).
对应这个原则的 Zipf 定律就是反映了说者和听者两者间讨价还价最后的折衷，即只有相当少的一些词能够表达很多语义，相应具有很高的出现频率；而绝大多数的词则能较准确的表达特定意思，也就只有较少的出现频率。
虽然 Zipf 定律针对的是同一种语言内部，但是在全球化的今天，很多英文词汇已经因为指向明确（因为很多概念首先来自英文，并且在其他语言还没来得及翻译的时候就已经广泛传播），同时也好念，从而符合最省力原则，在口头交流中被双方接受。
反过来说，如果我和一个非软件行业的人解释我们的工作，我基本不可能用任何英文（当然 bug 这个词例外），因为那时候我很清楚光自己说得爽不行，对方听不懂一问再问更麻烦，不如一开始就用中文。
所以说当我们一群码农在内部交流时不停冒英文，真的只是偷懒，而不是装 B 。
非 IT 行业里，很多情况也类似，很多英文术语会直接对应该领域中某个流程中的特定环节，提高沟通效率。
总之，这些单词就是这个行业的黑话。
另外，传说计算机开发中有两大最困难问题：更新缓存，以及变量命名。英文水平高一些，对于变量命名是非常有帮助的，一个不准确或者含糊的名字，不仅会给阅读者（甚至包括起名字的本人）带来歧义，未来还会妨碍新的命名，实际对程序是一种污染。
我们自己遇到过一个实际例子，打卡被命名为 checkin ，当时虽然感觉不是很准，但是将就用了；等到我们策划签到功能时，发现签到的英文就是 check in ，那怎么办，要改的话，不仅后端代码里有，各种对外 API 里也有，意味着所有移动客户端都要改，还要照顾那些不升级的老客户端；可是不改，就要想一个新名字，可这个不准确的新名字一方面用来别扭，另一方面还可能造成未来同样麻烦。
总体来说，扇贝对工程师的英文水平要求是很严格的，甚至扇贝程序中所有文字，实际上是先写成英文，再翻译成中文。虽然一开始有人觉得浪费时间，但是逐渐大家还是接受了，好处是从工单描述，到变量，再到注释，都能尽可能维持一致性。
我们曾经拿托福阅读题给公司里所有员工都做过一次测试，工程师的平均成绩和大部分是英语专业毕业的内容编辑团队是一样的，还有几个满分。
1
Select Language