Java规范

1. 0编程规范 ：

命名规范：

1.不能用下划线
2.禁止纯拼音
3.除了DTO，VO这种领域模型其他都要用CameLCase, 类用UpperCamecase
4.方法名， 成员变量， 形参， 实参， 局部变量 都用lowerCamelCase
5.常量命名全部大写， 单词间用下划线隔开MAX_STOCK_COUNT
6.抽象类，用abstract 开头， 测试类用test结尾， 异常类用exception结尾
7.返回bool类型的方法， 命名用is 进行
8.缩写如果影响到见名知意， 就不缩写
9.用到设计模式例如Observer， Factory 直接在结尾让别人阅读出来
10.接口类中的方法和属性，要保持简洁， 就不加任何的修饰符(public)， 用doc注释
11.Service接口和 serviceImpl 接口
12.枚举类名带上Enum后缀
13.Service/dao 层方法命名规范：
(1)获取单个对象的方法用get
(2)获取多个对象的方法用list
(3)获取统计值得方法用count
(4)插入方法用save
(5)删除用remove
(6)修改用update做前缀
14.领域模型命名规范：
(1)数据对象： 暂时不知道

常量定义：

1.不允许未经过定义的魔法值出现在代码中
2.Long类型进行赋值的时候屁股后面的l 修饰符， 统一用大写方便辨认
3.常量类应该归类进行维护
①跨应用共享的常量应该放在jar中的统一目录
②应用内共享常量
③子工程内部共享常量
④包内共享常量
⑤类内共享常量
4.枚举类型， 如果有衍生的要求 如星期几， 也有数字表示的要求， 在枚举类型中增加所以用枚举类型最好

格式规范

1.If, for, while, switch, do等关键字后面都要加空格
2.任何运算符号左右两边都要加空格， 如： =, +, -, &&, *, /, %
3.单行代码不能超过120个如果超过的话要进行换行， 多行的判断语句类可以少个直接换行
(1)相对缩进4个空格
(2)运算符和下文一起换行
(3)调用的点符号与下文一起换行
(4)参数过长， 要在逗号后面进行换行
(5)括号前不要换行
4.参数在定义和传入的时候参数逗号后面必须加空格
5.不同业务逻辑和语义之间加空行进行间隔

OOP规约

1.静态方法或者静态变量别无谓地生成对象去访问， 增加编译器的解析成本。直接用类名
2.所有覆写的方法必须加@Override注解
3.尽量别用可变参数编程， 如果用的话尽量避免用Object（String type, Integer... ids）
4.对外的接口不允许修改方法签名， 改的话要加@Deprecated
@Deprecated
protected HandlerExecutionChain getHandler(HttpServletRequest request, boolean cache) throws Exception {
return getHandler(request);
}
5.Object的equals方法很容易抛出空指针异常， 使用常量或确定值去调用equals方法
6.Integer var = ？ 如果在-128-127之间赋值的话会被放到integer的缓存里面去， 除了这些之外其他都会在堆上产生， 所以说除了-128到127 可以用==进行判断 其他的话都不能==进行判断
7.基本数据类型和包装类的使用标准：
(1)所有的javabean, RPC方法的返回值都要用包装类型数据
(2)局部变量用基本数据类型就好， 因为在栈内， 会自动被操作系统回收
8.split方法经常要做一个判断是否有值得判断
9.构造方法放到一起去
10.类中的方法定义顺序要-》 公有 -》 保护 -》 私有 -》 getter/setter方法
11.Getter和setter方法中别加业务逻辑这样会增加排查难度， 就让业务逻辑放在业务逻辑层， 多一个方法就多一个方法
12.String进行+操作 其实编译的时候每次都会new出一个StringBuilder对象进行append操作， 所以最后通过toString 方法进行返回String对象，造成资源浪费
13.使用好Final提高效率， 这个跟编译器有关系
14.Object的clone方法是浅拷贝， 拷贝地址的， 要深拷贝的话要重新生成变量要重写object方法才行， 所以要慎用
15.对于对象的权限控制， 成员变量的权限控制， private， protect， public之间的选择， 单例生动的例子

集合的处理

1.HashCode和equals， 要重写equals就要重写hashcode
2.Set存储的重复值是根据hashcode和equals进行判断， 所以如果要用set进行存储，那么就要用hashcode 和 equals进行重写

