“代码命名时，一致大于正确”
本文适合以下小伙伴阅读：
- 经常会有疑惑：这谁的单词拼错了，我之后要将错就错吗？
- 时常感觉到：项目中的命名好乱啊，明明是一个东西怎么一堆不同的名字
好了，正文开始！
现实中的问题
一线编写代码时，相信大家都遇到过命名或概念不一致的问题，明明是同一个东西，却在不同的地方命名不一致，导致修改起来非常麻烦，且很容易漏掉修改点。
遇到此情况时一般都会影响开发工期，有时自己消化的掉，但有苦说不出；有时消化不掉了，就会使项目延期发布。它也会隐藏的增加项目风险（由于认知成本升高），增加项目成本。
那出现这种命名不一致的情况到底要怎么办呢？
这里提供两个方法：优雅的方法和必须做抉择时的策略
优雅的方法：一致性文档
如果项目还没开始，或者当前项目有足够的灵活性可以支撑一定的开发流程的调整，那建议使用一致性文档方案。
这个方案不是在正确和一致之间选择，是全都要。既要一致，又要正确。所以比较推荐。
但相对的，会多付出一些不算大的成本，用来保证既正确与一致。
看图聊聊：什么是一致性文档
一个内部有两个概念的系统，应该是这样的：
此时系统中只有两个概念，独立清晰
但实际上，由于系统中使用概念的次数很多，所以实际可能是这样：
图中，系统有两个概念，但相同的概念出现了很多次，就像一个命名可能会用在很多地方一样。
这样也是健康的，因为系统中的概念虽然分散，但概念仍然统一。
后面讲对此的优化，这里先略过
但如果此时对应了多个开发人员，就可能出现偏差：
此图表示开发者对概念的加工，具体点可以理解为对某事物的命名
图中所示，对同一个概念（虚线框中的元素），两个开发者对其理解和映射不一致，导致概念一致性出现问题。比较直观的表现是命名的不一致。
那在这种情形下，系统的内部命名就像这样：
途中可以看的出来，系统中虽然还是两个概念，但系统内部的命名已经很混乱了。而且，图中才以两个开发者为例。开发者越多，这种情况越明显。
那如何解决这个问题呢？
其实有些读者已经想到了，只要去掉上边那个导致错误的步骤就好了。
就是：不要让开发者自己加工概念
可以团队讨论，可以负责人决定，也可以架构师定，但不要让每个开发者自己加工概念。
图中表示以团队为单位，对概念进行加工（命名）。
产出物为文档，此文档团队内共享。
使用此文档做约束后，系统内的命名情况就像这样：
虽然引用没有减少，但概念在系统中出现的形式统一了。
这样一来，系统就整洁多了。而且这文档也确实起到了意义（而不是摆设）。
而且，这个文档不光能规范命名，也作为团队内对齐概念、业务名词等的工具。总之，概念不一致相关的问题都可以用这个一致性文档解决试试。
一致性文档示例（仅以命名为例）
通过前期的需求分析和设计（初步可参考：需求和建模），应该有一定的业务概念出现了。
然后建立相应的映射，分发给团队的开发人员参考。
不用太复杂，表格形式就可以。
这里以需求和建模中贪吃蛇小游戏的概念为例：
- 名词：蛇、墙、蛇身、蛇头、食物、方向
- 动词：移动、碰、吃、变长、死
| 概念 | 英文映射 |
|---|---|
| 蛇 | snake |
| 墙 | wall |
| 身体 | body |
| 头 | head |
| 食物 | food |
| 方向 | direction |
| 移动 | move |
| 碰 | bump |
| 吃 | eat |
| 变长 | grow |
| 死 | die |
这样开发时就会减少很多的不一致，后边维护会舒服很多。
而且，因为统一了概念并文档化了，无论是内部沟通还是外部沟通，都可以减少歧义，增加沟通效率。
必须做抉择时的策略：一致大于正确
一致大于正确，说白了就是将错就错。
下面来聊聊为什么要“错”的决策更“对”。
下面从一个示例图说起：
图中黑圆代表错误命名，白圆代表正确命名。
现在，假设一个系统已经有了4个错误命名：
让我们看看发现错误命名后的不同操作对比：
左图表示使用正确命名的操作后的系统概况。
右图表示使用相同的错误名称后的系统概况。
看起来挺明显的，如果以系统的复杂程度来考量，明显右侧的系统复杂程度更低。
最起码它是一致的，就更容易理解。
简单来说：错虽然错，但最起码统一了，两样占一样了。
如果改成对的命名，系统中的概念更多了，得不偿失。
而且，其实对于软件开发来说，同样的错误其实很容易改，既可以搜索，又可以借助开发工具的联动修改功能，其实后面也很容易调整的。
上图为使用正确的命名统一替换掉所有错误命名的示意图。
所以，如果非得从正确和一致上选，那一致更重要。
总结
项目中出现命名不一致的时候，可以使用一致性文档来解决问题。如果一时之间做不到，那就优先保证名称的一致性，后续可以统一调整。
内容还感兴趣吗？公众号中会有更多相关内容持续更新哦
