复杂

今天和黎叔又讨论了一下TS、Job和预约，经过充满激情的讨论，得出一个小结论：

当承运商给Job派车时，永远只有一辆车的时候用Job，比如液空和中远，如果有多辆车的情况就用TS，比如零担Job。

谈到TS，就不可避免地要谈到它和Job之间多对多的关系，这个是最让黎叔头疼的关系，因为它复杂所以让人想不清楚，因为让人想不清楚所以让人头疼，因为让人头疼所以我们要尽可能避免多对多的关系，但是有时候好像又避免不了，这就是生活。

TS和预约合并的下半场已经开始，而且已经开发了两个版本了，可以亲身体会到驾驭复杂性的代价，上半场是从领域模型上支持了Job和TS多对多的关系，下半场是从业务逻辑上真正支持多对多的关系。

我们要尽量避免增加我们系统复杂性的功能，但是当复杂不能避免的时候，我们要有驾驭复杂的能力，反思自己，在这点上做得相当不够，可以把TS和预约重构下半场想象成一个大蛋糕，自己却没有花足够的时间和精力把大蛋糕切小，导致吃完大蛋糕的风险很大。

我们一直说Story要小，但是一直没有衡量的尺度，我想现在是不是有了，尺度是不是可以定义成：

一个版本上线不了的Story必须拆分成更小的Story。

所以拆解是化复杂为简单的第一步，而从需求就开始拆解是拆解的第一步，切记切记。