为何英雄难过命名关？

Martin Fowler在他的博文中提到一句话：

There are only two hard things in Computer Science: cache invalidation and naming things.

-- Phil Karlton

老马并表示：“很久以来，我一直很喜欢这句话。一个典型的现象是：我找不到一个令人满意的URL”。

看起来小小的命名真的不小，软件先辈也对其非常关注。

2016年，我在Eums项目上，三个Tech Lead的同事（很资深的老程序员，82，83，85）跟我一起Review了一个方法的命名，花了10多分钟，最终觉得不是最完美的。足以说明，命名真的很难。

程序员小白会说：“那么纠结干嘛！起一个差不多的名字不就得了，程序又不是不能运行” 就是这一个差不多，让代码的维护成本呈指数级增长。那为什么，很多时候起一个好名字这么难呢？

如果定义一个好名字？我觉得好名字很容易定义 -- 在当前业务上下文中，准确表达业务含义的名字，使用通用的业务语言描述。从这个维度出发，越精确接近业务概念，这个名字就越好。

那为什么很多小白写出的代码，别人就是不能直接看懂呢？从两大方面都可以找出一些原因。

业务理解上：

1. 自身对业务本身缺乏理解。
2. 自身对业务理解了，但沟通过程未确认统一语言。

软件建模上：

1. 干了两件事情，不知道以谁的业务为准。
2. 做的事情太通用，名字没法赋予业务含义。
3. 随意的编码习惯，引入没必要的简写。
4. 对领域专有名词翻译成英文后，选词不一致。

在业务理解上，没有什么捷径可走：

1. 首先要充分理解业务，这是软件交付的基础。
2. 切记不要因为疲于沟通，自己就随意脑补概念。
3. 通过沟通确认在团队中跟业务方形成一致理解。
4. 对一些特有的专业术语，形成一套固定的术语表供团队参考。

在软件建模上，当遇到不好命名的时候，多半是因为做的事情太多了，或者过度追求通用性，而导致代码无法赋予确定的含义，遇到这种情况，思考代码是不是做的事情不单一，进行分析和分解。

对于一些简写习惯，也要确保每个人理解一致的前提下才这么做，如果业务上没有使用简写，代码也不要选择简写。另外，不到迫不得已，不建议用拼音命名。对于一些非专有术语，尽量用一些简单常用的，比如find就比retrieve好。实在词汇量匮乏，备一个汉英词典。

以上如果只通过自己一个人来预防，难免会有不自知的问题。在敏捷交付项目中，充分发挥个体交互，让反馈机制运转起来。像结对编程、Code Review，Story Kick-Off这些环节都是能够为我们的建模提供有益输入的，非常值得在项目中去实践。