注释规范

1.类， 抽象类， 类似的 成员变量和方法都要用doc注释 注释起来
2.所有的类都必须加创建者的信息
3.有些可以用英文进行注释
4.参数，返回值， 核心逻辑， 异常信息，
5.注释掉一些代码的原因液压说清楚
6.FIXME进行标记某些代码是错误的， TODO::

其他

1.获取事件用System.currentTimeMillis() ， jdk8，
2.明确停止的代码直接清理出去
3.Jdk官网去查看最新的代码情况
4.正则是预编译的， 所以用好正则语句很重要

异常日志

5.不要捕获空指针和超出数组下标的异常， 让程序猿自己进行预处理（if判断）
6.异常不要拿去做条件控制， 因为非常的低效
7.不要对大段代码进行try-catch
8.捕获异常是为了处理它， 可以是程序猿进行手动处理， 也可以是代码中添入自动化代码进行处理
9.Finally对对象流进行关闭， 不要在finally进行return返回，
10.不要求一定要返回空字符或者空对象， 但一定要说明为什么方法会返回NPE，这样调用方可以进行null判断
11.防止npe是程序猿的基本修养？？？？/excuse me ?????
12.在接口进行错误码的时候， 应该提供几点， 1. 状态码， 2. 响应数据 3. 短消息， 关于错误的
13.应使用业务含义的自定义异常， 而不用业界推荐的已自定义的异常， 如： DAOException, ServiceException, 而不要用， Exception, Throwable RuntimeException， 后台数据要进行相对处理的校验的时候， 比如说输入信息是否包含敏感词汇， 长度是否过长， 比如我们的数据抽取的，
(1)说了这些其实白费， 主要还是要注意的是， 前台对于给予的数据进行校验
(2)Dao层对于已有数据进行校验， 关于一些增删改查进行校验
(3)服务层对于拿到的数据进行校验， 其中各自的服务处要各自进行定义校验捕获的方法
(4)PS:: spring 有很多已经封装好的异常类， 我们可以进行参考， GitHub上面可能也有

14.抽取共性方法， 公共类， 公用模块 ！！！ 这点主要是工具类为主， 抽取成模块的话， 需要一定的水平了， 预计maven项目进行抽取成jar类型的时候会用的多一点
日志规约
1.Log4j, logback, slf4j 都去了解下， 因为log4j依赖其他日志均要包含依赖， 所以我们要选slf4j这样更具有独立性。
2.日志系统文件最好保存15天为主， 日志主要是为了保存后端操作， 服务器问题， 查找线索， 放在服务器上更好让开发员进行查出问题。
3.日志的类型和描述均不是很理解， 还有缓存高并发问题， 需要在线去了解下，编译问题同理。
4.Warn级别常用来记录用户参数输入错误的问题， 避免用户投诉时候无所适从， 查看用户输入参数的问题， error只记录系统逻辑错误， 异常等错误信息， 如果非必要的话， 不要用这个 。 也就是warn对于用户， error对于我们， 而warn包含error
5.日志输出的量的问题也需要我们要有效的去了解

MySQL规范

1.建表规约： 如果表示是否的概念， is_xxx 数据类型 unsigned tinyint
2.表名字段名都是用下划线 和 小写字母或者数字， 禁止用数字开头， 禁止两个下划线中间单个数字下划线隔开， 数字靠近左边的字母连起来就好
3.表名不用复数形式
4.禁止使用MySQL官方保留字： desc, range, match, delayed
5.小数类型用Decimal， 禁止使用float和double ， 用后面两个可能存在精度缺失的问题
6.如果存储的字符串长度几乎相等就用
7.表必备的三字段为： id, gmt_create, gmt_modified 类型均为datetime
8.推荐的表名： 业务名称_表的作用 : token_task/ reader, mpp_config
9.一定要在表字段后面加注释
10.商品类目名称使用很高的话， 直接在查询表中直接添加字段， 避免二次查询：：允许适当的冗余，以提高SQL速度
11.分库分表， 三年的数据量估计才会进行把
12.适当的字符存储长度， 比如人的年龄， unsigned tinyint 0-255 肯定不会超过这个的

索引规范

1.组合主键也要加入唯一索引， 组合字段进行唯一索引
2.了解太少了

SQL规范

