散分...顺便听下各位关于工作中“约定优于配置”的看法。散分...

Question

约定优于配置这种说法。工作也有段时间了，在实际开发过程中，团队中也会自己指定一些自己的开发规范，但是都不很系统，基本就是团队成员之间商讨一下便定下来了，但是这样到了后期测试的时候，还是有诸多问题，（测试人员的意见也很重要），而且那些规范及其简单，就是些关于命名、验证之类的。所以想请问下，大家在实际开发过程中都会约定好些什么规范？
其实还一个问题，就是开发过程中，团队成员之间对于这个“约定”的执行不是很好，一般到最后又乱套了，这方面又如何做到能够很好的执行约定？

Answer 1

说下自己的。
1、类的命名，如XXXAction、XXXService、XXXDao之类的，这个基本上大家都是这样的吧。
2、页面的命名，当时约定的也是首字母大写。增删改查依次是Insert\Delete\Update\Select开头
3、页面中展示的时候的一些约定，字段的长度、验证、以及符号的引用时全角还是半角等等的细节。

Answer 2

楼主了解一下ROR的精神，以及搜索一下 'JavaEye' 和 'ROR调优'。为了说明各个对象之间的关联关系，一般的Web应用开发框架往往采用写入XML配置文件的方法。这种方式虽然可以解决一些问题，但是却带来了管理上的混乱。Rails 对此的态度是约定优于配置，这意味着在Rails中不会出现XML配置文件。Rails使用Web应用多年来积累的各种常见约定（更具体地说是命名规则）来代替XML配置文件，而在Rails内部的映射与发现机制根据这些约定可以实现对象之间的关联。举个例子。
访问
http://url/a/b/c
如果在javaEE的世界里面，可能就会写个Servlet，然后在xml内配置一下。有一天这个子系统变化了，那么你要改的东西就多了。
而在PHP，或者ROR中，那么这个可能只是一种约定，这个约定决定了程序员写c.php，或者是class c，并把这个文件放到目录a/b下就OK了。一目了然，而不是看配置。配置带来的灵活性往往是一种负担。这种负担要求程序员了解更多东西，写更多代码，维护更多的代码而已。
此外，配置真的那么能适应变化吗？以javaEE的各种配置来说，实际上，很多东西从开发到部署，可能都不会发生变化，那么配置的适应能力就变成一种奢侈品了。

Answer 3

像这种命名规范按照java规范来就好了

Answer 4

有的公司会按照Java规范，但是有的公司会有自己的一套编码规范。
像华为

Answer 5

contract是标准的，强制的；
config是不标准，随意的；

Answer 6

1. 代码规范：这个不用解释了
2. 设计规范：系统一般有自己的架构，比如要分层，不要在session中保存数据等，这个可以让架构来定
3. UI规范：一个应用程序，比如web系统，整体风格应该统一，比如出错信息应该用红色提示，但是成功信息用绿色等等。这些应该是产品方来决定。
规范应该是事先定好的，不可以因为任何原因，比如时间比较紧等做出不守规定的事情

Answer 7

一切按java规范来，没约定，看到谁不遵守，开会批评一番。再有同样，降级

Answer 8

http://www.360doc.com/content/07/0807/09/17598_658049.shtml

Answer 9

约定可以制成模板 或插件在开发之前做好模板就可以提高开发效率。
比如做一些IDE的插件 生成相关的代码但约定只适用于某个具体项目 除非公司产品是一个系列的然后你说的规范，一般通用的是编码规范，也有客户提出的编码规范，这些可以制作一些工具来检查。

Answer 10

CRUD，这四个操作几乎是所有模块都具备的。
CRUD整个流程的代码很多都是雷同的，有规律的。
JSP相应的代码很多也是雷同的（指的是增加、显示等等）。
JSP表单的很多内容都与数据库的字段是一一对应的。（能否根据数据库的字段自动生成表单？答案是可以的）
JavaBean、hbm以及DB Schema之间是可以互相生成（借助于Hibernate的帮助）。
struts.xml中的很多内容是相似的，能否自动生成？答案是可以的
对于Spring的配置文件：applicationContext.xml很多内容是相似的，能否自动生成？答案是可以的
Service的基础代码也可以自动生成。