本周继续做公会功能，有点乏味。

这次主要是基于上周完成的框架，进行具体功能的协议对接。原本以为对接会很简单，毕竟之前的功能模块都已经写过单元测试了，虽然覆盖率不高，好歹还是能跑通 happy path 的。实际用的时候，才发现上周设计的 api 粒度太细了。隐约记得第一次做公会，也是犯了这个错误，api 之间是十分正交，每一个完成的功能也很简单，方便测试。但是，用的时候需要调用多个 api，因此需要处理多种错误情况，而没有 goto 语句，又导致需要将同一段错误处理代码多次复制粘贴。

另一个比较头痛的问题，是目前的网络流是异步 IO 模型的，导致一段正常的逻辑需要断开多个函数来写，搞得我思维负担很大，有时候还需要在多个文件间来回切换，工作效率不高。异步回调这个无法解决了，除非引入 coroutine 的模型，可惜目前能力有限，无法向领导层推动这个事情。连游戏的自动测试，都无法推动到商业合作的阶段，真的有点失落。多个文件切换这个，最后用单元测试部分解决了，测好一个函数，对接一个，避免首尾应接不暇轮番报 bug。

为了方便开发，避免频繁更新协议，内部协议采用了 JSON 作为序列化的工具。因此，很多回调函数的参数都是 mapping，类似 python 里的 dict，漏参数在编译器不会报错，运行期会出现各种诡异问题。当年用 python 写公会的时候，没有想到解决办法，总觉得熬过去就好，反正有 QC 保证。现在学聪明了一点，写了个入口检查函数，既然不能在编译期检查，就在运行期加上吧，实际尝试后，发现效果拔群！虽然没有做类型检查，只是检查了 key 值是否有缺失，已经很有帮助了。

另，最近同事在研习 bt 软件，用了一个从网上扒拉过来的 SHA1 算法，然后老是说这个算法改了他的全局变量，导致变量变成一个巨大无比的值。我检查了一下代码，SHA1 里没用全局变量，不可能是别人的误改动。后询问得知，这个错误在 Linux 上不会发生，在 mac 上编译才会出现。前段时间，引擎从 Freebsd 迁移到 CentOS 上的时候，也出现了类似的错误。有可能是内存越界访问导致的，也有可能是某个 unsigned 的类型定义不一样，（不可能，溢出绕回的话不会变成大于 max 的值，如果可以大于 max 就不会溢出了）只是，网上找到的教程都是 Unix 向 Linux 移植，没有反方向的，比较囧