一致 VS 正确

“代码命名时，一致大于正确”

本文适合以下小伙伴阅读：

• 经常会有疑惑：这谁的单词拼错了，我之后要将错就错吗？
• 时常感觉到：项目中的命名好乱啊，明明是一个东西怎么一堆不同的名字

好了，正文开始！

现实中的问题

一线编写代码时，相信大家都遇到过命名或概念不一致的问题，明明是同一个东西，却在不同的地方命名不一致，导致修改起来非常麻烦，且很容易漏掉修改点。

遇到此情况时一般都会影响开发工期，有时自己消化的掉，但有苦说不出；有时消化不掉了，就会使项目延期发布。它也会隐藏的增加项目风险（由于认知成本升高），增加项目成本。

那出现这种命名不一致的情况到底要怎么办呢？

这里提供两个方法：优雅的方法和必须做抉择时的策略

优雅的方法：一致性文档

如果项目还没开始，或者当前项目有足够的灵活性可以支撑一定的开发流程的调整，那建议使用一致性文档方案。

这个方案不是在正确和一致之间选择，是全都要。既要一致，又要正确。所以比较推荐。

但相对的，会多付出一些不算大的成本，用来保证既正确与一致。

看图聊聊：什么是一致性文档

一个内部有两个概念的系统，应该是这样的：
此时系统中只有两个概念，独立清晰

但实际上，由于系统中使用概念的次数很多，所以实际可能是这样：

图中，系统有两个概念，但相同的概念出现了很多次，就像一个命名可能会用在很多地方一样。

这样也是健康的，因为系统中的概念虽然分散，但概念仍然统一。

后面讲对此的优化，这里先略过

但如果此时对应了多个开发人员，就可能出现偏差：

此图表示开发者对概念的加工，具体点可以理解为对某事物的命名

图中所示，对同一个概念（虚线框中的元素），两个开发者对其理解和映射不一致，导致概念一致性出现问题。比较直观的表现是命名的不一致。

那在这种情形下，系统的内部命名就像这样：

途中可以看的出来，系统中虽然还是两个概念，但系统内部的命名已经很混乱了。而且，图中才以两个开发者为例。开发者越多，这种情况越明显。

那如何解决这个问题呢？

其实有些读者已经想到了，只要去掉上边那个导致错误的步骤就好了。

就是：不要让开发者自己加工概念

可以团队讨论，可以负责人决定，也可以架构师定，但不要让每个开发者自己加工概念。

图中表示以团队为单位，对概念进行加工（命名）。

产出物为文档，此文档团队内共享。

使用此文档做约束后，系统内的命名情况就像这样：

虽然引用没有减少，但概念在系统中出现的形式统一了。

这样一来，系统就整洁多了。而且这文档也确实起到了意义（而不是摆设）。

而且，这个文档不光能规范命名，也作为团队内对齐概念、业务名词等的工具。总之，概念不一致相关的问题都可以用这个一致性文档解决试试。

一致性文档示例（仅以命名为例）

通过前期的需求分析和设计（初步可参考：需求和建模），应该有一定的业务概念出现了。

然后建立相应的映射，分发给团队的开发人员参考。

不用太复杂，表格形式就可以。

这里以需求和建模中贪吃蛇小游戏的概念为例：

• 名词：蛇、墙、蛇身、蛇头、食物、方向
• 动词：移动、碰、吃、变长、死

概念	英文映射
蛇	snake
墙	wall
身体	body
头	head
食物	food
方向	direction
移动	move
碰	bump
吃	eat
变长	grow
死	die

这样开发时就会减少很多的不一致，后边维护会舒服很多。

而且，因为统一了概念并文档化了，无论是内部沟通还是外部沟通，都可以减少歧义，增加沟通效率。

必须做抉择时的策略：一致大于正确

一致大于正确，说白了就是将错就错。

下面来聊聊为什么要“错”的决策更“对”。

下面从一个示例图说起：

图中黑圆代表错误命名，白圆代表正确命名。

现在，假设一个系统已经有了4个错误命名：

让我们看看发现错误命名后的不同操作对比：

左图表示使用正确命名的操作后的系统概况。
右图表示使用相同的错误名称后的系统概况。

看起来挺明显的，如果以系统的复杂程度来考量，明显右侧的系统复杂程度更低。

最起码它是一致的，就更容易理解。

简单来说：错虽然错，但最起码统一了，两样占一样了。

如果改成对的命名，系统中的概念更多了，得不偿失。

而且，其实对于软件开发来说，同样的错误其实很容易改，既可以搜索，又可以借助开发工具的联动修改功能，其实后面也很容易调整的。

上图为使用正确的命名统一替换掉所有错误命名的示意图。

所以，如果非得从正确和一致上选，那一致更重要。

总结

项目中出现命名不一致的时候，可以使用一致性文档来解决问题。如果一时之间做不到，那就优先保证名称的一致性，后续可以统一调整。

内容还感兴趣吗？公众号中会有更多相关内容持续更新哦