代码规范评审

责任心（Owner心态）

以业务产出价值为目标，实现个人价值成长，要求每位同事都拥有主人翁意识对待工作中的所有问题。
意识上坚信自己，态度上富有责任心。

编码规范

因团队成员原来背景各不相同，风格迥异，为了提升整个团队的效率，提升团队凝聚力，在此约定相应的规范让大家遵守，一定程度上减少沟通成本，减少各种不必要的出错概率

Java语言规范

1、代码格式化，统一使用IDEA初始安装后默认的格式，避免使用自定义格式插件，避免代码合并时diff过多，代码提交到Git仓库之前，都需要格式好，记住格式化快捷键，养成随时格式化的习惯
2、接口和实现类，避免处处都是接口，如果预想某个接口几乎不会出现多态实现，尽量就不用接口，直接使用实现类Service即可
3、不要使用一个常量类维护所有常量，按常量功能进行归类，分开维护
类内共享常量，直接在类内部private static final定义
工程内部共享常量，考虑放在当前工程的constant目录下
跨应用共享常量，考虑放到公共的库中，以.jar形式引用
3、Long初始赋值时，使用大写的 L
4、如果变量值仅在一个范围内变化，且带有名称之外的延伸属性，要定义为枚举类
5、IDE的text file encoding设置为UTF-8；IDE中文件的换行符使用Unix格式， 不要使用 Windows 格式
6、Object 的 equals 方法容易抛空指针异常，应使用常量或确定有值的对象来调用 equals，类似方法同理
7、关于基本数据类型与包装数据类型的使用标准
所有的POJO类、DO类属性必须使用包装数据类型
RPC方法的返回值和参数必须使用包装数据类型
8、同名方法应该按顺序放置在一起，便于阅读
9、任何类、方法、参数、变量，严控访问范围，private、protected、public审慎使用
10、其他具体的类库使用上的坑，或常犯的错，大家尽量规避（后续可以整个Bad Case集），比如线程不安全的类、高并发锁时序等问题
11、在 if/else/for/while/do 语句中必须使用大括号。即使只有一行代码，避免采用 单行的编码方式:if (condition) statements;
12、循环体中的语句要考量性能，远程调用、数据库操作尽量移至循环体外处理，或能明确性能瓶颈
13、多加注释，英文说不明白，用中文注释把逻辑说清楚，代码修改的同时，注释也要进行相应的修改。注释的要求：一、能够准确反应设计思想和代码逻辑；二、能够描述业务含义，使团队其他成员能够迅速了解到代码背后的信息。注释也是给自己看的，即使隔很长时间，也能清晰理解当时的思路。好的命名、代码结构是自解释的，注释力求精简准确、表达到位
14、TODO、FIXME等特殊注释标记，注明标记人和时间
15、避免对大段代码进行try-catch，这是偷懒不负责任的表现，catch时分清异常类型
16、防止NPE，是最基本素养，注意NPE产生的场景
17、避免出现大段大段重复的代码，想办法合并它
18、在代码中使用“抛异常”还是“返回错误码”原则
应用内部推荐异常抛出
对外的 http/api 开放接口必须使用“错误码”
跨应用间RPC调用优先考虑使用Result返回结构体方式，封装处理状态、错误码、错误信息

工程项目规范

1、工程项目名，尽量想一些有意义、有传播价值的名称；比如星球、游戏、名人、名地名等；取名就跟给孩子取名一样，独特、有价值、有意义、好传播
2、所有的类都必须添加创建者和创建日期
3、所有代码：包括项目代码、测试代码、临时性代码、脚本统统加入Git仓库进行版本管理，避免误删除、误操作丢失
4、项目需要有单元测试，测试覆盖度70%，测试代码放到单独的src/test/java工程目录下，单测也要入Git仓库管理

工程目录规范

项目名（项目根目录）
|
+---bin
|   |   build.sh
|   |   control.sh
|   |   deploy.sh

+---lib
|   |   项目xxx.jar

+---logs
|   |   app.log
|   |   error.log

