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