我工作多年,遇到过各种各样的共事。我见过各种代码,优良的、垃圾的、没有吸引力的等等,这篇文章记录集体的一些代码开发习惯。
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。
论断
以上是我集体的一些认识,如有不足之处请指出。