+---config
|   |   prod.conf
|   |   dev.conf

命名规范

代码命名
1、无特殊要求，项目都统一创建在miracle组下： http://devops-gitlab-dev.wanda.cn/miracle，个人名下的项目，禁止作为协同开发的git路径，更禁止作为上线项目。
2、代码中的命名均不能以下划线或美元符号开始，更不允许直接使用中文的方式。代码中的命名避免使用拼音与英文混合的方式，如果不知道如何表示，建议多查查翻译软件
3、类名使用UpperCamelCase风格，必须遵从驼峰形式，但以下情形例外：DO / BO / DTO / VO / AO
4、方法名、参数名、成员变量、局部变量都统一使用 lowerCamelCase 风格，必须遵从驼峰形式
5、常量命名全部大写，单词间用下划线隔开，力求语义表达完整清楚准确，细粒度，不要嫌名字长；比如MAX_COUNT适当细分为MAX_XXX_COUNT，MAX_YYY_COUNT
6、抽象类命名使用 Abstract 或 Base 开头；异常类命名使用Exception结尾；测试类命名以它要测试的类的名称开始，以Test结尾
7、POJO类中布尔类型的变量，都不要加is，否则部分第三方框架解析会引起序列化错误
8、包名统一使用小写，点分隔符之间有且仅有一个自然语义的词汇
9、杜绝不规范的简写，避免望文不知义；比如configure简写为config、cfg、conf都可以，con就不合理
10、如果模块、接口、类、方法使用了设计模式，在命名时体现出具体模式；比如OrderFactory，AgentProxy
11、枚举类名建议带上 Enum 后缀，枚举成员名称需要全大写，单词间用下划线隔开
12、领域模型命名规约：
数据对象：xxxPo，xxx即为数据表名, 对象属性和表字段对应；
数据传输对象：xxxDto，xxx为业务领域相关的名称，前端向后端传递对象，GRPC，及其他数据对象传输统一使用Dto后缀；
展示对象：xxxVo，xxx一般为view名称;
业务处理对象：xxxBo，xxx为业务领域相关的名称.

接口规范

接口设计原则

接口设计应立足于本服务自身，服务核心提供什么对外的能力，接口用于匹配自身的能力，接口设计以通用为准，避免被需求牵着走，提供一大堆极度相似的接口给维护带来困难。
接口设计需考虑安全问题及权限问题，接口设计需避免可遍历的访问
接口的入参必须检查及有效性验证，非法参数必须拒绝，并返回相应错误信息
部分接口，需有防重限制，访问量限制，验证码限制等，避免被滥刷，造成资损

接口格式：JSON

{
status: string
code: string,
message: string,
data: {
//具体交互的数据
}
}

//说明
status 通讯状态
code 业务返回码
message 业务返回消息
data 详细交互数据

接口常驻字段

接口将采用统一的格式，包括接口头、接口数据体，
接口头包括：调用方识别码、调用方服务ID、签名、秘钥、traceId、logId、wd_uid（万达统一用户ID）
接口数据体：如上JSON格式
详细待设计

接口命名

原则能从接口路径，名称上反映核心功能

数据库规范

数据库设计

建表规约

因为不同操作系统Windows/Linux/Mac区分大小写规则不同，统一使用小写
1、表名必须使用小写字母或数字，表名不使用复数名词，禁止出现数字开头，表名尽量能清晰表达业务作用
2、字段名必须使用小写字母或数字，中间可用下划线连接。通过字段名比较自然实现跟java字段的无缝映射，字段名需要有字段注释Comment
3、主键索引名为 pk_字段名；唯一索引名为 uk_字段名；普通索引名则为 idx_字段名
4、如果存储的字符串长度几乎相等，建议使用char定长字符串类型
5、可变长字符串使用varchar，超长文本，比如超过5K，建议使用text
6、物理字段，id、create_time、modify_time，valid(是否有效 0 无效 1有效)为必备字段，所有表都加上
7、单表超500万行或容量超2G，建议分库分表
8、选择合适的字段存储长度：比如char表示少量枚举，unsigned tinyint表示范围0~255；unsigned smallint 表示范围0~65535；别动不动全都使用integer
9、所有的字符存储与表示，均以utf-8编码

