我工作多年，遇到过各种各样的同事。我见过各种代码，优秀的、垃圾的、没有吸引力的等等，所以这篇文章记录了一个优秀的Java开发应该具备哪些良好的开发习惯或最佳实践。

1、封装方法参数

当你的方法参数过多时，建议封装一个对象。下面是反面教材，谁教你写成这样的代码？

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;
    ...
}

为什么要这样写？例如，您的方法用于查询。如果以后添加查询条件，需要修改方法吗？每次添加时必须更改方法参数列表。封装一个对象，以后无论添加多少查询条件，只需要给对象添加字段即可。关键是代码看起来也很舒服！

2、封装业务逻辑

如果你看过“狗屎山”，你会有很深的感受。这样的方法可以写几千行代码，没有什么规则可言。经常负责人会说，这个业务太复杂了，没办法改进，是偷懒的借口。无论业务多么复杂，我们都可以通过合理的设计和封装来提高代码的可读性。下面是一个建议的代码。

@Transactional
public 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。还有一堆单元逻辑嵌套在业务之间调用，这非常混乱并且有很多代码。

3、判断集合类型不为空的正确方法

很多人喜欢写这样的代码来判断集合

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;
}

4、集合类型返回值不返回null

当你的业务方法返回一个集合类型时，请不要返回null，正确的操作是返回一个空集合。看一下mybatis的列表查询。如果没有查询任何元素，它将返回一个空集合而不是 null。否则，调用者必须做NULL判断，大多数情况下对象也是如此。

5、推荐使用lombok

当然，这是一个有争议的问题，我的习惯是使用它来省略 getter、setter、toString 等。使用Lombok

6、编写尽可能少的工具

为什么要少写一些工具类，因为你写的大部分工具类都包含在你引入的jar包中，比如String、Assert断言、IO上传文件、复制流、Bigdecimal]等等。编写自己的错误并加载冗余类很容易。

7、写有意义的方法注释

写这种注释是不是怕后来接手的人瞎了。

要么不要写它，要么只是在它之后添加一个描述。写这样的注释并从IDEA收到一堆警告很痛苦

/**
* 请求号码验证
*
* @param a
* @param b
* @param param
* @return Result
*/

8、尽量不要让IDEA报警

很反感在IDEA代码窗口看到一连串的警告，很不舒服。因为有警告，说明代码可以优化，或者有问题。几天前，我在团队中发现了一个小错误。和我没有关系，只是同事们在外面看业务，判断业务为什么错了。我扫了一眼问题。

因为java中的整型字面量int是类型的，所以它们变成Integer了集合，然后点击它stepId就是一个long类型，而Long在集合中，那么这contains正确返回false了，它不是一个类型。

你看，如果你注意警告，你可以把鼠标移到上面看一下提示，就会少一个生产bug。

9、尽可能使用新的技术组件

我认为这是一个程序员应该具备的素质。反正我喜欢用新的技术部件，因为新技术组件的出现是解决老技术组件的不足，而作为技术人员，我们应该与时俱进。

当然，前提是做好准备，而不是想当然地升级。Java 17 已经发布了最简单的例子，新项目仍然使用Date来处理 DateTime。

结论

以上是我个人的一些看法，如有不足之处请指出。

目录CONTENT

几个友好java代码习惯建议