前些天写了那篇裁掉差程序员的文章后有看到一些私信问好的程序员的代码是长什么样子的今天就拿我们项目里一个真实的下单接口为例让你看看高手是怎么用「方法」把业务流程「一眼体现」的。今天我们不谈面向对象就单单谈用方法封装一些逻辑。用好方法除了大家都知道的提升复用之外还有2个重要的好处第一个是一眼就能看出核心业务流程是什么不需要深入到代码细节里第二个是我每次改他的代码失误率小很多像我这个年纪的看代码都是先关注这个模块的业务流程是什么。如果你一下子写一个大方法把所有代码细节扔进去。那为了理解关键核心业务流程就很费劲。相反我喜欢看到下面的这样的代码public Long submitOrderDocs(SaveOrderDocsCommand saveOrderDocsCommand) { //1、检查订货单的入参是否正确 checkCreateOrderParam(saveOrderDocsCommand); //2、计算订单能推送到ERP系统的时间 buildOrderCanPushTime(saveOrderDocsCommand); //3、创建订单 Long docsId createOrder(saveOrderDocsCommand); //4、超时订货走OA审批流程(不能影响主流程) createOaDocs(saveOrderDocsCommand, docsId); //5、发布订单已生成的领域事件 eventPublisher.publishCreateEvent(docsId, ORDER); return docsId; }上面的方法引入眼帘的就是一个一个方法单看这个几个方法我就知道「整个下单」的核心链路。如果我对细节感兴趣我会自己到每个方法去看细节的。如果我点击进入到某个方法比如上面的Long docsId createOrder(saveOrderDocsCommand);方法见到的是如下的代码那恭喜写这个模块的程序员是一个好程序员private Long createOrder(SaveOrderDocsCommand saveOrderDocsCommand) { //1、创建订货单 Long orderId createOrderDocs(saveOrderDocsCommand); //2、拆单根据供应商拆解成对应的配送单 createDeliveryDocs(saveOrderDocsCommand, orderId); return orderId; }注意看上面的代码又是同一种风格的不用看代码细节就知道核心流程是创建主订单和拆单。这就非常的好完整的体现了核心的user case。核心业务就是这么走的可以了。真正做到了业务流程到代码的完美映射。上面的代码就是美的代码。如果你当前还不习惯这么写请尽早建立起来。深入理解业务流程后通过代码完美的映射出来。请记住这句话清晰的代码应该能非常简单的就体现了核心的业务流程。那么我刚才提到的这种风格的代码很容易修改怎么体现呢?比如说有一个需求创建订单时新增一个校验。那么你就直接改checkCreateOrderParam(saveOrderDocsCommand);方法就可以了。剩下的不用动。为啥?因为上面的代码还体现了一个重要的写代码技巧叫代码是处于同一个抽象层次的。大家都是同等地位各司其职的。而是一会细节一会核心业务一会又不是。希望你不是一来就写出类似下面的杂乱且大而全的方法上面就是我对要多用好方法的理解了。最后问大家一个扎心的问题你们现在的项目里有这种「一眼看出流程」的代码吗还是说大家为了进度早就写成「一盘散沙」了评论区聊聊我看有多少人正在屎山里挣扎。