Java上线数据订正_java开发规范总结

1.抽象类命名使用 Abstract 或 Base 开头； 异常类命名使用 Exception 结尾； 测试类命名以它要测试的类的名称开始，以 Test 结尾。

2.POJO 类或者通常所说的实体类中布尔类型的变量，都不要加 is，否则部分框架解析会引起序列化错误。

3.任何运算符左右必须加一个空格。

4.构造方法里面禁止加入任何业务逻辑，如果有初始化逻辑，请放在 init 方法中。同理getter setter方法

5.类、类属性、类方法的注释必须使用 Javadoc 规范，使用/*内容/格式，不得使用//xxx 方式。 说明： 在 IDE 编辑窗口中， Javadoc 方式会提示相关注释，生成 Javadoc 可以正确输出相应注释； 在 IDE 中，工程调用方法时，不进入方法即可悬浮提示方法、参数、返回值的意义，提高阅读效率。

6.应用中不可直接使用日志系统(Log4j、 Logback) 中的 API，而应依赖使用日志框架SLF4J 中的 API，使用门面模式的日志框架，有利于维护和各个类的日志处理方式统一。

7.可以使用 warn 日志级别来记录用户输入参数错误的情况，避免用户投诉时，无所适从。注意日志输出的级别， error 级别只记录系统逻辑出错、异常等重要的错误信息。如非必要，请不要在此场景打出 error 级别

8.字段允许适当冗余，以提高性能，但是必须考虑数据同步的情况。冗余字段应遵循： 1) 不是频繁修改的字段。 2) 不是 varchar 超长字段，更不能是 text 字段。

9.单表行数超过 500 万行或者单表容量超过 2GB，才推荐进行分库分表。 说明： 如果预计两到三年后的数据量根本达不到这个级别，请不要在创建表时就分库分表。

10.如果有 order by 的场景，请注意利用索引的有序性。 order by 最后的字段是组合索引的一部分，并且放在索引组合顺序的最后，避免出现 file_sort 的情况，影响查询性能。 例如： where a=? and b=? order by c; 索引： a_b_c

11.利用延迟关联或者子查询优化超多分页场景 例如：先快速定位需要获取的 id 段，然后再关联： SELECT a.* FROM 表 1 a, (select id from 表 1 where 条件 LIMIT 100000,20 ) b where a.id=b.id

12.不得使用外键与级联，一切外键概念必须在应用层解决。 说明： (概念解释) 学生表中的 student_id 是主键，那么成绩表中的 student_id 则为外键。如果更新学生表中的 student_id，同时触发成绩表中的 student_id 更新，则为级联更新。外键与级联更新适用于单机低并发，不适合分布式、高并发集群； 级联更新是强阻塞，存在数据库更新风暴的风险； 外键影响数据库的插入速度。

13.数据订正时，删除和修改记录时，要先 select，避免出现误删除，确认无误才能执行更新语句。

14.在表查询中，一律不要使用 * 作为查询的字段列表，需要哪些字段必须明确写明。

说明： 1) 增加查询分析器解析成本。 2) 增减字段容易与 resultMap 配置不一致。

15.分层领域模型规约： DO(Data Object) ：与数据库表结构一一对应，通过 DAO 层向上传输数据源对象。 DTO(Data Transfer Object) ：数据传输对象， Service 和 Manager 向外传输的对象。 BO(Business Object) ：业务对象。 可以由 Service 层输出的封装业务逻辑的对象。 QUERY：数据查询对象，各层接收上层的查询请求。 注：超过 2 个参数的查询封装，禁止 使用 Map 类来传输。 VO(View Object) ：显示层对象，通常是 Web 向模板渲染引擎层传输的对象。

16.用户输入的 SQL 参数严格使用参数绑定或者 METADATA 字段值限定，防止 SQL 注入，禁止字符串拼接 SQL 访问数据库。

17.说明： CSRF(Cross-site request forgery)跨站请求伪造是一类常见编程漏洞。对于存在CSRF 漏洞的应用/网站，攻击者可以事先构造好 URL，只要受害者用户一访问，后台便在用户不知情情况下对数据库中用户参数进行相应修改。 防御措施： 1.检查http referer是否来自同一个域 2.限制session cookie的生命周期 3.验证码 4.使用token

18.在开发中尽量使用快捷键，避免鼠标的繁琐操作，提高开发效率。