这是一个创建于 3071 天前的主题，其中的信息可能已经有所发展或是发生改变。
看到我厂另一位同事写的“为什么程序员英文要好” 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 里也有，意味着所有移动客户端都要改，还要照顾那些不升级的老客户端；可是不改，就要想一个新名字，可这个不准确的新名字一方面用来别扭，另一方面还可能造成未来同样麻烦。
总体来说，扇贝对工程师的英文水平要求是很严格的，甚至扇贝程序中所有文字，实际上是先写成英文，再翻译成中文。虽然一开始有人觉得浪费时间，但是逐渐大家还是接受了，好处是从工单描述，到变量，再到注释，都能尽可能维持一致性。
我们曾经拿托福阅读题给公司里所有员工都做过一次测试，工程师的平均成绩和大部分是英语专业毕业的内容编辑团队是一样的，还有几个满分。
 |
101
pclover 2015-12-07 11:53:11 +08:00
说到底是个圈子氛围问题。以前有香港经理在，大家常说这些英文词，后来换个环境，就改中文词，没觉得有什么不方便。“这个问题检查过了，代码已经提交了，我发个邮件给你”，有不方便吗？不觉得。
|
 |
103
michaelye1988 2015-12-07 11:55:30 +08:00
楼主，你是怎么称呼 bug 的？
|
 |
104
zonghua 2015-12-07 11:56:33 +08:00 via iPhone
感觉有个词翻译不了， offer
|
 |
105
Linusyeung 2015-12-07 11:59:15 +08:00 via iPhone
好文，赞一个！
谁叫这些语言都是英语世界的人写的呢？(奇怪，德国人这么腻害，怎么没有德语的？——没关系，都一样，最终还不都是划归成 10011010110010101 ……) 一标题，以为是哪个程序员女友 /男友 在跟人撕呢…… “装 B 这个词是啥意思呢？——这语境是国人闭关锁国、自大，不愿与外界交流的心态。而且还对常说外语的人感到自卑。。感受下？ BTW ， Zipf 怎么念？ |
 |
106
gtalk 2015-12-07 12:06:16 +08:00
交流便利为主吧
几个英文单词没什么值得炫耀的 |
 |
107
ericshine 2015-12-07 12:06:45 +08:00
我也是醉，作为工程师，平常交流经常性的使用英文，多正常的事情。
竟然有人自以为不装逼的转成中文，怎么高效沟通怎么来喽。 |
 |
108
amon 2015-12-07 12:09:55 +08:00  1
软文水平有待提高。
楼主到底想表达什么？ 不标题党会死全家？ 另外，喜欢用中文的话标题肯定不能用“装 B ”咯，得用“装屄”。 |
 |
109
xiaoyu9527 2015-12-07 12:18:49 +08:00
有些真的是习惯 不是为了装逼
|
 |
110
DXpro 2015-12-07 12:23:35 +08:00 2
扇贝是不是要黄了 ，就不能掏点钱做作推广何必发标题党软文呢。吃相真难看。
|
 |
111
Silicon 2015-12-07 12:29:13 +08:00
ROP
Ret-to-libc/Ret-to-dl-resolve GS SEH 有没有中文翻译？有 有没有人会天天用中文说？没有 不信你去听听 |
 |
112
RqPS6rhmP3Nyn3Tm 2015-12-07 13:22:18 +08:00
因为易语言没人用
|
 |
113
nellace 2015-12-07 13:37:17 +08:00
当然是怎么发音短怎么说啊， commit 汉化发音是（肯米特），有三个音节，直接说我提交了更精简啊， tomorrow morning 一大串，帝都大爷一个明早多精简啊，怎么顺怎么来啊，哈哈哈哈
|
 |
114
zjuster 2015-12-07 13:45:50 +08:00
issue 和 commit 简单翻译成工单和提交都是不对的。
|
 |
115
learnshare 2015-12-07 14:24:06 +08:00
@weyou 易语言也是国家支持的项目吧，虽然发展得并不好，但确实也培养了一批热爱程序的人
|
 |
116
qihboy 2015-12-07 15:54:40 +08:00
最不习惯的是把 team building 叫成“团建”的，真的是硬生生的给翻成中文再简化造出来的词，哪怕就叫“团队建设”或是“腐败”都比“团建”好听！
实际上在外企，大家一说 team building 或是 TB 就很有那种可意会不用言传的感觉。 |
 |
117
Kain 2015-12-07 16:53:57 +08:00 via Android
擼主，先把標題改成“裝屄”吧，我覺得，語言只是用來溝通的。能明白就好了，不必太在意。
|
 |
118
tuuuz 2015-12-07 16:59:30 +08:00
how old are you （怎么老是你）
|
 |
119
doublleft 2015-12-07 17:10:31 +08:00
我遇到有这种方案说英文单词的同事，很多类似 issue, bug 都硬生生翻译。
比如刚刚听到的：开发环境有一个故障，我给你提了个问题。 故障和缺陷和问题，傻傻分不清。 相反， bug 就很好理解是缺陷 |
 |
120
palmers 2015-12-07 18:37:27 +08:00
我觉得分别对什么人群了 你不能说对一个没有计算机基础的人说 check 或者 commit 我认为这确是装
但是对圈内人 这样说确实省力，且不容易产生歧义，不会出现我说的和别人理解的不一致。 |
 |
121
killerv 2015-12-07 23:42:36 +08:00
都是程序员，说的都是大家都习以为常的话，装逼给谁看？
|
 |
122
hzlzh 2015-12-08 00:38:38 +08:00
「你 pull 一下，然后发 PR 给我，之后我合并就好」
|
Select Language