我工作多年，遇到过各种各样的同事。我见过各种代码，优秀的、垃圾的、没有吸引力的等等，所以这篇文章记录了一个优秀的Java开发应该具备哪些良好的开发习惯或最佳实践。
当你的方法参数过多时，建议封装一个对象。下面是反面教材，谁教你写成这样的代码？
public void updateX(long num, String str1, String str2, String str3, String str4, String str5, String str6) {}
尽量把这些输出封装到一个对象中。
public class X { private Long num; private String str1; ...}
为什么要这样写？例如，您的方法用于查询。如果以后添加查询条件，需要修改方法吗？每次添加时必须更改方法参数列表。封装一个对象，以后无论添加多少查询条件，只需要给对象添加字段即可。关键是代码看起来也很舒服！
如果你看过“狗屎山”，你会有很深的感受。这样的方法可以写几千行代码，没有什么规则可言。经常负责人会说，这个业务太复杂了，没办法改进，是偷懒的借口。无论业务多么复杂，我们都可以通过合理的设计和封装来提高代码的可读性。下面是一个建议的代码。
@Transactionalpublic void clearBills(Long customerId) { //获取清算所需的票据ng ClearContext context = getClearContext(customerId); // 验证该金额是否合法 checkAmount(context); // 确定优惠券是否可用，并返回可扣除金额 CouponDeductibleResponse deductibleResponse = couponDeducted(context); // 结清所有账单 DepositClearResponse response = clearBills(context); // 发送还款对账消息 repaymentService.sendVerifyBillMessage(customerId, context.getDeposit()); // 更新帐户余额 accountService.clear(context, response); // 处理已清算的息票，用完或未绑定 couponService.clear(deductibleResponse); // 保存优惠券扣减记录 clearCouponDeductService.add(context, deductibleResponse);}
这段代码中的业务非常复杂。估计内部保守做了一万件事情，但是不同层次的人写的东西完全不一样。不得不赞这个业务的拆分，方法的封装。大企业中有多个小企业。不同的业务可以调用不同的服务方法。
接手的人即使没有流程图等相关文件，也能快速了解业务。初级开发写的很多业务方法都是上一行代码给业务A，下一行代码给业务B，下一行代码给业务A。还有一堆单元逻辑嵌套在业务之间调用，这非常混乱并且有很多代码。
很多人喜欢写这样的代码来判断集合。
if (list == null || list.size() == 0) { return null;}
当然，如果你坚持这样写是没有问题的。
org.springframework.util.CollectionUtils但是你不觉得不舒服吗，现在框架中的任何一个jar包都有一个收集工具类，比如com.baomidou.mybatisplus.core.toolkit.CollectionUtils. 以后请这样写。
if (CollectionUtils.isEmpty(list)) { return null;}
当你的业务方法返回一个集合类型时，请不要返回null，正确的操作是返回一个空集合。看一下mybatis的列表查询。如果没有查询任何元素，它将返回一个空集合而不是 null。否则，调用者必须做NULL判断，大多数情况下对象也是如此。
当然，这是一个有争议的问题，我的习惯是使用它来省略 getter、setter、toString 等。使用Lombok。
为什么要少写一些工具类，因为你写的大部分工具类都包含在你引入的jar包中，比如String、Assert断言、IO上传文件、复制流、Bigdecimal]等等。编写自己的错误并加载冗余类很容易。
写这种注释是不是怕后来接手的人瞎了。
要么不要写它，要么只是在它之后添加一个描述。写这样的注释并从IDEA收到一堆警告很痛苦。
/*** 请求号码验证** @param a* @param b* @param param* @return Result*/
很反感在IDEA代码窗口看到一连串的警告，很不舒服。因为有警告，说明代码可以优化，或者有问题。几天前，我在团队中发现了一个小错误。和我没有关系，只是同事们在外面看业务，判断业务为什么错了。我扫了一眼问题。
因为java中的整型字面量int是类型的，所以它们变成Integer了集合，然后点击它stepId就是一个long类型，而Long在集合中，那么这contains正确返回false了，它不是一个类型。
你看，如果你注意警告，你可以把鼠标移到上面看一下提示，就会少一个生产bug。
我认为这是一个程序员应该具备的素质。反正我喜欢用新的技术部件，因为新技术组件的出现是解决老技术组件的不足，而作为技术人员，我们应该与时俱进。
当然，前提是做好准备，而不是想当然地升级。Java 17 已经发布了最简单的例子，新项目仍然使用Date来处理 DateTime。
点击此处免费领取java资料