程序员和软件开发者在给他们的工具命名时失去了方向
程序员和软件开发者在给自己的工具起名这件事上，似乎有点跑偏了。
2022年12月，我看了理查德·斯托曼（Richard Stallman）在EmacsConf上的一场演讲，标题是《我希望Emacs能有什么》。他在演讲中提到了一个很有意思的观点——“好记的名字”。他说：“我觉得每个你写的扩展包都应该有个容易记住的名字，让人一看就知道它是干什么的。但我们有种倾向，就是为了玩文字游戏或者取个听起来没什么特别含义的名字。” 斯托尔曼在2022年还要专门强调这点，其实已经说明了我们在命名这件事上已经偏离得有多远，哪怕是在Emacs这样一个以命名清晰著称的生态里（比如dired表示目录编辑器，eshell表示Emacs里的shell）。
如今软件开发圈子里有种奇怪的现象：大家都觉得用些莫名其妙的名词、神话人物、甚至自己喜欢的虚构角色来给项目命名，是一件很正常的事。但在其他几乎所有技术领域，这么做都可能会断送你的职业生涯。
最近我就深有体会。朋友跟我讲她们团队的技术架构时，我听得一头雾水。她说：“我们用Viper做配置管理，然后交给Cobra处理命令行界面，接着Melody负责WebSocket连接，Casbin管权限控制，最后通过Asynq来做任务队列。” 这里面除了最后一个名字稍微透露点功能信息之外，其他的我都得靠猜。我一边听一边上网查这些名字到底是什么意思，那一刻突然意识到一个问题：在别的行业里，从来不需要这么费劲。金门大桥一听就知道它跨越的是金门海峡；胡佛大坝就是一座大坝，名字来源于下令修建它的总统，而不是什么"雷霆瀑布计划"或"AquaHold"之类的代号；工字钢之所以叫工字钢，是因为它的截面像个"工"字；就算工程师们偶尔发挥创意，也是有逻辑的，比如蝶阀看起来真的像蝴蝶翅膀一样。名字和实物之间有直接联系，而且容易记住。你写过一百个命令行工具，也不会碰巧遇到一个叫"眼镜蛇"的。
其他领域同样如此。比如化学工程，那里的命名规则更加严格。根据国际纯粹与应用化学联合会（IUPAC）的规定，“2,2,4-三甲基戊烷"就只能指代一种特定的分子。没人会突发奇想地给它起名叫"史蒂夫”，仅仅因为觉得这个名字有趣或者能让论文显得更亲民。
# 其实以前不是这样的（我相信）
我对软件发展史略有研究，虽然不敢说历史上曾出现过一个完美的命名黄金时代（即便是顶尖工程师也曾犯过低级错误），但至少上世纪八十年代的时候，大家还是尽量让名字有点意义的。比如grep（global regular expression print，全局正则表达式打印）、awk（三位创始人的姓氏首字母组合：Aho、Weinberger、Kernighan）、sed（stream editor，流式文本编辑器）、cat（concatenate，拼接）、diff（difference，差异对比）。即便这些名字被缩写了，也能一眼看出它们的功能描述或是系统的衍生方式。没人会给拷贝命令起名叫"闪光"，也不会把移动命令叫做"耳语"。
早期的编程语言也遵循类似的原则：FORTRAN（Formula Translation，公式翻译）、COBOL（Common Business-Oriented Language，通用商业导向语言）、BASIC（Beginner’s All-purpose Symbolic Instruction Code，初学者通用符号指令代码）、SQL（Structured Query Language，结构化查询语言），还有Lisp（List Processing，列表处理）。这些名字都很清楚地表达了它们的设计初衷。大概是从2010年开始，一股"命名病毒"悄悄蔓延开来。也许是开发者厌倦了死板的企业风格命名，想要在开源项目中加入一点个人色彩？也许是吧。起初一些略显调皮的名字还挺讨喜的。比如MongoDB（源自"巨大"这个词），虽然简化成了"Mongo"，但至少还能看出跟数据存储有关。
可后来事情就越走越远了。我们现在面对的是一个充满各种毫无关联名字的世界，名字和功能之间的联系早已荡然无存。这或许与GitHub和初创公司文化的崛起有关。人人都想成为下一个Google那样的传奇品牌——一个原本毫无意义但却凭借强大的市场影响力变得家喻户晓的名字。Google可以用巨额广告支出和成为动词的能力建立起品牌认知，但你那个MIT许可证下只有45颗星星的小型文件解析器显然不具备这种条件。
# 给大脑增加负担
每一个拗口的名字，都是对每一位接触该项目的开发者施加的一种隐形成本。当你看到"libsodium"这个名字时，你会不由自主地从解决问题的状态切换到破案状态：“这是干嘛的？让我看看文档……哦，是个加密库。为啥叫钠？因为化学元素？因为氯化钠NaCl？嗯，还挺巧妙的。” 可问题是，现代项目往往依赖几十上百个第三方组件，每个都需要你花时间去理解和记忆。这些看似微不足道的时间积累起来，就会变成巨大的认知负担。
试想你在向新人讲解项目的整体架构和关键依赖时的情景。假设你朋友又说了那句经典台词：“我们用Viper做配置管理，然后交给Cobra处理命令行界面，接着Melody负责WebSocket连接，Casbin管权限控制，最后通过Asynq来做任务队列。”
现在请你认真读一遍这句话。你会发现里面有一条蛇（Viper）、另一条蛇（Cobra）、一段旋律（Melody）、一个听起来像是人名的东西（Casbin），还有一个怪怪的名字（Asynq）。你一半的大脑容量都要用来把这些奇怪的名字和具体功能一一对应起来，根本没法专心思考真正的架构设计。这就好比一位心脏科医生对你说：“我们要给你装个’蝴蝶’来改善你的’耳语心跳’”，而不是直白地说：“我们要在你的血管里放个支架来提升血液循环效率。” 再举个例子，在材料科学论文中，当你读到"高熵合金"或"形状记忆聚合物"这类术语时，光看名字你就大致明白它们的特点和用途了，根本不用等作者进一步解释。
# 听过的几种辩解
之前我和别人聊起这个问题时，听到不少反驳意见，下面是我对其中一些说法的看法：
“好记的名字有利于推广！”
这话倒也没错，前提是你要卖的是面向大众的产品。但你写的HTTP客户端、CLI辅助工具或者其他各种库，并不属于消费品范畴。真正关心这些东西的人只想知道它能做什么。
“太直白的名字多没劲啊！”
没错，手术刀也很无聊。但如果清晰更重要，那么无聊也没什么不好。毕竟这不是文学创作课。
“我只是图个乐呵而已！”
你的快乐给别人带来了麻烦。每次有人接触到你所谓的"有趣名字"，都要额外付出一点点精力去理解。在整个行业内，这些小小的代价加在一起，会造成相当大的资源浪费。我知道，这个问题也许算不上当前业界最紧迫的事情，但我还是忍不住要说出来。
“所有直观又好听的名字早被人注册完了！”
我们可以采用命名空间、前缀或者复合词汇等方式，就像其他工程技术领域几百年来一直在做的那样。我们有这样的能力。退一步讲，就算实在做不到这一点，至少也要让名字和产品本身沾点边，比如加上"DB"后缀，或者学学"magit"那样玩点文字游戏。如果不能做到一目了然，至少让它贴近现实也好。
# 往前走的方向
这一切的发生并非出于恶意，而是文化和环境变化的结果。随着编程逐渐从大型企业的封闭体系转向开放社区共建的时代，相应的社交习惯也在悄然转变。这当然是件好事。
所以我们需要一场文化层面的纠偏运动。不是要设立规章制度（毕竟开源精神的核心在于自由），而是要在社群内部重新树立起专业的标准，借助舆论力量和教育培训来推动进步。
请给你的库起一个能够体现其功能的名字。善用复合词组。如果必要的话，宁可啰嗦一点也没关系。"http-request-validator"永远比"zephyr"更适合深夜排查线上故障时快速识别依赖项的场景。
如果你实在很想找个可爱的吉祥物或者引用某个典故，没问题——把它当作项目的形象大使就行，千万别拿来做正式名称。PostgreSQL就有那只叫Slonik的大象作为吉祥物，但它依然叫PostgreSQL。大象的形象并没有替代名字本身的含义。
把那些富有想象力的名字留给那些品牌形象至关重要的终端用户产品吧。至于底层基础设施、开发工具和各类函数库，请优先考虑清晰易懂。每一次都坚持这么做。
下次你想把自己最爱的动漫角色拿来当项目名时，请先停顿一秒。问问你自己：“如果是土木工程师，他们会这样给桥梁支撑系统命名吗？” 如果答案是否定的，那就换个更好的名字吧。
我们的行业应该有更好的命名规范，而不是一群乱七八糟的名词堆砌而成的动物园。清晰不仅不无聊，更是对使用者时间和心智资源的基本尊重。