17.2 确保一致性

一致性是很难保持的，特别是当许多人在一个项目上工作了很长时间的时候。一个小组的人可能不知道另一个小组建立的约定。新来的人不知道规则，所以他们无意中违反了约定，并创造了与现有约定冲突的新约定。以下是建立和保持一致性的一些技巧：

文档。创建一个文档，列出最重要的整体约定，如编码风格指南。把文件放在开发者可能看到的地方，比如项目Wiki上的一个显眼的地方。鼓励新加入小组的人阅读该文档，并鼓励现有的人每隔一段时间复习一次。一些来自不同组织的风格指南已经在网上发布；考虑从其中一个开始。

对于那些比较本地化的约定，例如不变性，在代码中找到一个合适的位置来记录它们。如果你不把这些约定写下来，其他人就不可能遵守它们。

强制执行。即使有好的文档，开发人员也很难记住所有的约定。强制执行约定的最好方法是编写一个工具来检查违规行为，并确保代码在通过检查器之前不能被提交到版本库。自动检查器对于低级别的语法约定来说效果特别好。

我最近的一个项目遇到了行终止符的问题。一些开发者在Unix系统上工作，那里的行是由换行符结束的；另一些开发者在Windows系统上工作，那里的行通常是由一个回车符和一个换行符结束的。如果一个系统的开发者对以前在另一个系统上编辑的文件做了一个小的编辑，编辑器有时会把所有的行结束符替换成适合该系统的结束符。这让人觉得文件的每一行都被修改了，很难追踪有意义的变化。我们建立了一个约定，即文件应该只包含换行符，但很难保证每个开发者使用的每一个工具都遵循这个约定。每次有新的开发者加入项目，我们都会遇到大量的行终止问题，尽管该开发者适应了这一约定。

我们最终通过编写一个简短的脚本解决了这个问题，该脚本在修改提交到源代码库之前自动执行。该脚本检查所有被修改的文件，如果有任何文件包含回车，就中止提交。该脚本也可以手动运行，通过用换行符替换回车/换行符序列来修复损坏的文件。这一下子就消除了问题，而且还有助于培训新的开发人员。

代码审查为执行约定和对新开发人员进行有关约定的教育提供了另一个机会。 代码审查员越挑剔，团队中的每个人都会越快地学习约定，代码也会越干净。

当在罗马时... 最重要的约定是，每个开发者都应该遵循古老的格言“当在罗马时，像罗马人那样做”。在新文件中工作时，请查看现有代码的结构。所有的公共变量和方法都是在私有变量和方法之前声明的吗？这些方法是按字母顺序排列的吗？变量是像 firstServerName 那样使用驼峰命名法，还是像 first_server_name 那样使用蛇形命名法？当你看到任何看起来有可能是约定的东西时，请遵循它。当做出一个设计决策时，问问自己是否有可能在项目的其他地方做出过类似的决定；如果是的话，找到一个现有的例子，在你的新代码中使用同样的方法。

不要改变现有的约定。抵制“改进”现有约定的冲动。有一个 "更好的想法 "并不是引入不一致性的充分借口。你的新想法可能确实更好，但一致性优于不一致的价值几乎总是大于一种方法对另一种方法的价值。在引入不一致的行为之前，问自己两个问题。首先，你是否有重要的新信息证明您的方法在建立旧约定时不可用？第二，新的方法是否好得多，值得花时间去更新所有旧的用法？如果你的组织同意这两个问题的答案都是“是”，那么就去做升级；当你完成后，应该没有旧约定的迹象。然而，你仍然面临着其他开发者不知道新约定的风险，所以他们可能在将来重新采用旧的方法。总的来说，重新考虑既定的约定很少会是对开发者时间的良好利用。