Raytron实习
Raytron实习
Java编码规范
编程规约
- 命名不要以下划线或美元符号开始,也不要以下划线和美元符号结束
- 类名UpperCamelCase,参数、方法名lowerCamelCase,常量名全部大写单词间下划线隔开
- 抽象类使用Abstract或Base开头,异常类使用Exception结尾
- 使用类型中括号紧挨的形式定义数组
- 布尔类型不要用is开头
- long或Long赋值时,数值后使用L,小写不容易区分;浮点同理
- 常量类要分类,不要写到一个里面
- 变量值仅在一个范围内,使用enum枚举
- 空格和换行的使用
- 空大括号{},不需要加多余空格;空代码块:左大括号前不换行,左大括号后换行,右大括号前换行,右大括号后还有else等不换行,表示终止的右大括号必须换行
- 左右小括号内部和字符之间不需要空格,但是左大括号前需要空格
- if / for / while / switch / do 等保留字与左右括号之间必须加空格
- 任何二目、三目(几目代表需要几个运算数)运算符的左右两边都需要加一个空格
- 采用4个空格缩进,禁止使用Tab
- 单行不超120个字符,若超过遵循换行规则:第二行相对第一行缩进4个空格,运算符与下文一起换行,方法调用的点符号与下文一起换行,方法调用中的多个参数需要换行时在逗号后进行,括号前不要换行
- 相同参数类型,相同业务含义才可以使用可变参数(...),参数类型避免定义为Object
- 使用常量调用equals来检测相同,比如“test”.equals(),避免空指针
- 整形包装类Integer的比较,全部使用equals方法比较
- 人恶化货币金额,均使用最小货币单位
- 浮点数基本数据类型不能用 == 判断相等,包装类不能用equals判断
- BigDecimal使用comepareTo方法判断,而不是equals;使用String转化BigDecimal对象,别用Double
- POJO必须加toString方法,如果继承了先super.toString();POJO类中不能同时用isxxx和getxxx获取属性
- 日期格式化时,传入pattern中表示年份统一使用小写的y(yyyy表示当天所在的年,YYYY表示当周所在的年,如果跨年就表示下一年)
- M表示月份,m表示分钟,H是24小时制,h是12小时制
- 获取当前毫秒数:System.currentTimeMills()
- 不允许程序任何地方使用 java.sql.Date,java.sql.Time,java.sql.TimeStamp
- 禁止程序中写死一年为365天,避免公历闰年出现日期转换错误或程序逻辑错误
- 覆写equals就必须覆写hashCode;因为Set存储的是不重复的对象,依据的就是这俩方法,所以必须重写;如果自定义对象作为Map的键,那么也必须覆写这两个方法
- 使用isEmpty()判断集合是否为空,不要使用size() == 0
Java代码评审
一、Java Review
(一)通用
【强制】代码提交前格式化后再提交。
【强制】不可以大量拷贝代码,又不做细节调整。
【推荐】善用 IDE 智能提示信息,尽可能修复警告信息
【推荐】不需要的代码建议删除。
(二)变量
【强制】每个变量命名必须有实际意义,不可以随便使用 i、j、temp 等通用变量。
【推荐】变量定义位置尽可能贴近其使用位置。
(三)函数
【推荐】对外提供的函数接口,应进行详细的注解说明,说明返回的数据类型和特殊情况处理。
【推荐】对内部函数要抛出异常,而不是使用错误码。
【推荐】函数的命名是否清晰地定义了实现功能,且一个函数应只实现一个功能。
【推荐】函数长度如果过长( 大于 80-100 行),应尝试进行优化,将公用部分提取到别的函数或者专门的服务中。
【推荐】对入参进行有必要验证,考虑其边界值,对外接口,需要有 null 验证。
【推荐】不要返回 null 数组/集合。应使用 Collection. EmptyList () 等静态方法返回空集合。
【推荐】函数要有抽象层级,自顶向下阅读:向下规则。
(四)类
【推荐】类的命名是否清晰定义,直接表达其功能,如果使用设计模式在类名上应有所体现。
【推荐】类的设计要短小、内聚(内聚会促进短小)、单一职责(只有一个修改的理由)。
(五)设计
【推荐】遵循代码分层:
Controller :处理入参、调用服务、封装出参,禁止直接调用持久化层(JPA、Mybatis、...)
Service :被 Controller 调用,实现具体业务
持久化层:数据持久化、访问
【推荐】业务代码是否尽可能的封装,类和函数实现上保持简洁,不要太重。
【推荐】不要有反思维的系统设计。使用大多数人容易理解的逻辑处理问题。如果有通用的算法模型除外。
【推荐】不要有明显的性能问题。比如大量的数据库交互、文件交互、RPC 接口交互。
【推荐】调用第三方的接口和第三方类方法,是否捕获了所有异常。
【推荐】对内提供的微服务接口统一使用 Response 类和 RespCode 响应码。
【推荐】对外接口使用可处理的返回码,而不是抛出 Exception。
【推荐】可能被重复调用的接口,应考虑其是否实现幂等性。
【推荐】使用注解的作用范围尽可能小,如@Transactional 注解,类似的,多线程中加锁代码块尽可能小。
【推荐】系统内部函数参数,编写相应的 dto,vo,do,禁止使用 json。跨服务调用常用接口,也应该编写相应的 dto。
【推荐】try-catch 代码块容易使代码混乱,可以将 try 内部的内容封装成函数。
【推荐】多使用 AOP,剥离通用业务
(六)复杂性
【推荐】代码行数过长,嵌套过深(不超过 3 层),适当考虑优化。
【推荐】反转 if 语句减少嵌套。
(七)性能
【强制】循环中通过 SQL 获取数据时需要谨慎,对性能影响较大,尽量少用。
【强制】批量写入、删除 SQL 数据时,不要遍历执行,使用 batchSave 、batchDelete 批量方法,遍历执行性能很差。
【强制】数据分页,数量较少时通过 sql 语句分页,或者使用数据库组件(Mybatis plus,pagehelper)实现自动拦截分页。如果要查询的数据很多 (百万级别),使用延迟加载的 sql 语句编写分页。
【强制】注意释放已申请资源(网络、文件等)。
【推荐】避免循环引用,会导致序列化失败。
(八)日志
【强制】禁止使用 System. Out 打印日志。
【推荐】日志框架打印时,注意日志级别:
Debug: 调试数据打印,可以比较密集,仅在开发、测试环境输出
Info:打印核心业务、对外接口、三方服务调用的开始、结束位置、关键参数,可在生产环境输出
Warn:程序执行出错,但是错误是业务可预见、可接受,所有环境允许输出
Error:程序执行出错,错误业务不可接受(常见在 catch Exception 中打印),所有环境允许输出
【推荐】避免过度输出日志记录。
二、Commit Review
(一)提交原则
单一提交:一个 commit 变更应该以一个功能、一种类型的修改为主。多次提交可以保证每次修改可以正确记录和错误回滚。
以下分类不要同时提交。修复 BUG、新功能、修改原接口、重构、代码格式化
在定义完一系列接口、修复完一个 BUG 等情况即可提交。
完整性:一个 commit 提交后,程序应该仍然可以正常运行。
不要提交过于小且没有完整意义的 commit。
Git使用规范
类型
在commit提交内容前面加上:
- feat 新功能、新特性。
- update 局部代码修改。
- fix 修复问题。
- docs 文档更改。
- style 代码格式(空白、格式化、缺少分号等)。
- refactor 代码重构(在不影响代码内部行为、功能下的代码修改)。
- perf 改进性能(在不影响代码内部行为的前提下,对程序性能进行优化)。
- test 添加确实测试或更正现有的测试。
- chore 非功能代码,例如 CI/CD 、构建脚本、配置文件、依赖项版本等。
- revert 撤销 commit 提交。
- release 发布新版本
build 项目构建或依赖库修改。ci 持续集成文件和脚本(示例范围:Travis、Circle、BrowserStack、SauceLabs)。