xx项目代码规范与项目质量
从以往各种的经验来看，一个优秀的产品或项目，经过千锤百炼，成为一个内涵丰富的宝藏：文档、代码、设计、bug的fix和各种思想的火花，都沉淀下来，变成了很多人长期的资产和营养。在这个过程中，项目的质量是长期稳定的。但是一个一般的项目，由于各种因素，开始就质量一般，后来又各种曲折，最终项目质量会从开始的一般水平，很快的下降，收敛到一个非常低得水准。在这个过程中，文档和设计开始残缺，代码开始腐朽，散发着我们常说的bad smell的味道。那么如何防止这个变坏的过程呢？一是项目一开始就要按照一个简单高效的方式实施一些规范：代码风格、命名、注释等等，约束概念和形式上的一致性；二是制定较高的质量目标：unit test和code/sql/document review等等，提高项目质量；三是持续的执行。
代码风格
-- 亲，一个不合适的ctrl+f会变成merge代码的噩梦，请每次格式化的时候，考虑下你用的是不是跟大家一致的模板。
-- 代码应该是简洁的，清晰的，可读性强的，高效的
模板保证新建的类和方法的注释风格一致，format格式一致（按120字符每行）。
合理的缩进和空行，便于阅读代码。
提供格式模板，请在eclipse中使用：
详见上面链接wiki文档的附件，其中codetemplate.xml用于eclipse的java-code style-code template，eclipsetemplate.xml用于java-code style-Formatter。
命名标准规范
-- 统一各种层次对象的命名，一方面是使得团队多人的代码更一致，更一方面更是我们自己概念理解的统一。
项目
统一使用ieo-xxx方式命名project，比如ieo-web，ieo-biz，ieo-common等等。
包、类
包名必须小写，尽量一个单词或缩写。
包名应该和所在项目名一致，与包下的类的作用一致。
实现类所在的包应该是接口或抽象类的包名后缀.impl。
类名的每个单词首字母必须大写。
类名必须能直接表达本类的作用。
类名的后缀必须表达出其所在分层，比如Screen，AO，Manager，Service，DAO等等。
方法
方法名称首字母必须小写，后续每个单词首字母大小。
方法名必须能直接表达方法体的作用。
参数名称必须是有意义的。
增删改查的方法使用create, delete, update, find开头。
局部变量
局部变量名称必须是有意义的，禁止使用user1,user2,user3,a,b,c命名。
常量
静态常量需要加上final。
公用的常量必须放在常量类中
非公用的常量可以放置在使用的类中，声明为private
可以枚举的常量集合必须使用常量或枚举类
常量名称必须是有意义的
常量必须全部大写，并使用下划线连接不同的单词
使用很少的字面量，在不影响阅读的情况下可以不使用常量声明，直接写在代码中
配置文件
spring相关的配置文件，按层次或功能划分不同的配置文件
spring所有的bean，一般按照类名或接口名首字母小写命名
spring配置文件默认使用byname的autowire
sqlmap必须使用xxxx-sqlmap结尾
VM文件
文件名必须与内容在意义上一致。
文件名首字母小写，后续单词首字母大写。
vm文件中的变量引用需要注意使用!判断空。
名词参照表
对于行业相关术语的和常用命名的前缀，请在这里查询，如果找不到请添加到这里并周知大家：
xxxxxxx
注释规范
-- 如果说代码本身说明了在做什么，注释则是说明了为什么要这么做。复杂的代码没有注释，过几天你自己都看不懂了。
接口、类和public的方法必须要有注释，请参考风格模板，或者eclipse里在方法和类上shift、alt+J
待定的功能、review的问题、修复的bug，请使用TODO，REVIEW，FIXME标记。
bug修复，问题排查时修改的关键代码，请加上注释，说明修改人，修改时间，问题分析和采取的措施，如果说明较多在wiki上，请加上链接。
日志标准规范
-- 日志是用来排查问题的，你今天写什么注定你以后用什么。
所有写操作必须有日志
所有日志必须有唯一标识（比如update一条数据，必须记录id）
必须说清楚本操作是做什么的，影响了什么，结果如何
所有与第三方交互数据必须输出原始报文（比如xml或soap）
日志必须使用enabled判断：log.isDebugEnabled(){ log.debug(...); }
单元测试要求
-- 单元测试的目的是持续的保证代码方法层次的逻辑是对的，一直都是对的，改了也是改对了的。
最小粒度方法级的逻辑测试
覆盖所有逻辑分支判断和边界条件
不依赖具体的某些绝对条件，比如写死的日期
不能catch异常不处理
test case不得在运行时有依赖关系
test case的包名类名与被测类保持一致
test case的方法建议一般使用中文
能mock的对象尽量mock，比如对外部的依赖，本test case不关注的manager-
核心模块如biz、dal、core，要求必须70%以上。
其他模块如web等，建议30%以上。
SVN要求
-- svn是可靠的，当然前提是使用svn的人必须是可靠的。
提交时必须输入说明修改目的的备注，比如修改日期格式化错误问题，解决bug id：123456
分支名称必须带日期版本号加上分支说明，比如廉航的分支：v051216_20120308_Lianhang
其他要求
整个项目使用GBK编码
设计文档评审前必须发出并收集反馈意见，评审需要针对意见
模块代码完成和大范围修改（非小bug fix），必须code review
参考列表
xxxxx