服务端开发规范

未分类

1.manager、handler、provider、Entity

• manager - 代码主要逻辑实现的地方，一个模块可以有多个manager，分别处理不同的功能。
• handler - 处理与网络相关的逻辑，比如说参数检测、解析Protobuf协议并获取相关的参数等。
• provider - 加载静态文件
• Entity - 所有的游戏逻辑数据，Entity除了相关的属性定性外，不要实现过多的逻辑代码，尽量不要在这里面调用Manager

2.DB、缓存

• 存取数据使用mongoTemplate
• entity定义必须使用@Docment、@Id，根据需求使用@Index，尽量不要将字段名定义为id，对于一些历史遗留的 - 字段，有必要进行修改或者删除，在未修改之前使用@Transite
• 复杂查询可以使用mongoTemplate，也可以使用Responsity接口
• 目前玩家和公会相其它数据是内容中是有缓存的，对于需要一直保存在内存中的数据，需要谨慎对待数据的状态管理、线程同步等

3.Spring

• 项目中所有的bean使用spring来进行管理
• 所有的manager必须使用@Component注解
• 使用Spring来管理bean的生命周期，不再需要使用构造函数、单例、init()方法等
• 尽量不要再使用Services这个来调用Manager，请使用spring的注入
• 定时任务请使用@Scheduled，尽量不要再用WzTimer，动态的定时任务可使用QuartzScheduler
• properties配置相关，使用@Value注入

4.代码规范

• 必须使用checkStyle，代码必须满足checkStyle规范，并且没有warn
• 不要使用system.out来进行日志打印或者调试，请使用使用log4j
• 使用驼峰命名法
• 未使用的类、代码，上传前请删除
• 控制每个类的代码行数
• 对应的功能在对应的Manager中实现，不要将不相关的功能写到一起去
• handler，对每个参数都必须做相应的check
• handler，需要对每次客户端的调用打出相关的log，应当包含player id、请求的参数等
• manager，对一个敏感操作（解散公会、使用物品、充值等）必须打印Log
• 不要使用main方法测试，请使用JUnit来进行单元测试

5.codeReview

• review使用交差review的方式
• 有共性的问题可以设置到到checkStyle中，或者商讨出一个统一的方案
• 后期使用pull request模式

6.其它约定

• 不要使用ActorManager、Actor、IRunner等，原因是Actor没有对线程的状态进行管理
• 不要使用WzTimer
• 除了调用Provider外，不要使用Services
• Enum的定义，由于目前可以直接序列化到DB中，可以不用再定义IntValue，如果Json文件中还有使用，则不能删除
• 不要使用ConfigUtil，接下来将修改成用Spring注入
• interface中的方法不需要定义为public、Enum的构造函数也不需要定义为public
• 尽可能使用lambda
• 尽量不要在entity中调用manager，如果需要调用，则说明这个方法可以放到manager中去实现

7.需扩展、加强的地方

• SysDataEntity需要完善
• 清理log、login、game-main
• 打包机，自动打包上传脚本，每日构建

一些参考
程序员必备的代码审查（Code Review）清单
Git 工作流程
checkstyle