【发布时间】:2010-09-11 20:20:29
【问题描述】:
在一个不那么小的程序中,当你的实体不那么少时,为了保持代码的可读性、通用术语,或者提高团队成员之间的相互理解,必须定义和维护节目词汇。
你(或你的公司)如何处理这项任务,你有什么纪律,你有什么安排?
【问题讨论】:
标签: language-agnostic vocabulary
在一个不那么小的程序中,当你的实体不那么少时,为了保持代码的可读性、通用术语,或者提高团队成员之间的相互理解,必须定义和维护节目词汇。
你(或你的公司)如何处理这项任务,你有什么纪律,你有什么安排?
【问题讨论】:
标签: language-agnostic vocabulary
大多数规模合理的项目都应该有一份编程/编码标准文档,其中规定了应遵循的通用约定和命名准则。
另一种帮助解决此问题的方法是通过代码审查。显然,审阅者之间需要进行一些协调(该文档也有助于此)。代码审查有助于让更环保的开发人员和高级开发人员都走上正轨,并充当执行编码标准的途径。
【讨论】:
@Ilya Ryzhenkov,
恐怕大多数公司都没有这样的做法 :) 我曾在一家拥有数百万 LOC 代码库的不那么小的公司工作,他们根本没有任何文档(除了通用编码指南)
在我的一个项目中,我们维护了应用程序领域中常用术语的词库,并在代码审查期间使用它。我不时分析 .NET XML 文档差异,以决定应将哪些实体\术语添加到同义词库中。强制遵守词库的唯一方法是编码指南。
Wiki 方法被证明是不适用的,因为没有人愿意定期更新它:)
我想知道您在 JetBrains 使用什么方法?我在 Reflector 中检查了 ReSharper 的代码,对实体的数量和名称感到惊讶:)
【讨论】:
将您的包/模块划分为逻辑组,并使用描述性和简洁的名称。避免使用通用名称,除非它们真的是计数器等。为功能组或功能组创建约定并遵守它们。
【讨论】:
领域驱动设计在这里很有趣,因为它鼓励程序员接受领域词汇。除此之外,还有一些设计约定,允许您使用众所周知的术语来引用应用程序的某些部分,例如服务、存储库、工厂等。
结合领域词汇并使用上面的技术约定可能是一个很好的解决方案。
【讨论】:
我的团队将此类信息(约定/词汇等)保存在 wiki 上。这样可以轻松了解最新情况并进行分享。
【讨论】: