服务开发原则
- 通信
pack、event事件、corn定时任务必须在facade层作为开始。 service层不允许作为被其他模块调用。只能被自己模块的facade调用。manager层允许其他业务模块调用。如果涉及到多线程manager自己考虑自身的线程安全。- 可以把用用的（其他模块也会用到的，确定只有自己会用到的条件没必要做抽象了，避免代码不直观）条件设计成
condition。根据策划接收程度考虑用json配置或者conditionResource配置 - 跨模块资源消耗、策划需要统一配置的资源必须抽象出
Consumes去消耗。 - 跨模块资源发放、策划需要统一配置的资源发送不允许直接修改领域对象。必须走
reward方便管理和记录日志。 chooser作为条件选择器。可以抽象出一些统一的筛选规则。比如条件筛选、概率筛选。- 不允许在代码中拼接文本内容。
- 玩家自身的任务采用的是玩家的
account的hashcode来作为任务分发。公共模块例如交易、公会等业务需要模块自身维护加锁。使用到锁的模块必须与项目主程沟通协商。`AtomicXX.compareAndSet()解决不了代码块的问题，如果觉得可以用和主程讨论以后再决定。 - 实践证明，程序参与配置表配置然后策划改修数值比直接掉给策划一张空表开发效率会高很多。
- 每一张Resource配置表。必须要包含一个sheet配置说明，并且不断维护更新。这个说明的起草通常由服务端开发人员发起。然后各方维护。
- 配置表映射的Resource类中为了防止配置表对象被无意中修改。应当不包含
set*方法。 - 每一模块，开发完成后以后，必须用findbugs和阿里编程规范插件扫面。高级别的错误必须修正。
- 设计一个活动系统的时候。无论策划文档是否有明确指出，都应该将是否热更新考虑进去。
- 项目中不允许出现
System.out.println(),统一使用SystemOut.println()代替。 - 服务端开发应视为客户端已经被破解。所以设计到安全和收益相关的逻辑，必须做好严格的验证。不得依赖客户端的消息。
- 所有开发中的常量都必须使用配置的方式实现，不允许将常量定义在代码中，可以配置在ConfigValue.xml中。
- 所有代码中需要被处理的错误，都应该用
Logger.error记录下来，及时查看error日志并解决。 代码中的
return,仔细思考为什么需要中断业务，不应该什么都不做直接return。
协议处理时需要return的地方，应该选择以下三种方式
a 客户端没法预判断，需要服务器来判断的，提示对应错误信息`throw ManagedException.valueOf(result.getCode())`b 客户端可以预检验的情况下发过来的 没有被检测的请求 统一返回请求非法就行
`throw ManagedException.valueOf(MessageCode.ERROR_MSG)`c 其他不属于上面，只能直接return的，用Logger.error记录日志
必须安装提交日志的插件，提交日志需要遵循规定的格式，插件中的类型、标题、说明为必填项
- 提交代码时必须勾选以下选项
- Alibaba Code idelines
- Reformat code
- Optimize import
- Perform code annlysis
- Check TODO