服务器逻辑开发心得

---

系统层面

1. 通信协议一般是由服务器制定,有几个关键点:
   ①. 变量注明必须和可选字段(required or optional).
   ②. 协议注明请求，返回和推送时机，不要让其他协议阅读者猜测意图。
   ③. 涉及枚举定义一定要专门定义，不要直接在协议里面注释标明。

2. 日志：
   ①. 分类按照级别, debug, info, warn, error分文件夹存储.
   ②. 以小时为单位分文件存储, 每个文件大小限制在500m ~ 1g左右比较好.
   ③. 格式: [MODTAG] + 做了什么，结果如何 + 角色标识(uid + name + account …) + 关键变量以及变化
   [MODTAG] , dowhat, roleInfo, result, key_param_list.
   建议在每个函数开头给全局变量 LOGTAG赋上模块值，在日志函数中直接取这个LOGTAG做tag即可，减少写日志的麻烦。
   ④. 涉及多系统调用，日志要加上调用模块来源标识(src).

3. 为了使回调函数可以热更,注册回调函数的时候不要直接取函数地址,而是写成闭包的形式封装回调函数.(即需要触发回调时,再去寻找回调函数.)

4. 定时器回调，要用pcall或xpcall进行调用处理，以免出现因为报错导致定时器没删除，反复执行超时函数，或因为一个实体报错，导致共享同一定时器的其他处理实体(一个常见的例子就是场景处理)无法处理的问题.

---

逻辑层面

1. 逻辑功能中，凡是 0->1(制造), 1->n(升级)状态可以合并公用的函数尽量公用，这样检查操作代码(checkOp)也只需要写一个即可。 然后对0->1, 1->n都可以进行同样操作, 也要放在一起去做。前期分开了,后面一定要做优化.
   原则: 分解函数,函数最简化,只做应该做的事情.

2. 先把后端的功能做好,涉及前端推送的问题,如果没想清楚先不纠结,不要混合开发,先标记为优化项(Todo),等自测完毕后再添加即可.

3. 每个功能开发完,一定要及时花上半天时间去检查优化, 效果最高. 优化顺序:
   ①. 逻辑正确性. (是否写错变量, 是否有死循环,循环发奖代码结束是否正确…)
   ②. 日志信息齐全.
   ③. 性能(做cache，算法优化).

4. 频发难找的小bug(例如数据修改后没同步到其他模块)，可以在玩家对应模块的online函数执行时做一次数据修复.

5. gm指令不能只依赖于客户端发送,因为一旦客户端登录不上(最常见就是上线模块报错), 就没法发送(如热更文件修复bug,只能重启服务器). 至少要实现通过http携带gm指令到http服务器, 再转发到游戏服务器进行处理.

6. 打开界面获取信息功能，从效率上设计，可以都是客户端登录或打开界面时请求一次所有数据，之后的数据修改就由服务器主动推送.

7. 玩家上线处理函数设计. 上线处理函数会分布在各个功能模块实现，顺序原则:
   ①. 要把模块独立的放在前面, 依赖其他模块的函数放在后面.
   ②. 不要有模块间相互依赖的逻辑,否则要么报错,要么逻辑不正确.

8. 对于一个表存储所有事件，另一个做分类计数用的功能, 推荐用弱表实现。

9. 插件式开关开发模式，面向接口编程， 减少模块之间的耦合。

10. 防刷，先重置条件(记录表数据换到临时表)，先扣，再做发奖逻辑.

---

性能优化:

1. 做缓存. 目的: 减少cpu和io操作。 数据特征： ①. 大对象数据. ②.只读和读频率远远大于写.
2. 存储传输一致. 本地存储与数据传输的数据结构往往有差别，如能把定制成一样，可以空间换时间，避免传输时重建数据的开销。
3. 尽量不做排序加工操作，可以让客户端做则推给客户端，只要保证原始数据正确即可。
4. 一次推送，如发给客户端的数据量太大，可以在玩家上线时做一次推送，待数据有修改时再推送。

---

代码整洁

1. 多层 if嵌套逻辑，可用临时变量记录符合条件的对象，提取出if嵌套逻辑，到下个处理过程中处理。
2. 过长函数拆分(100行以上), 过长文件拆分(1000行).
3. 特殊做法的函数要写好注释.
4. 重复代码剥离到一个函数.