简单Elixir游戏服设计-call和测试不舒服的地方

这个系列写到这里，主要关注的2点在于。

1.  到底是call好还是cast好

2. 到底怎么测试更简单

现在发现前面的想法坚持不下来，让我觉得不舒服。

1. call 还是比较适用于阻塞期间无需及时处理其他消息的用法，这不适合多人游戏。

    之前为什么纠结于这个问题，实际上是希望利用call的有返回方便测试。

   但后面在进程端的测试其实很少，也就是说没有增益。

   具体是否合适，只有在项目里检验才知道。

2. 之前说游戏逻辑可以在数据结构上测，这种说法没什么问题。

   但又产生新的问题：

  2.1  进程才是erlang建模的世界观，是系统的API，而不是数据结构。

         数据结构测试完整逻辑，不能保证进程关于数据结构的使用是正确的。

　　从API的观点看，进程是必须要测试的。

  2.2 把业务逻辑放到数据结构， 实际上使得数据结构模块臃肿了。

上个流产的项目我是按照这个思路去做的，不确定写这个系列时，为什么会去探索别的方案。

最大的可能是当时进程测试太啰嗦，却没有去简化进程测试，而想着改变测试位置。

现在想到进程测试同样可以简化， 直接把数据置为指定状态，然后再起进程，不就得了。

接下来，会按照这个思路，先把代码和测试调整过来吧。。。。郁闷