如何在开发人员团队上构建项目术语的共享词汇表？

Question

当我在一个开发人员团队(3-10人)工作时，我经常注意到，随着代码库的增长，获得每个代码中每个术语的精确和共享定义就成了一个问题。

几个月后，两个完全不同的概念可以使用相同的名称，两个相同的概念可以使用同义词。它加强了新开发人员的代码阅读和集成。

我以电子邮件客户端的编码为例。

以下是几个月后最常见的问题：

• 业务模型词汇表与UI和技术词汇表混合使用(即:电子邮件客户端的文本UI视图和电子邮件模型的文本属性)
• 开发人员以不同的方式翻译相同的概念(即。detailled视图中的Email类在ListView中成为消息-但它仍然使用相同的属性)
• 开发人员之间对模型的近似和不可共享的翻译--有时是由于缺乏英语词汇，导致使用过于频繁的术语(即。项目，文字，标签，按钮，经理，手.)。这些术语听起来不错，但是如果不在团队中讨论它们，就很难得到一个精确的共享定义。
• 对业务概念的误解--这会导致将业务概念混合在一个独特的类中，从而打破单一责任原则。

在编写代码(有时不适合于敏捷开发)之前记录大量文档--在开发过程中，是否有任何方法在团队之间共享业务和技术词汇表？这样，每个人都能清楚地知道什么涉及到一个词--不是一般的，而是在项目和代码上下文中。

Answer 1

代码评审和对编程是解决这些问题的更好工具，因为您对代码有了更多的关注，并且可以更好地协作，使您的命名更加标准化。您必须讨论并就哪些术语需要定义或限制在特定的范围内达成协议。我建议你从大约5个左右的名字开始，让你感到最混乱，从那里开始工作。它将有助于有某种形式的文件，你可以指出，作为真相的来源，可以指出。不过，请记住，您试图限制的术语越多，开发人员就越有可能开始忽略任何文档，或者开发人员可能会觉得他们喜欢的所有术语都被折扣了。

这个问题的解决方案是政治性的，你需要从每个人那里购买，以避免任何一个开发人员觉得他们的贡献被打折扣，因为你不喜欢他们的名字。对这样的事情进行标准化的努力是善意的，但它们也是实现几个标准的好方法，这些标准都是部分遵循的，这使得您的代码比以前更糟糕或更糟。

Answer 2

我不知道无所不在的语言意味着什么，这似乎是解决我的问题所缺少的。

• 业务模型词汇表与UI和技术词汇表(即电子邮件客户端的文本UI视图和电子邮件模型的文本属性)混合在一起，类的单一责任原则是:有一条规则不将任何业务属性存储在View类中，而不管理业务类中的View
• 开发人员以不同的方式翻译相同的概念(即。detailled视图中的Email类在ListView中变成了消息--但是它仍然使用相同的属性)无处不在的语言，如果域不是英文的话，就会有一个域术语的共享翻译表。与任何缺少术语的专家交谈，了解他们如何称呼它。
• 开发人员之间对模型的近似和不可共享的翻译--有时是由于缺乏英语词汇，导致使用过于频繁的术语(即。项目，文字，标签，按钮，经理，手.)。这些术语听起来不错，但是如果不在团队中讨论它们，就很难得到一个精确的共享定义。翻译表，以及对Handler，Manager，Label和其他技术术语的精确的团队定义和标准。)
• 对业务概念的误解--这会导致将业务概念混合在一个独特的类中，从而打破单一责任原则。与专家交谈，要求PO对故事中使用的术语进行具体说明，并在疑问中询问明确的定义。最终写入定义