几个友好Java代码习惯建议

语言: CN / TW / HK

我工作多年,遇到过各种各样的同事。我见过各种代码,优秀的、垃圾的、没有吸引力的等等,所以这篇文章记录了一个优秀的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、封装业务逻辑

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

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

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。