简单Elixir游戏服设计-call和测试不舒服的地方
这个系列写到这里,主要关注的2点在于。
1. 到底是call好还是cast好
2. 到底怎么测试更简单
现在发现前面的想法坚持不下来,让我觉得不舒服。
1. call 还是比较适用于阻塞期间无需及时处理其他消息的用法,这不适合多人游戏。
之前为什么纠结于这个问题,实际上是希望利用call的有返回方便测试。
但后面在进程端的测试其实很少,也就是说没有增益。
具体是否合适,只有在项目里检验才知道。
2. 之前说游戏逻辑可以在数据结构上测,这种说法没什么问题。
但又产生新的问题:
2.1 进程才是erlang建模的世界观,是系统的API,而不是数据结构。
数据结构测试完整逻辑,不能保证进程关于数据结构的使用是正确的。
从API的观点看,进程是必须要测试的。
2.2 把业务逻辑放到数据结构, 实际上使得数据结构模块臃肿了。
上个流产的项目我是按照这个思路去做的,不确定写这个系列时,为什么会去探索别的方案。
最大的可能是当时进程测试太啰嗦,却没有去简化进程测试,而想着改变测试位置。
现在想到进程测试同样可以简化, 直接把数据置为指定状态,然后再起进程,不就得了。
接下来,会按照这个思路,先把代码和测试调整过来吧。。。。郁闷