为什么程序员动不动拽英文单词不是装 B

2015-12-07 00:42:02 +08:00
 cheka
看到我厂另一位同事写的“为什么程序员英文要好” 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 里也有,意味着所有移动客户端都要改,还要照顾那些不升级的老客户端;可是不改,就要想一个新名字,可这个不准确的新名字一方面用来别扭,另一方面还可能造成未来同样麻烦。

总体来说,扇贝对工程师的英文水平要求是很严格的,甚至扇贝程序中所有文字,实际上是先写成英文,再翻译成中文。虽然一开始有人觉得浪费时间,但是逐渐大家还是接受了,好处是从工单描述,到变量,再到注释,都能尽可能维持一致性。

我们曾经拿托福阅读题给公司里所有员工都做过一次测试,工程师的平均成绩和大部分是英语专业毕业的内容编辑团队是一样的,还有几个满分。
12755 次点击
所在节点    程序员
122 条回复
ffffwh
2015-12-07 00:47:12 +08:00
“小 x 啊,下次变基了再提交代码”
Delbert
2015-12-07 00:47:30 +08:00
总体来说,扇贝对工程师的英文水平要求是很严格的,甚至扇贝程序中所有文字,实际上是先写成英文,再翻译成中文。

唔,长叹……
binux
2015-12-07 00:53:26 +08:00
> “好,我 check 下。”

"我们中文" 一般说,「好,我查下」

> “这个 bug 我 fix 了,代码已经 commit 。”

"我们中文" 一般说,「这个 bug 我修了,代码已经提了」

> 再看 check, fix ,还有 App ,在中文里是有相对明确的对应词汇的,分别是“检查”,“修复”,还有“应用”。实际上我们也确实有时候会用对应的中文词,但是用英文更多,为什么呢?因为这几个英文词念起来更省力啊。

"我们中文" 不知道是不是比你们更省力呢?
crisfun
2015-12-07 00:58:57 +08:00
那么你要不要打算说下中国人写的主要面向中国开发人员,而且特别面向中国用户的程序从一开始到最终界面都用英文的合理性?


贵司既然这么能折腾工程师团队,请问对解决几百年都没改变的 Bug 有过帮助吗,对用户学好英语有比工程师中文更多优势吗?
cheka
2015-12-07 00:59:26 +08:00
@binux 你怎么说 git 里的 push 和 pull 呢,推和拉吗?

还是那句话,并非说中文无法表达,而是很多概念在中文有一致的翻译之前就已经得到应用,大家约定俗成的用英文了,这时候用中文翻译反而可能造成沟通不畅。你说拉代码,那我平常说拽代码怎么办?而用 pull 都明白。
d7101120120
2015-12-07 01:00:06 +08:00
像是 bug 找不到合适的中文词翻译,亦或者是在特定环境下的英文,如果说连普通的名词动词都要用英文表达,还真的不如直接使用全英文。

当然我也只是说说,实际怎么使用还是个人自由。
crisfun
2015-12-07 01:04:32 +08:00
@cheka 奇怪了, 你就确定你当真能因为以前的英文明白 git 里面的 push pull ?
还不是只有在额外的说明以后才能理解这里的指代。

那么问题来了,请你们摸着良心

你们理解 push pull 时候有用过它的对应中文意义与中文意义对应的“理解“给你的知觉吗?

既然英文都能额外解释理解 push pull 的意义,中文怎么就不行?

再说,你们是传说中的小团队,你打算因为一个词你们不能主导全球中文对它的翻译,就以为自己不能使用翻译的词汇。
binux
2015-12-07 01:06:43 +08:00
@cheka 「我代码更新了」「你更新下」,"我们中文" 没有那么弱。。
LioMore
2015-12-07 01:06:57 +08:00
「代码我已经通过分布式版本管理工具提交了,等做好下一个工单改好我就推送到主分支」
如果有人这么和我说话,我真的会觉得他在装逼
lincanbin
2015-12-07 01:09:04 +08:00
如果你身边有人这么说,总的来说,是你的朋友圈子出了问题,应该反思自己。
crisfun
2015-12-07 01:17:00 +08:00
其实我差点想说,你们用中文写变量名不就完了,你自己都描述你们是取的 英文变量名 check in ,结果另外一个东西,在中文里面倒是很大的区别,偏偏英文上又要和 checkin 重合。

那么你就干脆用中文,好认又好记,不会存在这不应该存在的问题。
cheka
2015-12-07 01:17:48 +08:00
@crisfun 我再强调一遍,没有任何贬低中文表达能力的意思,这个例子是说 git 在工程界大范围使用的时候,很多术语在中文里还没有一致的翻译,相关的中文书籍很可能有不同的翻法,导致对应读者脑子里就有不同的中文说法,这时候用中文就可能造成误解(把中文换乘其他语言也一样),而直接用英文术语就可以避免这个问题。
loratadine
2015-12-07 01:19:53 +08:00
轮完 4A 腔又来轮程序员了,下一个行业是什么?
BROWNURSIDAE
2015-12-07 01:20:46 +08:00
@crisfun 因为他们要面向世界编程
crisfun
2015-12-07 01:22:48 +08:00
@cheka 你说的 git 体系里面的词汇,即便可以说, git 这东西真奇怪不好翻译,那么其他词汇呢。
第二来说,我也再说,你们不需要其他人明白,你们自己明白就行。 你不需要全球一致的翻译。
再额外来说,你以为大家的翻译会差异非常大,结果多数词汇翻译的差异都不会那么大。
crisfun
2015-12-07 01:26:00 +08:00
@BROWNURSIDAE 那确实是,假装自己团队有外国人,假装团队都是英语大拿用外语比用母语好,假装自己很在意用户感受。
vivianalive
2015-12-07 01:29:57 +08:00
在国外似乎么这个问题,能把 push 说成推是件很有趣的事情。
rwalle
2015-12-07 01:31:20 +08:00
为什么总见到这种无聊的话题。。。
Elethom
2015-12-07 01:32:52 +08:00
「工單」是「 ticket 」,「 issue 」是「問題」。我讀書少你別騙我。
就這英語水平還是閉嘴吧。
d8
2015-12-07 01:36:16 +08:00
软文真的不错

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/241604

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX