裁掉那个差程序员后，给你看团队里高手的代码：这个习惯，希望你有

前些天写了那篇裁掉差程序员的文章后，有看到一些私信：问，好的程序员的代码是长什么样子的，今天就拿我们项目里一个真实的下单接口为例，让你看看高手是怎么用「方法」，把业务流程「一眼体现」的。

今天我们不谈面向对象，就单单谈用方法封装一些逻辑。用好方法，除了大家都知道的提升复用之外，还有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);方法就可以了。剩下的不用动。为啥?

因为上面的代码还体现了一个重要的写代码技巧：

叫代码是处于同一个抽象层次的。

大家都是同等地位，各司其职的。而是一会细节，一会核心业务，一会又不是。

希望你不是一来就写出类似下面的杂乱且大而全的方法：

上面就是我对要多用好方法的理解了。

最后问大家一个扎心的问题：你们现在的项目里，有这种「一眼看出流程」的代码吗？还是说，大家为了进度，早就写成「一盘散沙」了？评论区聊聊，我看有多少人正在屎山里挣扎。