应对复杂的业务逻辑

1.确定逻辑单元

2.对逻辑单元做单元测试

确定逻辑单元的方法有很多，说简单其道理就像我们平时整理自己的屋子，只要将各种东西分门别类的放整齐就可以了；说复杂的，大家可以看看现在市面上的各种设计模式，它们又像一把梳子，帮助我们将杂乱无章的业务逻辑理顺。事实上，不管你怎么写，你的代码是由逻辑单元组成的，因为你的代码的确是在描述业务逻辑，就算是只有一个逻辑单元存在。

然而事情并没有那么简单，逻辑单元划分的粒度的确定是另外一个头疼的问题。举一个例子，创建订单。创建订单过程包含：获取订单相关资源；检查资源可用性；写入订单数据。检查资源可用性过程包含：检查服务员的资质；检查服务员的时间；检查该项订单的时间范围等等。而检查服务员的资质过程包括：获取服务员的工作区间；获取该服务员在该工作区间中的资质....。以上只是我举的一个例子，在显示环境中的大多数情况下，其实我们根本不能很好的确定到底该将这个所谓的逻辑单元确定到什么程度。

其实没有什么，当我们不能很好的完成一件事情的时候，我们应该想到还有其它办法来弥补---这就是单元测试。实际上我们没有必要花很多时间去评价到底该将逻辑单元确定到什么程度。我们只需要确定这个逻辑单元完全实现了它本身所蕴含的业务逻辑。因此我们需要对逻辑单元做单元测试。

实际上，从我们一出生我们就开始完平衡游戏。在这里，逻辑单元和单元测试就是一种平衡。而分析这种平衡的最好方法就是先假设这个平衡不存在会是什么样子。假设我们只一味强调逻辑单元，那么逻辑单元可能会被分得很小，到头来，代码一样会变得难以维护；假设我们一味强调单元测试，我们同样会为此付出高昂的成本。所以我们需要在这个当中找到平衡。而这才是需要我们积累的经验。