前些天写了那篇裁掉差程序员的文章后，有看到一些私信：问，好的程序员的代码是长什么样子的，今天就拿我们项目里一个真实的下单接口为例，让你看看高手是怎么用「方法」，把业务流程「一眼体现」的。
今天我们不谈面向对象，就单单谈用方法封装一些逻辑。用好方法，除了大家都知道的提升复用之外，还有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);方法就可以了。剩下的不用动。为啥?
因为上面的代码还体现了一个重要的写代码技巧：
叫代码是处于同一个抽象层次的。
大家都是同等地位，各司其职的。而是一会细节，一会核心业务，一会又不是。
希望你不是一来就写出类似下面的杂乱且大而全的方法：
上面就是我对要多用好方法的理解了。
最后问大家一个扎心的问题：你们现在的项目里，有这种「一眼看出流程」的代码吗？还是说，大家为了进度，早就写成「一盘散沙」了？评论区聊聊，我看有多少人正在屎山里挣扎。
