当最终用户的命名法改变时，我们应该在多大程度上重命名代码和数据？

很久以前，我们添加了一项功能，使用户在将图像添加到工作流队列后可以“接受”图像。原来，我们使用了错误的术语，并且用户实际上“批准”了该图像。

在我们的界面上更改“接受接受”很容易，只需替换一个单词即可。但是，我们从CSS类名称到数据库值都使用“ accept”一词对所有层进行了编程。

• 使按钮变为绿色的CSS类：“ .accepted”;
• 验证并绑定DOM节点上的类属性的模型方法：“ isAccepted”;
• JavaScript状态属性：具有“未审阅”，“已接受”和“已发布”的数组；
• Mysql状态列：ENUM，具有“未审阅”，“已接受”和“已发布”；
• 测试名称；

替换大多数出现的接受批准很简单（特别是在进行测试时）。迁移数据要困难一点，特别是因为它需要与部署同步。

这个特定的案例很简单，但是在我的职业生涯中，我遇到过类似但更复杂的案例。当文件也被重命名并且在数十台服务器上进行部署时，或者当代理缓存时，将涉及memcached和mysql。

除了接口之外，在所有其他层上都保留“接受”是一个坏主意，因为加入该团队的新程序员可能无法了解导致该决定的历史原因，并且如果接受->赞成，则在含义上是相近的词语被重命名为“排队参加管理层下次地位会议”，这当然没有任何意义。而且，如果我们在这里和那里折衷，就会感觉到，在一些迭代中，用户界面的概念不会影响系统内部，并且我当然不希望在其中一半输出与其内部没有关系的系统上工作。

那么，您是否总是在需要时重命名所有内容？如果这发生在您身上，并且您认为这种权衡不值得，那是不是又回来咬了您？代码注释或开发人员文档是否足以避免此问题？

对我来说，绝对最好更改与该商品相关的所有内容。

这是一种代码降级的形式，虽然一项没有更改可能没什么大不了的，但它为代码库设置了基调。

这也可能导致将来的混乱，并使新开发人员更难理解代码库/域。

从问题的内容和标签中，我将假设您使用的是普遍存在的语言。

以我的经验，UL很棒，但是正如您提到的，随着语言的发展，UL可能会导致其他维护任务。这本身并不是一件坏事。当然，这很不方便，但也是可以预期的。

我通常做的（或者看做的）是：

• 一键式重构：重构应用程序的所有层以采用更新的语言；要么
• 记录技术债务：您可以立即更改面向用户的代码，然后记录技术债务任务，以使其余应用程序层与更新的语言保持一致。这通常会导致一些无聊（但可管理）的任务。（下午5点完美！）

我认为这里的关键是，您所描述的是技术债务，应该这样承认。

我曾经遇到过一些经理，他们争辩说我们不应该在没有添加任何可见功能的琐碎任务上浪费时间。这就是债务类比真正派上用场的时候。归结为：

团队选择使用通用语言进行DDD。通过使代码处于不一致状态来摆脱这种方法，会增加混乱并消除DDD和UL提供的许多好处。用经理的话来说，这增加了项目成本。该代码变得更加难以管理（昂贵），并且使新开发人员更加困惑（昂贵）。

您可能需要研究Localization（l10n）选项。尽管从英语到西班牙语看起来似乎并不那么激烈，但是您要针对同一概念使用不同的术语。如果这似乎经常发生，那么使用l10n可以使您快速更改用户界面中显示的内容，而不必更改代码中使用的术语。

设置好之后，只需使用代码中最容易理解的术语即可。如开发人员所知并可能期望从域中选择名称。

正如您恰当地描述的那样，跟踪源的每个部分中的最终用户命名更改都是一项巨大的投资。但是绝对值得，特别是对于由完整的基础结构（带有热线，测试器等）开发的长寿命产品而言

跟踪源中的最终用户命名法是一项投资，因为它会出现很多组件类型，并且没有魔杖在所有这些组件上同时工作。也许逐个组件地开发这样的魔术棒是一项有趣的投资，您可以在项目的整个生命周期中对其进行稀释。

我使用了30年的代码库，其中最终用户命名法和内部命名法之间的偏差变得特别大。以下是这种情况的一些缺点，所有这些缺点都增加了每个人的工作负担：

1. 在缺乏适当政策的情况下，新的开发趋向于使用当前的最终用户命名法。因此，同一概念在不同的组件中可能具有两个或多个名称。由于这些组件相互作用在一起，因此会在代码的某些本地部分中模拟存在多个同义名称。

2. 致电热线/服务台时，他们会使用最终用户命名法写下用户故事。负责解决问题的开发人员必须翻译最终用户的术语，以与源术语匹配。当然它没有被存档，当然是一团糟。（请参阅1.）

3. 当程序员调试代码时，她想在相关功能中设置断点。如果最终用户命名法和源命名法不一致，则很难找到合适的功能。甚至很难甚至不可能确信相关功能的清单是完整的。（请参阅1.）

4. 如果没有适当的政策，使用过时的术语对源进行维护将不时将这种过时的术语再次摆在用户面前。这会产生较差的印象并导致开销。

我已经跟踪了整整两天，即从数据库中读取一些数据并将其注入此代码库的某些组件的地方。因为无论是我还是我工作的公司中的任何人都能够找到通向这个地方的名字，所以我最终解雇了，并决定为该问题找到另一种解决方案。

虽然花费超过[1]两天的维护成本却没有得到任何结果（一无所知，无修复，一无所获）可能会很糟糕，但用户命名法和源命名法之间的差异会增加许多常规任务的维护费用一个软件。

重要的是要指出，间接费用随着生产软件的公司而增加，在一个大型组织中，问题报告不会在您的桌面上出现，而要经过数位同事的考虑之后，修复程序可能会受到测试。

[1]因为涉及多个开发人员。

我并不总是重命名代码和数据，因为某些包在客户之间共享。他们基本上在使用相同的东西，但名称不同。例如，在CMS中，一个客户将其客户称为“客户”，而另一个客户则将其称为“客户”。因此，我们从表面上将“客户”替换为“一个客户”的“客户”，但是CMS始终是“客户管理系统”。

另一个示例是带有诸如权限vs访问控制列表，admin vs管理器之类的术语的用户管理。这可能会使新用户感到困惑，但是对于诸如此类的核心组件，通常会有核心开发人员来确保这些组件适用于所有客户端和也易于其他开发人员实施（例如，通过创建可配置标签）。

可能会认为，如果您进行了此更改，那么如果其他客户使用了相同的产品（基本上将其转变为产品），希望您无需再次进行此操作。