索引规约

1、业务上具有唯一特性的字段，即使是多个字段的组合，也必须建成唯一索引
2、模糊查询，建议走搜索引擎，比如ES
3、验证查询效率效果，多用explain
4、建组合索引的时候，区分度最高的在最左边
5、索引以适度为原则，覆盖60%~80%的查询逻辑为宜，避免缺少索引或过度加太多索引

SQL规范

1、查询是可以适当使用ISNULL()来判断是否为 NULL 值
2、不要使用 count(列名)或 count(常量)来替代 count(*)，count(*)会统计值为 NULL 的行，而 count(列名)不会统计此列为 NULL 值的行
3、不得使用外键与级联，一切涉及到外键逻辑必须放到应用层解决
4、删除和修改记录时，要先select，避免出现误删除，确认无误才能执行更新语句。(适用于登录到MySQL客户端操作时，要谨记)
5、IN操作，控制集合元素范围在1000个之内，否则尽量避免使用IN
6、更新数据表记录时，必须同时更新记录对应的 modify_time 字段值为当前时间

ORM映射相关

1、POJO 类的布尔属性不能加 is，而数据库字段必须加 is_，要求在 resultMap 中进行 字段与属性之间的映射。
2、配置映射关系，使字段与DO类解耦，保持每个DO类跟每个表字段一一对应
3、sql.xml 配置参数使用:#{}，#param# 不要使用${} 此种方式容易出现 SQL 注入
4、不允许直接拿HashMap或Hashtable作为查询结果集的输出，因为映射过程中值的类型不可控
5、@Transactional事务不要滥用，事务会影响数据库的QPS，事务的作用域必须尽可能小。同时使用到事务的地方需要考虑关联系统的回滚，比如缓存回滚、统计修正、消息补偿等。

Java阿里代码规范插件

IDEA安装该插件

打开IDEA，File-> Setteings->Plugins->Browse Repositories，在Browse Repositories搜索栏搜索Alibaba，然后安装Alibaba Java Coding Guidelines
下载本地zip文件，下载地址：Alibaba Java Coding Guidelines - IntelliJ IDEs Plugin | Marketplace
下载版本 Alibaba Java Coding Guidelines 2.1.1
打开IDEA，File->Settings->Plugin->Install plugin from disk，选择刚才自己下载插件zip包的地址

前端研发规范

1、无特殊要求，项目都统一创建在fe组下： http://devops-gitlab-dev.wanda.cn/fe
2、项目名称全部采用小写，以下划线分割。如my_project，目录命名全部采用小写，以下划线分割。有复数结构时，要采用复数命名法。
3、详细规范遵循： 前端代码规范 V1

日志规范

日志很重要，需要统一定义日志格式规范
1、必须要有日志、必须要有日志、必须要有日志
2、日志要能清晰反映程序运行状态、上下游链路调用处理过程、核心逻辑
3、日志必备字段：日志级别、时间戳、服务名、IP、调用方、TraceId、日志主体
日志格式：

4、谨慎记录日志，生产环境避免输出debug日志，有选择地输出 info 日志，注意日志输出量的问题，避免无意义的大段不可阅读的日志。大量地输出无效日志，不利于系统性能提升，也不利于快速定位错误点

三方套件：滴滴Logi日志服务套件

CodeReview规范

1、大型项目，增加/修改超过10个文件或超过500行代码的，需组织CodeReview会议，邀请相关同事及高阶同事参与代码Review
2、小型项目，小需求修改，（少于10个文件变更或500行代码的）至少需要2~3位同事帮忙进行代码Review并提出点评建议
3、重点逻辑，建议找相关同事共同Review一下

规范插件

1、Java开发手册（嵩山版）.pdf

2、Java开发手册（嵩山版）〉灵魂17问.pdf

3、p3c-master.zip