我与一个团队合作，该团队在不到一年的时间内从2个开发人员成长为10个开发人员。我是第三名，也是第一个提出编码标准问题的人。两位原始的开发人员并肩工作了几年，他们采用了一个对我来说似乎陌生的通用标准。我们遇到的问题与您描述的完全一样。
我们所做的是：
研究编码标准
我们花了几天时间检查已建立的开源项目。我们知道团队会迅速扩大，我们正在寻找基于实际项目而非某些通用准则的实际解决方案。同样，我们也不在乎最佳的编码标准，而是在意一些有意义的规则和准则，而不需要重构我们所有的代码库。如果您愿意，我们正在寻找编码标准技巧。
我们三个人决定，对于一个已建立的PHP项目，最好的编码标准就是Zend Framework遵循的标准。幸运的是，Zend Framework人员提供了非常全面的编码标准文档。
建立我们自己的编码标准
当然，在我们的项目上应用另一个项目的编码标准是没有意义的。我们使用Zend Framework文档作为模板：
- 首先，我们删除了不适用于我们项目的所有内容
- 然后，我们将我们认为与样式有关的所有内容都更改为样式
- 最后我们把所有东西都写下来了
因此，我们手上有一个相当大的文档，存储在我们喜欢的Wiki中，这是一本不错的书，得到了我们所有人的同意。并且完全没有用。
恪守我们的诺言
当时我们的代码库约为1 * 10 ^ 6 sloc。我们知道，自从采用正式的编码标准以来，我们不得不开始重构代码，但是当时我们面临其他问题。因此，我们决定只重构我们的核心库，仅5 * 10 ^ 3 sloc。
我们赋予我们的一个是编码标准主（我们用来代替本地亵渎主）与检查和执行标准的责任。我们每隔几个冲刺就回收一次角色。我是第一个，这是很多工作，因为我必须监视几乎每个提交。
在我任职期间，我们对原始文档进行了一些新的讨论和小的附录，最后我们有了一个比较稳定的文档。我们会不时地对其进行更改，但是其中大多数更改都是在该语言的新功能上进行的，因为PHP 5.3是除名称之外的主要版本。
与新人打交道
下一个新人到来时，是时候对我们的编码标准进行测试了。在简短介绍了我们的代码库之后，我们请他评估我们的编码标准文档。他差点哭了。看来他所做的一切都不一样。
当时我是编码标准专家，因此我需要评估他的意见并相应地修订文档。他的建议是：
- 个人风格事务（暂时被驳回）
- 对他的Java背景有意义的标准，但对PHP却没有太多意义（已废除）
- 他简短接触PHP时遵循的约定（有些被驳回，但很多事实证明是我们在最初的研究中从未想到或发现的流行约定）
在接下来的几周中，他被分配了一个简单的任务：使我们的代码库的几个部分与标准保持最新。我必须根据一些规则仔细选择那些部分：
- 对于不熟悉我们的代码库（通常是PHP）的人来说，代码应该相对容易
- 代码应该在他被雇用要做的事情上
我监控了他的过程，他做得很好。我们确定了无法适应我们文档的几部分代码，并进行了相应的修订（代码和/或标准，以较有意义的为准）
然后另一个新人到了。我们重复了该过程（这次是不同的主站），然后又再次起作用。然后再次。
结论
- 创建一个编码标准文档，但是要确保您的标准不是排他性的，而是在平台的更广泛的社区中能够反映通用的标准。
- 为我们的编码标准主管分配相似的角色。有人至少监视新代码，尤其是新成员的新代码。回收角色，因为它非常无聊。
- 始终评估来自新成员的输入。如果有意义，请务必修改您的标准。您的编码标准文档应该在不断发展，但是进展缓慢。您不想在每次迭代时重构您的代码库。
- 为每个新成员留出一些时间来学习并适应您的标准和约定。在这种情况下，通过做得最好的方法来学习。
- Wiki为此类文档创造了奇迹。
- 代码审查在任何情况下都可以创造奇迹！
建议在过程中的某个时刻，我们使用预提交钩子来自动检查标准。我们出于各种原因而决定拒绝它，关于StackOverflow的问题有一些有趣的讨论：
有些是特定于PHP的，但答案适用于所有平台。