个人总结一点开发规范 （思维）

开发规范，这个问题是每个技术都在做的事情，

比如下面的 阿里开发规范截取判断

命名
【规范】类名使用UpperCamelCase 风格，必须遵从驼峰形式，但以下情形例外： （ 领域模型的相关命名 ）DO / BO / DTO / VO 等。
正例： MarcoPolo / UserDO / XmlService / TcpUdpDeal / TaPromotion
反例： macroPolo / UserDo / XMLService / TCPUDPDeal / TAPromotion

【规范】方法名、参数名、成员变量、局部变量都统一使用lowerCamelCase 风格，必须遵从驼峰形式。
正例： localValue / getHttpMessage() / inputUserId

【规范】常量命名全部大写，单词间用下划线隔开，力求语义表达完整清楚，不要嫌名字长。

【规范】抽象类命名使用 Abstract 或 Base 开头 ； 异常类命名使用 Exception 结尾 ； 测试类命名以它要测试的类的名称开始，以 Test 结尾。枚举类名建议带上 Enum 后缀，枚举成员名称需要全大写，单词间用下划线隔开。

【规范】POJO 类中布尔类型的变量，都不要加 is ，否则部分框架解析会引起序列化错误。

【规范】各层命名规约：
A) Service / DAO 层方法命名规约
1 ） 获取单个对象的方法用 get 做前缀。
2 ） 获取多个对象的方法用 list 做前缀（习惯：getXXXList）。
3 ） 获取统计值的方法用 count 做前缀。
4 ） 插入的方法用 save（ 推荐 ） 或 insert 做前缀。
5 ） 删除的方法用 remove（ 推荐 ） 或 delete 做前缀。
6 ） 修改的方法用 update 做前缀(或modify)。
B) 领域模型命名规约
1 ） 数据对象： xxxDO ， xxx 即为数据表名。
2 ） 数据传输对象： xxxDTO ， xxx 为业务领域相关的名称。
3 ） 展示对象： xxxVO ， xxx 一般为网页名称。
4 ） POJO 是 DO / DTO / BO / VO 的统称，禁止命名成 xxxPOJO 。

常量
【规范】不允许任何魔法值（ 即未经定义的常量 ） 直接出现在代码中。
反例： String key =” Id # taobao _”+ tradeId；
cache . put(key , value);

　很多规范都是不必赘述的了，

个人总结一些其他的，

1，用户数据，尽量不要删除后重新添加这种操作，而应该是去维护（修改）

2，很多维护地字典在使用的过程中 key value 都可以冗余进去使用的表中，方便查询

3，枚举的使用，对于固定的或者更新时一般需要重新code 的东西可以写Enum，而变动比较多的可以维护字典表

4，代码在操作两张表或者对一张表中数据进行两种操作的 比如先删除后增加 必须使用事务

5，定义实体的时候，request 和response 实体尽量分开，维护功能时 减少实体用错改错概率

6, 数据库表在创建的时候每个表一般冗余6个字段 创建时间 创建人 修改时间 修改人 数据状态（有效 无效 删除 ）备注