注释?

开发中合理添加注释，提高代码的可读性和易读性

1. 在类、接口、方法、属性、代码块、有特殊逻辑的地方都要添加注释说明
2. 推荐中文注释，减少理解成本
3. 遵循 javaDoc 注释规范，除方法内的代码块用 // 注释，其他地方推荐 javaDoc 注释

日志

开发中要合理添加 info、error 日志，方便线上问题定位

1. 在关键步骤上要添加日志
2. 异常分支必须增加日志，比如throw抛异常的地方，打印出关键信息，提升问题定位效率
3. 日志描述信息用英文，不要用中文，防止不同编码导致乱码问题
4. 一般只在开发中打印的日志会用debug打印，线上日志debug级别的一般会设置不打印出来，不过上线前还是建议删除开发中调试的日志

命名

1. 不能太随意，反例：BaseResultMap1、param1
2. 能正确区分含义和功能
3. 拼写要正确，反例：supper => super

代码可读性

日常开发中哪怕是不断在开发新需求，但我们至少有一半的时间都是在阅读老的代码，想要提高代码可维护性，那可读性就很重要。

就像Martin Fowler在《Refactoring: Improving the Design of Existing Code》中提到的：“任何傻瓜都能写出计算机能理解的代码，但只有优秀的程序员能写出人类能理解的代码。”

所以一定不要按照需求文档一步一步的去写出面条式的代码，多去抽离和提取。

1. 每个函数不要太长
2. 函数参数不要超过3个，多个参数可以定义成单独的对象传递
3. 复杂的参数可以封装成上下文context对象里再嵌套其他实体对象，利用引用数据类型的特点，单独的方法中也不需要在额外return出结果，后续其他方法中通过context对象就可以直接获取其他方法中处理过的最新的数据
4. 可读性比节省的那点性能重要，比如在同一个for循环中去同时做两件不同的事，看似只用1次循环节省了点性能，实际可读性变差了
5. 一些DTO、entity对象附属的判断、赋值之类操作可以直接封装在实体对象里面
6. 保持简单，不要炫技，如果一眼就能让人看明白的，就不要去写出需要别人想半天才能明白的代码

条件判断

• 1、判空统一用 StringUtils、CollectionUtils 这类官方库 如字符串判空项目中有自己判断的，有用 hutool 的，推荐统一使用 Apache 的 StringUtils 来判断，多条判断可以用 isAnyBlank、isAnyEmpty 合并，反例：

if (str == null || str.isEmpty()) {}
if (StrUtil.isNotBlank(testDO.getName())) {}

• 2、复杂判断抽成单独的方法，比如抽成单独的assembler静态方法，这样也很方便单独针对判断逻辑来写单测测试，反例：

if (queryEntity.getId() == null && queryEntity.getName() == null && queryEntity.getUserId() == null && (queryEntity.getAge() > 0)) {
    return true;
}

• 3、if 判断不要嵌套太深 可以提前 return 来减少 if 嵌套层级，也可以利用 switch、策略模式、提取单独的方法简化逻辑
• 4、多用 StringUtils.defaultString、ListUtils.emptyIfNull 简化代码：

if (CollectionUtils.isNotEmpty(testList)) {
    for (Item item : testList) {
        item.setNickName(StringUtils.isEmpty(item.getName()) ? "" : item.getName())
    }
}

可以简化成：

for (Item item : ListUtils.emptyIfNull(testList)) {
    item.setNickName(StringUtils.defaultString(item.getName()))
}

代码逻辑

1. 方法职责单一，尽量保证每个方法只做一件事
2. 转换代码抽到单独的 Assembler 里
3. 无用的代码直接删除掉，除非确实容易埋坑的代码可以注释掉保留
4. 消除魔法值，可以定义成公共/局部常量、枚举，反例：

if (!"YEAR".equals(request.getUnit())) {}

单测

1. caseDesc 里清晰描述每条用例
2. 用例文件名命名有意义，反例：success1.json5、fail2.json5
3. 所有外部依赖数据要全部 mock 掉
4. 尽量覆盖所有场景的用例，单测实际能检测出大部分的问题
5. 不像前端开发中基本不会单独写单测，后端开发实际很依赖单测来自测，所以要重视单测

以上就是开发中总结出来的有利于提高代码优雅性、可维护性的一些地方，其中最重要的我觉得还是可读性那一点，代码可读性太差，实际是给团队后续开发中埋坑，优化在平时，没有那个团队会说我专门给你一个月来优化之前的代码，所以在日常开发中就要多注意可读性问题，不要写出几天之后自己都看不懂的代码。