1.用isnull() 进行判断count(*)获取行别用count()获取
2.分布式环境下别用外键进行关联， 所以为了方便以后都不用外键进行关联
3.分页查询之前要count()一下
4.Sum(col) 如果数据不存在则会返回null 再sum的时候要进行npe判断
5.禁止使用存储过程， 因为存储过程难以调试和扩展？？？？？
6.In后面的数量级一定要小， 当然尽量不用是最好的
7.编码问题， 如果国际化的话就要用utf-8编码， 所以统一直接用它就好

ORM规范

1.ResultClass一作为返回参数， 一定用resultMap进行返回参数的操作
2.不要用${}进行拼接， ${}一般插入在自己人输入参数的时候， 因为${}很可能出现SQL注入问题
3.Pojo类的Boolean属性不能加is， 数据库字段则要加is_
4.不允许拿HashMap与hashtable作为结果集的输出
5.更新数据的时候要对应着gmt_modified进行更新操作
6.关于事务不能乱用关于事务很匮乏
7.binlog是sql进行存储日志的一个东西，所以我们要注意在更新操作的时候别写的大而全， 单一话就好， 于是禁止使用自动生成工具

工程规范

1.什么不一样， 注意下 dao层还可以放其他部门的rpc接口和其它公司的HTTP接口
2.Web层是做基本参数校验， 一般不复用， service是逻辑服务层。
3.Manager层主要作用是 join操作的替代， 事务控制不会失效
4.所以四层和三层的规范还是要注意点， 区别点， 如果不是有用到事务， 查询的时候没有用到存储过程并且查询量又很大的情况下， 就不要用四层了。
5.分层领域模型规范:
(1)DO和数据库表一一对应
(2)Query 将请求参数进行查询封装， 一般查询参数超过2个的时候用的
(3)DTO/BO/VO 对于一般情境下都差不多

二方库

1.类似指在maven这种工具下对于， com.公司.业务线。自业务线
2.版本号：
(1)主版本号： 不兼容的接口， 增加了改变产品方向的新功能
(2)次版本号： 向下兼容的功能
(3)修订号：修复bug，
3.二方库的线上版本不要依赖与snapshot版本因为snapshot版本会更新一次就让依赖者一直更新， 如果release的话就反过来，而且也可以加快编译时候的打包构建
4.如果二方库jar功能点的jar进行改变是正常的， 但是如果其他非功能点的jar也改变了， 也就变得不正常了， 所以要用dependency：resolve进行对比， dependency：tree进行找出差异点， 进行《excludes》进行排除jar 包
5.依赖maven库的时候一般要定义一个共同的版本号， 避免jar包冲突问题
6.二方库都该可追溯源头。

服务器规范

1.高并发情境下， 因为服务器可能因为连接数太多而无法建立新的连接， 所以我们应该在需要的服务器上面调小等待时间， 让用户今早知道无法建立连接， 进行再次发送请求， 好吧这里服务器问题还是比较懵逼， 太牵强了， 需要补充点专业知识， 关于服务器和数据库， 编译原理等都需要进行再次的了解
2.OOM表示内存溢出， 所以设置服务器进行dump堆信息是很有必要的， 一般在数个月一次。 对于现场信息进行排错是非常又必要的

安全规范

1.对于用户个人页面必须进行权限校验。 就是说权限这块要很注意， 不能让用户拥有多余的权限
2.敏感数据要脱敏， 就是指如手机号码要在中间点改成** 去表示
3.对于用户请求传入的参数都要做有效性的验证，
(1)page size如果过大就可能导致内存溢出
(2)恶意地order by加dos 攻击地话 很容易导致数据库慢查询
(3)任意重定向， 有些网页不能开发， 不能让用户重定向到该网页， 所以要对url进行重定向地判断
(4)Sql注入问题， 要在前端进行校验， 然后mybatis都有做校验
(5)反序列化注入。。。这就有点懵逼了
4.HTML页面地输入框都要进行校验， 这点h5上就有很好地诠释
5.发帖， 发邮件， 发即时性地消息都要防止违纪地词， 广告， 黄等地风控。
6.很多技术点都很难要求做到。 只能略懂一点， 关于安全方面， 还有垃圾短信邮件等的校验需要进行监督模型的建立， 反序列化，前端校验， 需要对前端只是有一点了解才性， 其他的话， 安全问题， 则是在编译原理等需要多加了解。