介绍
在把底层框架写好之后，服务器开发的主要任务就转移到业务逻辑上，本文主要结合自己的经验，简单介绍业务逻辑开发过程中几个需要注意的点。
防御性编程
- 不要相信客户端数据，一定要对客户端数据进行检验。通常做法是检查协议所有参数的合法性，一旦遇到不合法的判断，马上打上信息充足的日志，然后中断请求的执行。
- 插件式的模块设计，模块功能的健壮性应该是内建的，尽量减少模块间耦合，在所有模块的调用入口做好开关，一旦出问题可以马上关闭系统。另外一个好处的是方便热更，不用考虑执行文件热更的先后顺序。
防刷
-
关键系统资源（如元宝，精力值，道具，装备等）的产出记日志(一般会要求写到数据库)
-
发奖励，严格检查各项操作的前置条件，先扣道具再发奖励。这里举几个例子：
1.如果先发奖，在执行到扣道具代码之前，程序报错了，那么玩家就可以刷道具了。
2.一个活动间歇性地(定时器驱动)给这个时段内参与活动的玩家发奖，名单是一个全局数据，在发奖过程中通过分为给在线和离线的玩家发奖，如果只是简单地循环发奖，发奖结束后再把名单清空，一旦发奖过程有报错，给部分玩家发奖了，但是名单并没有清空，就会导致这批名单的人带入下次发奖活动。解决方法：1.先把玩家从名单中移除，再发奖，发奖失败的玩家会被带入下一轮；2.在发奖前，将全局的名单转移到局部变量中，即使发送失败也不会把名单带到下一轮，可以通过日志还原参与活动的名单，后面再补发奖励。 -
涉及进入条件为入场券的玩法，条件的限制必须加上入场卷每天可以使用几张。 因为通常道具的发放与玩法是否开启并无关系，一旦玩法未开启，但因为一些意外入场卷被发放了，在等待玩家开启的过程中，入场卷就会大量堆叠，在玩法第一天开启就会有大量入场卷消耗，玩家可以获取大量奖励。
-
概率用整数配置，因为不确定在数据转存中是否会把浮点数转换为整数(通常会把一个浮点数转换为0).
日志系统
- 完备，玩家关键操作一定要记日志，记好关键变量的变化，理想的情况是通过日志能重建任何时刻的玩家数据.
- 开发日志的要加级别开关控制, 并且可以线上随时修改这个级别，一方面是防止把大量开发日志带入线上服务器，另一方面是一旦有需求，可以短时间内开启开发日志的打印。
性能优化
- 读大于写的大数据可以做成缓存+版本号，如玩家属性，活动配置表描述信息等，一旦数据修改，版本号增加，客户端请求时所带的版本号不一致，就会重新建立缓存。
- 玩家上线数据批处理加载，最好一次I/O获取。
程序设计可扩展性
- 数据用一个整型还是数组存放？0,1与N，0到1不可扩展，0到N则可以。
测试
测试样本要足够大，最好是线上样本，没有则自己写测试机器人，要问QA拿checklist。