1.背景
1.1 愿景
编码是一门艺术,优雅编码,规范编码,愿大家早日成为艺术大师。
1.2 适用读者
- 初中级程序员,参考编码的一些规范和建议。
- 代码审批人员,审核代码时,一些参考的指标和方向。
- 本文所举例的代码缺陷,改造参考方向,难免存在理解错误或偏差之处,欢迎批评指正。
- 本文中所举案例,主要是用于记录作者在开发中遇到的一些不规范现象,一些编码技巧及调优方向,随着时间沉淀会持续总结和更新。
2. 非规范案例
Set 集合去重
项目 | 描述 |
描述 | 申明一个对象,如xxxDto,却未申明去重的参考标准。Set<xxxDto> xxxSet = new HashSet<>(); |
潜在风险 | 集合不会去重,或去重与业务需求不一样。 |
调整方案 | xxxDto类,重写equal,hashCode方法。参考: Set去重问题 。 |
备注 | 暂无。 |
避免采用反逻辑运算符
项目 | 描述 |
描述 | 代码中存在大量判空集合:if(!CollectionUtils.isEmpty(reqDto.getList()) |
潜在风险 | 反逻辑,容易造成理解偏差; |
调整方案 | 推荐使用: org.apache.commons.collections.CollectionUtils.isEmpty() org.apache.commons.collections.CollectionUtils. isNotEmpty() |
备注 | 《java开发手册》-控制语句-11 |
集合函数为空返回null
项目 | 描述 |
描述 | 参考代码:获取list数据,为空时返回null |
潜在风险 | 可能导致NullPointExcepetion |
调整方案 | 推荐使用: return Collections.emptyList(); |
备注 | 明确单个对象,为空返回null;集合时不要返回null; |
慎用BaseController
项目 | 描述 |
描述 | 每一个controller对外暴露接口时,可能存在异常等情况,或分页等通用的一些功能。编写BaseController,让其他Controller去继承。 |
潜在风险 | BaseController功能需要业务Controller去继承,造成代码冗余且不便扩展。 |
调整方案 | 编写统一的WebMvc配置类,基于 @RestControllerAdvice(annotations = RestController.class)做异常兜底处理。 |
备注 | 基于BaseController的模式:非常外行。 |
java 8的LocalDate代替Date
项目 | 描述 |
描述 | 日期,时间,大量基于Date做日期处理 |
潜在风险 | Date是存在多线程不安全性。 |
调整方案 | 建议使用LocalDate 扩展了解java 8的一些新特性,基于java 8编码。 |
备注 | Java 18都出来了,先进入java 8吧,一定要快!!! |
枚举类使用
项目 | 描述 |
描述 | 可列举的变量大量使用了静态字符串。如 4表示审批中,直接定义了静态变量值为4。 比较数据是否为某一种类型时,直接使用魔法值处理。如:getStatus()==4。 |
潜在风险 | 避免使用魔法值,避免使用静态字符串,变量混用容易造成业务混乱; |
调整方案 | 全局统一的一些状态,变量等使用枚举值统一控制。针对状态值,建议使用枚举。 且枚举申明要满足规范,定义变量值时,定义为final。 |
备注 | 枚举扩展性高,便于做类型判断 |
代码注释规范
项目 | 描述 |
描述 | 注释,命名等大量非规范的情况。如: 函数命名不规范,错误的定义返回类型; 代码注释不完整,在接口的实现类上写注释; |
潜在风险 | 错误或混乱的注释,造成代码可读性变差。 |
调整方案 | idea安装 Alibaba Java Coding Guidelines 插件 安装阿里巴巴编码规范插件,可以自动识别不规范的编码。 |
备注 | 1.代码注释格式要统一 2.变量命名应遵循规范,统一定义规则,如驼峰。 3.混乱的编写注释,显得外行。 |
命名规范性
项目 | 描述 |
描述 | 外部系统,或部分业务对象,命名混乱。 如is_enable,a_b_ddd; 部分函数,接口,类等命令不具有可读性,命名不规范; |
潜在风险 | 代码可读性差; |
调整方案 | 建议统一使用驼峰命名方式。对接外部系统或特殊情况: 1.可在对应变量上编写@JsonProperty做自动转义; 2.若驼峰需要转换下划线,编写统一工具类实现 |
备注 | 命名请参考:《java开发手册》-命名风格-1 |
@ResponseBody使用混乱
项目 | 描述 |
描述 | 在Controller中,定义对外提供的api接口时,在方法上,在类上混乱使用@ResponseBody的情况 |
潜在风险 | 带偏新同事; |
调整方案 | 参考@restController的作用,可不必写@ResponseBody 默认就是返回json对象。 |
备注 | 使用注解时,了解该注解的使用场景,不要滥用。 |
String字符串非空拦截
项目 | 描述 |
描述 | String 字符串非空使用@NotNull |
潜在风险 | 若是空字符串,拦截失效 |
调整方案 | 根据业务场景,建议使用@NotBlank |
备注 | 暂无 |
验证完整性问题
项目 | 描述 |
描述 | 功能验证逻辑写在前端,后端提供的接口,未编写逻辑验证; |
潜在风险 | 前端验证失效时,或直接调用接口时,造成业务异常。 |
调整方案 | 验证逻辑: 后端一定要编写严格的业务验证; 前端做第一层验证,后端要编写第二层验证,数据层做第三次验证; |
备注 | 暂无 |
深拷贝问题
项目 | 描述 |
描述 | 使用序列化做深拷贝对象的处理。 将对象转换为json字符串,将字符串再转换为对象。 |
潜在风险 | 降低了函数的性能。 |
调整方案 | 1.避免在循环中,采用序列化做深拷贝。 2.设计功能时,部分逻辑是可以不用深拷贝实现的,应避免。 |
备注 | 字符串做深拷贝,性能不好。 |
数据库字段类型规范定义
项目 | 描述 |
描述 | 态类型字段避免使用varchar存储; 日期使用date,不做默认值设置等; |
潜在风险 | 不合理的数据类型,在数据表后续优化时,如建立索引,会造成空间浪费,性能差等情况。 |
调整方案 | 1.类型字段:建议使用tinyint。避免浪费数据库资源。 2.建议非特殊业务字段,所有字段设置默认值,不允许为空。 |
备注 | 新建数据表时,考虑数据的可能情况,用合理的最小的空间,建立数据字段。 新建数据表时,考虑该表的业务使用场景,构建好唯一索引,普通索引。 |
数据表关键字作为字段名称
项目 | 描述 |
描述 | xxx表中的state字段。 |
潜在风险 | 造成部分场景下,sql识别失败。 |
调整方案 | 避免使用数据库关键字。 |
备注 | 暂无。 |
布尔字段申明为isXXX
项目 | 描述 |
描述 | isDetete字段,申明类型为Boolean; |
潜在风险 | 不同序列化工具,产生序列结果不同。 |
调整方案 | 所有字段类型,避免这样的申明。 |
备注 | 《java开发手册》-编程规约-命名风格-8暂无。 |
数据物理删除
项目 | 描述 |
描述 | 数据物理删除,在数据库执行Delete的场景 |
潜在风险 | 物理删除,数据不能留痕。存在误删等巨大的风险。 |
调整方案 | 物理删除,数据不能留痕。存在误删等巨大的风险。 |
备注 | 无 |
字符串代表数组
项目 | 描述 |
描述 | 使用字段如a: a 表示模板id,且表示多个,用逗号隔开; 用一个变量表示集合字段,如:String a="2,3,4"; |
潜在风险 | 不合理的数据类型,代码可读性差,不便于系统扩展和前后端接口对接。 |
调整方案 | 字段表示集合,数组含义时,不要定义为字符串。 建议使用数组,如 String[] reviewTemplateIds; |
备注 | 明确参数类型,不要基于字符串做特殊的处理。不便于功能扩展。(如数组数量@size()限制) |
正确使用事务
项目 | 描述 |
描述 | 事务使用的场景,格式不对,显得混乱; |
潜在风险 | 编写大事务,系统性能差,占用了数据库资源。 |
调整方案 | 1.避免编写大事务,后续数据量大以后,系统性能不好。 2.单表操作,不使用事务。 3.注解使用@Transactional propagation = Propagation.REQUIRED, isolation = Isolation.DEFAULT, 这个配置是系统默认的,可不编写。 4.注意事务传递性等 |
备注 | 注意事务的传递性,慎用。 |
正确创建线程池
项目 | 描述 |
描述 | 代码中,存在周期性任务脚本,线程池构建代码:Executors.newScheduledThreadPool(2); |
潜在风险 | 创建不会限制最大线程数,会造成OOM风险。 |
调整方案 | 基于ScheduledThreadPoolExecutor,自定义线程池。 |
备注 | 建议修改,后期数据量大,会造成jvm频繁FullGc,影响性能或造成系统死掉。 |
正确使用异步
项目 | 描述 |
描述 | 异步使用,使用的Spring boot 默认的线程。 |
潜在风险 | 造成OOM风险。 |
调整方案 | 配置自定义线程池,代替默认的线程。参考: Async配置自定义线程池 。 |
备注 | 微服务若使用了@Async,必须配置异步线程池。 |
循环中操作外部资源
项目 | 描述 |
描述 | 直接在循环中,多次操作数据库的情况。如: for(i=0;i<100;i++){ xxxMapper.select(i); xxxMapper.update(i); } 直接在循环中,单次调用远程接口; |
潜在风险 | 严重拉低系统性能,拖死服务。 |
调整方案 | 1.建议将操作的最小模块,独立出来,判断是否可以异步单个处理最小模块。 2.单条数据查询,更新等考虑一次批量处理,获取数据到内存后,在处理。 |
备注 | 采用批量接口做逻辑处理,避免在循环中单条处理。 |
使用非序列化对象做参数
项目 | 描述 |
描述 | 使用非序列化出入参问题,如使用Map结构:Map<String,Object> data |
潜在风险 | 非对象模式,容易引发null等不确定问题。不便于对象的扩展和维护。 |
调整方案 | 采用对象的模式。避免前后过程式处理。 |
备注 | 面向对象编程。 |
大函数问题
项目 | 描述 |
描述 | 部分函数代码太长,表示了多个含义,如500行的功能函数。 |
潜在风险 | 函数功能不唯一,函数逻辑复杂,行数多,不便于后期扩展和维护。 |
调整方案 | 建议一个函数至多50行代码。 1.小函数代表一个明确的功能。 2.多用设计方法达到函数复用,函数剥离的效果。 |
备注 | 先把函数写小,控制行数。 |
3.编码调优参考
数据对象设置安全对象
项目 | 描述 |
描述 | 远程调用其他系统后,业务代码存在重复的判空,验证等流程。如: Response<xxxDto> sampleNumRes = xxxFeignClient.query(xxxxTemp); if(sampleNumRes!=null && sampleNumRes.getData() != null && sampleNumRes.getData().getTotal_num()!=null){ } |
缺陷 | 调用其他API接口,获取数据对象时,总会要做各种判空处理,代码严重冗余; |
调整方案 | 编写:ResponseUtils工具类,并提供安全方法,非安全方法。改造如下: xxxxDto= ResponseUtils.safe(xxxFeignClient.query(xxxTemp)); 基于泛型,穷举判断返回是数组,列表,对象等是否为空。 安全性:接口返回成功,返回的对象最终data是一定存在值的。 非安全性:接口返回成功,返回的对象不一定存在值。 请求异常:调用接口失败,或对方返回非成功状态的信息。直接拦截报错。 |
备注 | 参数代码:
|
判断对象是否为空
项目 | 描述 |
描述 | eqDto.getStatus() != null等判空 |
缺陷 | 暂无 |
调整方案 | 建议使用: Objects.isNull(),Objects.nonNull() |
判断对象是否相等
项目 | 描述 |
描述 | xxx. DISEASE_POSITIVE == xxxDto.getDiseaseType() |
缺陷 | 避免直接使用equal,==比较,对象为空时,报错。 |
调整方案 | 建议采用:Objects.equals() |
集成测试用例代码
项目 | 描述 |
描述 | 系统中无测试用例代码; 存在部分单元测试,缺乏对controller提供接口的集成测试; |
缺陷 | 测试用例未在代码中体现,不能留痕; |
调整方案 | 为每一个controller编写对应的集成测试。 完整验证该接口是否正常。 |
备注 | 强制编写测试用例,便于提高开发人员的自测工作效率,并为后续开发人员,测试人员提供测试参考的示例。 |
巧用反射
项目 | 描述 |
描述 | 如一个对象中,对所有类型为Decimal的字段,统一加密翻译为另外一个字段; 代码遍历处理对象中的所有Decimal字段; |
缺陷 | 功能重复,代码可重用度低,不便于扩展。 |
调整方案 | 针对不同对象,属性字段逻辑处理一致的功能,建议采用反射机制代替穷举模式。 基于反射的模式,批量处理一个对象,做逻辑处理。 |
备注 | 统一处理代替逐个处理,编码时,一定不要写死代码。 |
面向对象编程
项目 | 描述 |
描述 | 许多业务代码,基本是面向过程编码,缺乏对象的封装,抽样,导致代码冗余,过程繁杂。如: 基于if/else,switch等模式做过程是分支; 基于方法编程,未做接口封装; |
缺陷 | 面向过程编码,后期代码缺乏剥离,冗余复杂,难以维护。 |
调整方案 | 建议看看《重构》,《代码整洁之道》,面向对象编码思维。 1.多用设计方法,如模板方法,策略设计模式,代理等替换过程是编码; 2.复杂过程做DDD领域分层,做功能模块化拆分; |
备注 | 实现一个功能,一定要考虑后期的扩展性和可维护性。 |
函数性能考量
项目 | 描述 |
描述 | 许多业务函数,存在性能不高,如重复计算,轮询获取数据等。 |
缺陷 | 低性能函数,拉低系统性能。 |
调整方案 | 编写函数后,建议思考该函数是否还存在性能优化的空间。 1.内存逻辑代替循环取数逻辑。 2.函数功能单一,避免大而全的函数,导致函数性能下降。 |
备注 | 性能考量应该作为代码评审的一个标准。 |
优雅关闭
项目 | 描述 |
描述 | 系统关闭时,还存在运行的异步线程等如何优雅关闭。 |
缺陷 | 不做处理,系统在特殊条件下,存在问题且难以排查。 |
调整方案 | 1.编写全局配置文件,重新实现SmartLifecycle接口,重写stop()方法实现优雅关闭。 2.系统关闭时,系统内部设置等待时间,便于执行未完成的任务。 3.记录关闭时,执行异常的日志信息。 |
备注 | 单个微服务,应包括优雅关闭模块。 |
4.感谢
- 作为一名程序员,您一定在研发过程中,或多或少有过排雷采坑的经历。欢迎留言,分享更多编码调优的经验。
- 本文参考《java-开发手册-泰山版》,《代码整洁之道》,《重构2》等编码规范,编码理论知识。欢迎留言探讨书中的相关知识。