记得初学java，彻夜学习马士兵老师的教程，讲到struts 2时，马老师说道，真实的项目开发，命令约定非常重要。当时太年轻，并不明白这句话的真谛，但是还是默默记在心里。等到真正参与项目了，见识了很多因为不约定或者约定不一致而引发的争吵和矛盾，也见识了很多拥有优雅简练的约定的很棒的项目。有很多吐槽，这里就不说了。只是总结一下自己的经验吧。
1. 约定必须面面俱到
从项目的架构，到各种实体的命名，包括模块，文件，类，对象，变量，方法，注释的格式，等等，凡是开发人员参与的东西，必须都有约定说明。比如，所有的数据库访问对象都必须放在models目录下；所有的标识符必须用驼峰式。
比较专业的程序员，一般都会遵循已有的项目风格，比如，虽然没有命名约定，但是，他会至少参考一下已有代码的命名风格，然后开始写自己的代码。虽然他的风格会和其他的人不一样，至少他是有自己的风格的。但是，总是会有很不负责任的人存在，而且不在少数，他们的风格是，没有风格。高兴注释就注释，不高兴就不注释。有时候变量是驼峰，有时候是下环线。所以，面面俱到是非常必要的。
2. 约定必须简洁
为什么要简洁？只有简洁的约定，才能被人所接受。
我亲眼见过繁琐约定的诞生，甲说，命名用驼峰式吧，乙说，数据库对象的名词应该用下环线比如 user_model，然后领导说，两种综合一下，于是一个约定诞生了。 可是真的有必要吗？
这个时候，一个独断专行的约定指定人，可能比一个爱接受建议的，更好。
3. 约定必须死板
不遵守约定的代码，对不起，请改了之后再提交。
你觉得有个好建议，希望加到约定中，对不起，请接受现有的约定。
当然，应该一定的周期，更新约定，但是不宜频繁。
4. 必须要有人监督约定的实施
再好的约定，没人监督，都会沦为废纸。人都是有惰性的，不要相信自觉。至少，在程序员素质良莠不齐的项目组里，一定要有明确的人来监督实施。
以上。