为什么程序员动不动拽英文单词不是装 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 里也有,意味着所有移动客户端都要改,还要照顾那些不升级的老客户端;可是不改,就要想一个新名字,可这个不准确的新名字一方面用来别扭,另一方面还可能造成未来同样麻烦。

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

我们曾经拿托福阅读题给公司里所有员工都做过一次测试,工程师的平均成绩和大部分是英语专业毕业的内容编辑团队是一样的,还有几个满分。
13207 次点击
所在节点    程序员
122 条回复
20015jjw
2015-12-07 01:38:00 +08:00
并不装逼啊... DFS 和 SCC 难道还要深度优先搜索和强力连接组件么 hhhhh
cheka
2015-12-07 01:38:13 +08:00
@Elethom 我们内部用 GitLab ,和 Github 一样, issue 实际上翻译成工单更合适。
6IbA2bj5ip3tK49j
2015-12-07 01:39:31 +08:00
@LioMore
「代码我已经提交了,等下一个工单改好我就推送到主分支」
我中文一般是这么说的。
不知道你英语怎么说。
cuebyte
2015-12-07 01:39:37 +08:00
不明白不使用英文是如何产生优越感的,楼上诸位把常用单词翻译了就觉得自己胸前的红领巾更鲜艳了吗吗?这样的话不如写个插件汉化 github 好了。

对了,在交流超文本标记语言,层叠样式表,爪哇脚本,蟒蛇,红宝石,超文本预处理器(拍黄片)的时候,各种关键字也请替换上中文,比如循环,如果 /否则,开关 /情况。
cheka
2015-12-07 01:39:57 +08:00
@crisfun 奇怪,好端端说个方法学问题,怎么开始诛心“假装团队外语比母语好了”,我就是说下我们公司是这么做的,你觉得是瞎胡闹也罢,我也不争辩了。
binux
2015-12-07 01:45:18 +08:00
在特指的时候用英文并没有什么问题,比如 git 在说 push 和 pull 的时候(更常见的如 rebase ),特指这个操作。和「更新一下」做出区别,毕竟 pull 不完全等同更新。
再例如提 issue 特指在问题,任务追踪系统中提交一条记录。如果对方并不打算帮你提这个记录,一般说「我报个 bug 」;而说「我提个 bug 」,如果对方是 QA ,可能会帮你提记录,如果是 RD ,对方的意思一定是「我就提一下」,所以这时候会说,「记得帮我提个 issue 啊」来表示特指。

在特指的时候用英文并没有什么问题;但是「 check 」和「我查一下」有什么区别?「 fix 」和「修复」有什么区别?
crisfun
2015-12-07 01:46:36 +08:00
@cheka 是,你觉得瞎胡闹也就算了,我也不想和人争论。我说那些更多目的是想看看有没有比较高水平的人来发表意见。

别人抛砖引玉可能还加下说自己诚惶诚恐,我可能懒得说。
arbipher
2015-12-07 01:47:43 +08:00
Zipf 定律,涨姿势了
clearc
2015-12-07 02:07:21 +08:00
@cuebyte 他们只是觉得用英文的在秀优越感而需要强行扳回一城,我之前这里曾发过咨询帖,里面提到 salesforce 的 workflow ,下面都有人跳出来问我为什么中英文夹杂...只能说没有在国外长期生活或者在外文环境下长期工作的无法理解吧..语言是用来交流的,最直接交流就是想到什么说什么,例如“ defect ”,之前国外的 QC 都是英文,即便和中国人交流也是“这个 defect ”如何如何,后来回国用中文的 QC ,他们习惯用“缺陷”,我反而不适应了挺久..(然而维护母语纯洁性却从没有类似经历的他们,应该不会去用这样二元的思维考虑的...)
crisfun
2015-12-07 02:11:07 +08:00
喝口水洗漱回来。

我真正表达的是主客问题。

汉语是主,英语是客,那么就用英语来扩充,能用中文就用中文,这样不论理解还是选词造句速度与准确度都有保证。

但是,偏偏,现在有的人是迫不及待要显示自己那点蹩脚英语。

结果 ,英语是主,汉语是客。这样的时候,不论是理解的速度还是书写的速度,不要说准确性,都反而没了保证。

不信看看楼主自己举的本来想说只要英语好,那么英文妙的例子。这样的蹩脚命名问题,冲突命名问题,他们这些外语人士应该还会遇到的。
SharkIng
2015-12-07 02:11:15 +08:00
因为你写代码的时候需要用英文啊。你总不能把 IF 写成 如果( ruguo i = 1 )吧?

所以有的时候和国际接轨一些词语没什么奇怪的啊。比如 Bug 。我把这个 Bug 修复一下,你难道非要说我把这个错误修复一下?而且这种简单词汇谁都懂,甚至不会英语的人都知道 bug 是什么..
miyuki
2015-12-07 02:11:55 +08:00
读作 “我代码已经提了”,写作 “ git commit ”

个人比较不喜与人交流用 “我去 check 一下”,“我已经 fix 了”
MrGba2z
2015-12-07 02:13:23 +08:00
issue 是问题更合适

我同事经常说 there is an issue in this code 。 i'v created a ticket for that 。难道 issue 翻译成工单?工单对应的是 ticket
linhua
2015-12-07 02:16:22 +08:00
@arbipher
"Zipf 将此称为最省力原则(Principle of least effort)"
乍一看来感觉好熟悉,原来和“最小作用量原理”差不多。
比较一下
最小作用量原理:(源自刘连寿 《理论物理基础教程》)
一个物理系统实际发生的真实运动状态是所对应的作用量具有最小值的那个状态。
cxbig
2015-12-07 02:22:23 +08:00
行业内,这些“黑话”用与不用都没有什么问题。
行业外,中英混杂容易让人无法理解。但硬要扣装 13 的帽子也是不妥。
myang
2015-12-07 02:52:01 +08:00
在你的例句里, issue 和 commit 本来就是有所指代的专有名词,用英文替代还算合理;但 check 、 fix 等在这里完全就是普通单词,对应的中文根本不难说,还要故意夹杂的,基本可以肯定是英文水平并不高的人在装 b 。例如如果我是某杂志领导,说了这么一句:“小王啊咱下个月 issue 的 feature 就由你负责了”,这里面几个词在语境中都是普通单词,要这么夹杂就是典型的装 b 。
Khlieb
2015-12-07 03:11:06 +08:00
@rwalle 这种话题有可能是些有组织有纪律的人发起的。
PublicID
2015-12-07 04:17:18 +08:00
对啊对啊,如果能把 bug 翻译成 feature 就更好了
lovewilliam
2015-12-07 04:23:39 +08:00
nope
fengxiang
2015-12-07 05:04:29 +08:00
把 app 读 a p p 还真觉得和国际接轨也是醉了。

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

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

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

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

© 2021 V2EX