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

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

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

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

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

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

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

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

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

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

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

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

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

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

原创文章,作者:carmelaweatherly,如若转载,请注明出处:https://blog.ytso.com/185318.html

(0)
上一篇 2021年11月4日
下一篇 2021年11月4日

相关推荐

发表回复

登录后才能评论