关于“编码参考规范”的探讨
2012-09-04 14:20
211 查看
去年年末,为我所在的技术团队编写了Java编码规范。其执行过程还算顺利,因为团队不大,并且大家都希望能够有这么一个可供参考的东西。但是在我与其他的团队交流的时候,有些程序员却跟我道出了不同的意见。现在我摘出几条:
1、团队应该在设计上追求一致,比如一致的业务逻辑、一致的算法,但是在编码风格上应该带有些个人色彩,否则就没有乐趣了。
2、我们每天都有那么多东西约束我们,比如:上下班要打卡,工作任务即使加班也要按时完成,涨工资不随心愿,头头并不能理解我的愿望和思想等等。为什么还要在编码风格这么小的事情上进行约束呢?
3、开发团队里规范太多了,连编码规范都要统一么?开发组长和技术经理就不应该过多的干涉细节,这样还让我们怎样工作?
听到这些言语,我很感叹,因为我曾经也有过类似的想法。但是我现在想说的是:
1、我们是一个团队,需要协作、需要共事。项目开发的工作并不是一起玩过家家,更不是一个人自娱自乐。一个标准的编码规范,有利于团队的协作,包括代码共享、交互学习、结对编程、交叉测试、代码审查等等,更有利于提高大家的工作效率和团队精神。它就像实现模式一样让大家不必为细小的琐事而浪费精力,直接按照经过检验的惯例来做。它更像设计模式一样,使大家有一个共同的参考,共同的标准做法。
2、人活在世上,除非有能力和勇气做一个独一无二的、创造历史的牛人,否则就需要遵守社会国家、家庭、公司、团队的各种规范和制度。但即使是上述的那种牛人也是需要先虚心学习、融入环境,而后才能去创造历史。所以,我认为一个组织是需要它自己的规矩的,它的合理与否可以经过商榷和探讨,但是它的存在必要性是可以完全肯定的。我相信,一个希望和团队一起共事、有团队精神的成员是不会对一般性的规范和制度产生质疑的。
3、就开发工作而言,我所提倡的是:编码风格的统一,设计风格的自由。每一个项目的设计理念和架构是需要项目技术负责人自己去把控的,只有这样才能让大家真正的思考怎样才能做好软件设计,这样才能让大家真正的在项目中获得经验和锻炼。然而,对于编码的风格、父包命名规则、缩进规定等等这类细小的地方不需要、也不值得让每个程序员去费心选择,这既不利于工作重点的明确也不利于代码可读性的提高。
4、其实,从实现模式和设计模式的概念中,我们可以映射出编码风格统一和设计风格自由的真正含义。
实现模式,是一些久经历史验证的一些惯例和原则。虽然可以根据具体的情况进行调整,但是大多数情况下它已经成为了大多数开发者们的习惯性行为。毫无理由的改变,就意味着在交互和沟通过程中需要花费额外精力去解释和理解。编码规范就类似于实现模式。
设计模式,也同样是业界精英们总结出来的好的设计方法。然而,每个项目都有它的特殊性和独立性。我们需要根据项目需要来做出我们的设计,教科书似的完全照搬设计模式并没有什么好处。我很少看到完全照搬的代码能够成为一个好的设计。好的设计是什么?我认为,好的设计是开发者根据实际要处理的问题,选择、组合、演化、应用众多设计方法和技巧,在满足各类客观指标的情况下,构建出高效灵活的解决方案实现。注意,我这里说的并不是在一个类中所运用的那一小块模式代码,而是至少针对于模块的系统化设计。设计的自由开放是为了什么,这就是原因,根据问题求解,发挥出我们的生产力和创造力,构建出优秀的解决方案。
以上的所有,欢迎大家共同探讨和合理拍砖。
附件中有文章中提到的我先前编写的《Java编码参考规范》(已变更为1.0版本),仅供参考。当然也希望大家对其中的细节提出自己的建议和意见。
本文出自 “Hyper Mind” 博客,请务必保留此出处http://freej.blog.51cto.com/235241/282424
1、团队应该在设计上追求一致,比如一致的业务逻辑、一致的算法,但是在编码风格上应该带有些个人色彩,否则就没有乐趣了。
2、我们每天都有那么多东西约束我们,比如:上下班要打卡,工作任务即使加班也要按时完成,涨工资不随心愿,头头并不能理解我的愿望和思想等等。为什么还要在编码风格这么小的事情上进行约束呢?
3、开发团队里规范太多了,连编码规范都要统一么?开发组长和技术经理就不应该过多的干涉细节,这样还让我们怎样工作?
听到这些言语,我很感叹,因为我曾经也有过类似的想法。但是我现在想说的是:
1、我们是一个团队,需要协作、需要共事。项目开发的工作并不是一起玩过家家,更不是一个人自娱自乐。一个标准的编码规范,有利于团队的协作,包括代码共享、交互学习、结对编程、交叉测试、代码审查等等,更有利于提高大家的工作效率和团队精神。它就像实现模式一样让大家不必为细小的琐事而浪费精力,直接按照经过检验的惯例来做。它更像设计模式一样,使大家有一个共同的参考,共同的标准做法。
2、人活在世上,除非有能力和勇气做一个独一无二的、创造历史的牛人,否则就需要遵守社会国家、家庭、公司、团队的各种规范和制度。但即使是上述的那种牛人也是需要先虚心学习、融入环境,而后才能去创造历史。所以,我认为一个组织是需要它自己的规矩的,它的合理与否可以经过商榷和探讨,但是它的存在必要性是可以完全肯定的。我相信,一个希望和团队一起共事、有团队精神的成员是不会对一般性的规范和制度产生质疑的。
3、就开发工作而言,我所提倡的是:编码风格的统一,设计风格的自由。每一个项目的设计理念和架构是需要项目技术负责人自己去把控的,只有这样才能让大家真正的思考怎样才能做好软件设计,这样才能让大家真正的在项目中获得经验和锻炼。然而,对于编码的风格、父包命名规则、缩进规定等等这类细小的地方不需要、也不值得让每个程序员去费心选择,这既不利于工作重点的明确也不利于代码可读性的提高。
4、其实,从实现模式和设计模式的概念中,我们可以映射出编码风格统一和设计风格自由的真正含义。
实现模式,是一些久经历史验证的一些惯例和原则。虽然可以根据具体的情况进行调整,但是大多数情况下它已经成为了大多数开发者们的习惯性行为。毫无理由的改变,就意味着在交互和沟通过程中需要花费额外精力去解释和理解。编码规范就类似于实现模式。
设计模式,也同样是业界精英们总结出来的好的设计方法。然而,每个项目都有它的特殊性和独立性。我们需要根据项目需要来做出我们的设计,教科书似的完全照搬设计模式并没有什么好处。我很少看到完全照搬的代码能够成为一个好的设计。好的设计是什么?我认为,好的设计是开发者根据实际要处理的问题,选择、组合、演化、应用众多设计方法和技巧,在满足各类客观指标的情况下,构建出高效灵活的解决方案实现。注意,我这里说的并不是在一个类中所运用的那一小块模式代码,而是至少针对于模块的系统化设计。设计的自由开放是为了什么,这就是原因,根据问题求解,发挥出我们的生产力和创造力,构建出优秀的解决方案。
以上的所有,欢迎大家共同探讨和合理拍砖。
附件中有文章中提到的我先前编写的《Java编码参考规范》(已变更为1.0版本),仅供参考。当然也希望大家对其中的细节提出自己的建议和意见。
本文出自 “Hyper Mind” 博客,请务必保留此出处http://freej.blog.51cto.com/235241/282424
相关文章推荐
- 关于“编码参考规范”的探讨 推荐
- 关于OC的编码规范
- Java编码规范总OA信用盘搭建出租维护结(参考腾讯编码规范)
- 关于CSS编码规范的文章
- 关于文件编码格式的一点探讨
- 关于ios项目目录规范结构探讨
- OWASP安全编码规范快速参考指南
- 关于编码规范的延伸资料(来自于福州大学陈世发同学的博客)
- 个人C/C++编码规范______仅供个人参考使用
- 编码规范参考
- 这个if语句怎么运行?附加关于编码规范的思考
- PHP编码规范的深入探讨
- CERT关于Java安全编码规范的新书
- 转帖MSDN的关于RMS文章1:RMS 技术参考、RMS 技术概述(RMS技术探讨QQ群:24893581 )
- [原]关于java的编码规范的一些想法
- 关于编码规范的一点心得体会
- 关于大学生如何进行编码规范的火拼
- [转]可参考的.NET编码规范及编码指南
- 外籍团队工作有感:2、关于编码规范
- python编码规范工具PyLint (未亲测,但是头部分具有参考价值)