简要说明 框架github
根据游戏的特性,整理了一套后台开发框架,方便上手开发业务,后继会对框架的结构和使用做进一步说明。
使用这套框架希望达到的目标和效果
-
方便开发人员在不同业务模块之间切换
业务模块之间结构尽量保持一致。
-
方便开发人员在不同项目之间切换
项目之间结构尽量保持一致。
-
降低开发难度
对开发人员隐藏底层实现
开发人员可以在不理解整个框架的情况下快速上手业务
-
方便 java 和 c++ 等开发人员快速入手业务开发
为达到这个目标,业务设计的思路和方向
1. 越高的一致性,意味着越低的维护成本
软件项目开发之所以复杂,很大一部分原因是因为同样的结果可以有无数种实现方案,当我们只关注能看到结果的时候,复杂度就会在这异构的实现过程中急剧地膨胀。
所以,在任何有可能实现一致的地方,都要尽量的让它保持一致。
2. 职责清晰
尽量保证每一个模块有清楚唯一的职责。
每一个功能模块有清楚的界限,app边界和接口,进程边界和接口,模块、子模块的边界和接口。
可以理解成分层是一个维度X,业务是第二个维度Y。保持第一个维度的一致性,然后在第二个维度上不断地把复杂系统切割成一个个有意义的块,降低每一个块的复杂度。
3. 保持功能模块开发的一致性
每一个业务模块在层级架构和调用关系(尽量保持树状的调用关系)上保持一致
进程间的调用接口
业务模块接口层
业务子模块接口层
数据Dao层
数据结构Pojo层
利用工具包的第一个功能,实现模块间的一致性
做好一个标准模块,规范命名
用拷贝修改的方式开发新的类似模块
用辅助工具做模版的业务名替换
4. 进程内尽量保持面向对象开发的方式
方便java和c++等开发人员转erlang开发
对象这一层可以做一定的封装
5. 面向维护
-
当有AB方案的时候,尽量考虑容易维护的方案,而不是快速开发的方案
-
易于维护包括但不限于
易于数据状态变化的跟踪 易于数据升级 良好的好封装,封装的范围包括 pojo,类(erlang的module), 业务模块,进程,多进程业务 设计良好的分层,随时可以做面向切面的调试,重构,开发。 优先考虑维护性再考虑性能,在维护性好的情况下,性能可以有的放矢