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