关于“编码参考规范”的探讨

去年年末，为我所在的技术团队编写了Java编码规范。其执行过程还算顺利，因为团队不大，并且大家都希望能够有这么一个可供参考的东西。但是在我与其他的团队交流的时候，有些程序员却跟我道出了不同的意见。现在我摘出几条：

1、团队应该在设计上追求一致，比如一致的业务逻辑、一致的算法，但是在编码风格上应该带有些个人色彩，否则就没有乐趣了。

2、我们每天都有那么多东西约束我们，比如：上下班要打卡，工作任务即使加班也要按时完成，涨工资不随心愿，头头并不能理解我的愿望和思想等等。为什么还要在编码风格这么小的事情上进行约束呢？

3、开发团队里规范太多了，连编码规范都要统一么？开发组长和技术经理就不应该过多的干涉细节，这样还让我们怎样工作？

听到这些言语，我很感叹，因为我曾经也有过类似的想法。但是我现在想说的是：

1、我们是一个团队，需要协作、需要共事。项目开发的工作并不是一起玩过家家，更不是一个人自娱自乐。一个标准的编码规范，有利于团队的协作，包括代码共享、交互学习、结对编程、交叉测试、代码审查等等，更有利于提高大家的工作效率和团队精神。它就像实现模式一样让大家不必为细小的琐事而浪费精力，直接按照经过检验的惯例来做。它更像设计模式一样，使大家有一个共同的参考，共同的标准做法。

2、人活在世上，除非有能力和勇气做一个独一无二的、创造历史的牛人，否则就需要遵守社会国家、家庭、公司、团队的各种规范和制度。但即使是上述的那种牛人也是需要先虚心学习、融入环境，而后才能去创造历史。所以，我认为一个组织是需要它自己的规矩的，它的合理与否可以经过商榷和探讨，但是它的存在必要性是可以完全肯定的。我相信，一个希望和团队一起共事、有团队精神的成员是不会对一般性的规范和制度产生质疑的。

3、就开发工作而言，我所提倡的是：编码风格的统一，设计风格的自由。每一个项目的设计理念和架构是需要项目技术负责人自己去把控的，只有这样才能让大家真正的思考怎样才能做好软件设计，这样才能让大家真正的在项目中获得经验和锻炼。然而，对于编码的风格、父包命名规则、缩进规定等等这类细小的地方不需要、也不值得让每个程序员去费心选择，这既不利于工作重点的明确也不利于代码可读性的提高。

4、其实，从实现模式和设计模式的概念中，我们可以映射出编码风格统一和设计风格自由的真正含义。

实现模式，是一些久经历史验证的一些惯例和原则。虽然可以根据具体的情况进行调整，但是大多数情况下它已经成为了大多数开发者们的习惯性行为。毫无理由的改变，就意味着在交互和沟通过程中需要花费额外精力去解释和理解。编码规范就类似于实现模式。

设计模式，也同样是业界精英们总结出来的好的设计方法。然而，每个项目都有它的特殊性和独立性。我们需要根据项目需要来做出我们的设计，教科书似的完全照搬设计模式并没有什么好处。我很少看到完全照搬的代码能够成为一个好的设计。好的设计是什么？我认为，好的设计是开发者根据实际要处理的问题，选择、组合、演化、应用众多设计方法和技巧，在满足各类客观指标的情况下，构建出高效灵活的解决方案实现。注意，我这里说的并不是在一个类中所运用的那一小块模式代码，而是至少针对于模块的系统化设计。设计的自由开放是为了什么，这就是原因，根据问题求解，发挥出我们的生产力和创造力，构建出优秀的解决方案。

以上的所有，欢迎大家共同探讨和合理拍砖。

附件中有文章中提到的我先前编写的《Java编码参考规范》（已变更为1.0版本），仅供参考。当然也希望大家对其中的细节提出自己的建议和意见。