团队合作和个人开发完全不一样，要想问题少，必须强行规定一些东西，成为一种习惯，起初会很痛苦，但是这样磨合一段时间后会发现效果非常的棒，下面的一些规范是老大经常和我们说的，我总结一下分享给大家！之后会不定时更新！！

方法命名

1、get set开头的方法只能出现在dto 、do、po等对象实体中，用于属性值的设置和获取，其他类中禁止使用，主要是为了避免读代码的人混淆

2、从数据库或者远程获取数据时，方法名称应该使用query、fetch开头

3、创建数据对象或者对象转换赋值操作，封装到一个方法里面，名字以build、generate开头，填充数据以fill开头,转换数据使用convert开头

4、方法名称必须动词在前，名词在后

5、入参不能是map，因为别人不知道传什么，出参不能是map，因为别人不知道返回的是啥。

日志处理

1、日志打印统一使用slf4j，禁止使用log4j的方法，这样主要是更换日志框架的时候更为方便

1、所有异常不能吃掉，一直向上抛出，在最顶层捕获并打印

2、如果返回值是BaseResult或者BasicResult类型，方法则不用抛出异常，但异常信息一定要包含在返回对象之内，不能丢掉；否则必须抛出

3、为方法进行aop拦截，使用log打印入参和出参，可以为解决和定位问题节省大部分时间

1、参数如果是必传参数，使用基本类型替代，不使用引用类型，类中的变量也是如此，数据库对象DO、POJO除外

1、如果是调用其他系统接口，接口的完整返回值样例需要写在调用方法的地方。能达到的目标是让读代码的人在不用看文档的情况就能非常清晰的了解接口的返回值状态

2、普通接口、属性注释要全面，让调用者可以不去问你就知道该怎么使用该接口，而不是每个人都要问一遍，无形之中增加沟通成本

1、dao层只负责单纯的CRUD，不掺杂处理任何业务，sql语句尽量设计成通用查询形式，非特殊情况尽量不针对某一个业务功能写针对性的sql。

2、在dap层的上面封装一层manager层，负责封装一个或一组业务而存在，让调用者不用关心具体实现就可以放心使用，所以这一层的接口要精心设计哈

3、尽量让主流程代码清晰，像参数校验、大段的数据填充、转换，这些都应该放到独立的方法和类中

4、如果一个相同意义的接口在项目中出现了两次，但是是不同的人写的，那么这两个人就要坐下来，决定干掉其中一个接口！

5、对于废弃或修改接口，将使用@Deprecated 关键字，并通知上游修改替换，待全部替换完毕后，后续此接口将不再维护，或是进行删除。

6、能够穷举出来的字段尽量设计成枚举，且枚举的key不能为“”

1、每次开发新功能或者修复bug都要新拉分支进行开发，格式为开发新功能使用dev_date_xxxx,修复bug使用bugfix_date_xxxx

2、每次开发完毕，测试通过后提交合并请求,由专人负责合并到主干，必须由专人负责合并，这个很重要。

3、每次提交的日志，前缀必须是你当前在干的这件事的简称，比如(性能优化:xxxxxx)，过程中所有的日志提交都要使用这个前缀

4、每天早晨都需要把release的代码向下合并到自己的分支，每天至少一次，上线合并release前再次向下合并一次，确保冲突率降到最低