在规模不大的程序中，当我们没有那么多实体时，为了保持代码的可读性，通用术语以及增强团队成员之间的相互了解，必须定义和维护程序词汇表。

我们(或者公司)如何处理此任务，我们有什么纪律，我们采取了什么安排？

解决方案

大多数大小合理的项目都应具有编程/编码标准文档，该文档规定了应遵循的通用约定和命名准则。

解决此问题的另一种方法是通过代码审查。显然，需要审阅者之间进行一些协调(文档对此也有帮助)。代码审查有助于使更环保的开发人员和资深开发人员保持一致，并成为实施编码标准的途径。

将软件包/模块划分为逻辑组，并使用描述性和简洁的名称。避免使用通用名称，除非它们确实是计数器等。请为功能或者功能组创建约定并坚持使用。

领域驱动设计在这里很有趣，因为它鼓励程序员使用领域词汇。最重要的是，有一些设计约定，使我们可以使用众所周知的术语(例如服务，存储库，工厂等)来引用应用程序的各个部分。

结合领域词汇表并使用上面的技术约定可能是一个不错的解决方案。

我的团队将此类信息(会议/词汇等)保留在Wiki上。这样可以很容易地保持最新和共享。

@Ilya Ryzhenkov，

恐怕大多数公司都没有这样的实践:)我在一家拥有数百万LOC代码库的规模不大的公司工作，他们根本没有任何文档(除了通用的编码准则)

在我的一个项目中，我们维护了在我们的应用程序领域中使用的常用术语词典，并在代码检查期间使用了它。我不时分析.NET XML文档差异，以确定应将哪些实体\术语添加到同义词库中。强制遵守同义词库的唯一方法是编码指南。

Wiki方法被证明是不适用的，因为没有人愿意定期更新它:)

我想知道我们在JetBrains使用什么方法？我在Reflector中检查了ReSharper的代码，并对实体的数量和名称感到惊讶:)