摘要：在关键步骤上要添加日志异常分支必须增加日志，比如throw抛异常的地方，打印出关键信息，提升问题定位效率日志描述信息用英文，不要用中文，防止不同编码导致乱码问题一般只在开发中打印的日志会用debug打印，线上日志debug级别的一般会设置不打印出来，不过上线前
开发中合理添加注释，提高代码的可读性和易读性
开发中要合理添加 info、error 日志，方便线上问题定位
在关键步骤上要添加日志异常分支必须增加日志，比如throw抛异常的地方，打印出关键信息，提升问题定位效率 日志描述信息用英文，不要用中文，防止不同编码导致乱码问题 一般只在开发中打印的日志会用debug打印，线上日志debug级别的一般会设置不打印出来，不过上线前还是建议删除开发中调试的日志日常开发中哪怕是不断在开发新需求，但我们至少有一半的时间都是在阅读老的代码，想要提高代码可维护性，那可读性就很重要。
就像Martin Fowler在《Refactoring: Improving the Design of Existing Code》中提到的：“任何傻瓜都能写出计算机能理解的代码，但只有优秀的程序员能写出人类能理解的代码。”
所以一定不要按照需求文档一步一步的去写出面条式的代码，多去抽离和提取。
每个函数不要太长函数参数不要超过3个，多个参数可以定义成单独的对象传递复杂的参数可以封装成上下文context对象里再嵌套其他实体对象，利用引用数据类型的特点，单独的方法中也不需要在额外return出结果，后续其他方法中通过context对象就可以直接获取其他方法中处理过的最新的数据可读性比节省的那点性能重要，比如在同一个for循环中去同时做两件不同的事，看似只用1次循环节省了点性能，实际可读性变差了一些DTO、entity对象附属的判断、赋值之类操作可以直接封装在实体对象里面 保持简单，不要炫技，如果一眼就能让人看明白的，就不要去写出需要别人想半天才能明白的代码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))}if (!"YEAR".equals(request.getUnit)) {}以上就是开发中总结出来的有利于提高代码优雅性、可维护性的一些地方，其中最重要的我觉得还是可读性那一点，代码可读性太差，实际是给团队后续开发中埋坑，优化在平时，没有那个团队会说我专门给你一个月来优化之前的代码，所以在日常开发中就要多注意可读性问题，不要写出几天之后自己都看不懂的代码。
来源：小思说科技
免责声明：本站系转载，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与本站联系，我们将在第一时间删除内容!
