§ 业务校验，要着眼于整体流程——不做冗余校验

我司是共享经济体制下的灵活用工企服平台。今天评审代码过程中，我们注意到一个实现细节，是在交付单完成后给用户结算时，判断了用户是否已签约，用户是否领取了任务，用户是否已经注销，当上面3个条件都满足后，才发起结算。

先大致描述一下业务流程链：（1/7）企业客户发起灵工需求，生成任务单→（2/7）平台审核任务单，匹配灵工服务商→（3/7）企业支付完成任务所需的费用→（4/7）自由职业者领取任务（此时如果未签约，会先发起签约）→（5/7）自由职业者完成任务，提交交付物，生成交付单→（6/7）企业验收，确认自由职业者交付完成→（7/7）平台为自由职业者结算。

那么，在交付完成给自由职业者结算时，显然不需要再判断用户是否已签约，用户是否领取了任务了。因为在整个业务流程链中，用户签约是用户领取任务的前提条件，用户领取任务是用户交付的前提条件。也就是说，没有用户签约和用户领取任务，就不会有用户交付。至于是否判断用户注销，则视产品需求来定，如果需求规定了给用户结算时不关注用户状态，那么，就不能有这个判断；而如果需求规定了必须判断用户状态，那就要保留这个判断（校验）。

简言之，假设一个业务的流程是①→②→③这三个环节，那么，在进行③时，必须要验证②，无需同时验证①。业务流程中每个环节的校验应基于上一个环节，无需再基于更靠前的环节。

§ 业务校验，注意各个校验的先后顺序。

举个简单的例子，我们去看望朋友，上超市买了一堆东西，打车到了朋友小区，结果一问才得知朋友出差了，尴尬不？当登山者快要登上珠穆朗玛峰的顶峰时，突然发现氧气不够用了，这可是非常危险的情况，甚至可能要命。

业务方法里，进行业务校验的先后顺序，有必要理清楚。

经常看到这样的方法，逻辑执行了一大部分，结果在持久化更新数据时，发现某个参数值是null，程序或返回参数有误，或出现NPE或持久化异常，导致更新失败。

这是比较简单的案例。在复杂的业务流程中，尤其要注意校验的顺序。

这里提供一些实用的规则：先校验入参，然后执行本地（本服务内）校验，然后是涉及远程或外部调用的校验。

例如：我们调用第三方支付通道进行付款时，先系统内判断数据的正确性，以及业务的严谨性，最后再请求三方通道验证账户余额是否充足，最后是调用三方通道进行付款。我们来颠倒一下，假如先请求三方通道验证余额，然后再校验本地数据和业务，是不是有些本末倒置的感觉？