架构的典型组成部分:

架构的典型组成部分:

  以下分类来自《代码大全》3.5小节的《架构的典型组成部分》,并用我的框架来做了一遍对比。

由框架解决的架构问题:

主要的类:

  书上写的是:架构应该详细定义所用的主要的类。在我的框架里,提供的主要的的类有QFSM(状态机),QMsgDispatcher(消息分发器)。在未来还会提供ResourceManager,GameManager等,现在框架中有一份实现,但是其实现有些复杂,不易阅读和理解,等有比较容易理解的实现时候会对其写一篇文章,还有一些主要的模块需要客户端自己实现。

资源管理:

  包括资源加载/卸载,音频、模型、纹理等,是模块化管理资源还是统一管理资源?,我的框架目前有一份实现,但不够易用,未来会提供易用版本。

国际化/本地化:

  很多游戏都会有海外版,国内版,各个国家的版本,如何进行切换/翻译?(我的框架未来会提供)。

输入输出、错误处理:

  我的框架未来会提供错误日志。

性能:

  1.如何检测?框架应该提供相应的数据。
  2.指标如何确定?速度?内存?成本?，游戏开发中还有Draw Call,GC等等(我的框架未来会提供)。

由客户端解决的架构问题:

程序组织:

  包括文件结构应该反映文件或文件夹之间的关系,要思考以什么方式组织比如:先按照模块分文件结构再按照MVC或者先按照MVC分,然后再按照每个模块来区分，再推荐一篇好文:3D手游开发实践《腾讯桌球》客户端开发经验总结:http://www.gameres.com/654759.html(文章略长),文章的第一小节就有讲到关于文件组织。

数据设计:

  书中指的是设计数据库表。在游戏框架中是指提供给客户端使用的数据结构定义,包括何种结构定义玩家的数据信息,策划表结构的定义等等。好的数据结构定义 + 烂的代码质量 >> 坏的数据结构定义 + 好的代码质量。

业务规则:

  属于游戏逻辑范畴,需客户端实现。

用户界面设计:

  用户界面组件之间如何通信,如何管理?用户界面和业务规则还有数据之间如何通信?通信方面已提供消息分发器(QMsgDispatcher)。

安全性:

  资源如何加密,如何防破解,防反编译,安全数据检查,服务器验证等等。

可伸缩性:

  可伸缩性是指满足未来需求的能力，包括程序的可扩展性,用户量增长时系统的策略等等。

互用性:

  如果预计这个系统会与其他软件或硬件共享数据或资源,架构应该描述如何完成这一任务。

容错性:

  举个例子:当界面跳转时,系统不可以接受输入(我的框架不提供)。

关于买还是造的决策:

  Unity可以有很多可以使用的插件、C#库可以使用,很多问题迎刃而解,(我的框架不会包含任何插件,项目不同需要的插件也不同)。

核对表摘自《代码大全》:

1.程序的整体组织结构是否清晰?是否包含一个良好的架构全局观(及其理由)?
2.是否明确定义了主要的构造块(包括每个构造块的职责范围及其他构造块接口)?
3.是否明显涵盖了"需求"中列出的所有功能(每个功能对应的架构块不太多也不太少)?
4.是否描述并论证了那些最关键的类?
5.是否描述并论证了数据设计?
6.书否详细定义了数据库的组织结构和内容?
7.是否支出了所用关键的业务规则,并描述其对系统的影响?
8.是否描述了用户界面设计的策略?
9.是否将用户界面模块化,使界面的变更不会影响程序其余部分?
10.是否描述并论证了处理I/O的策略?
11.是否估算了稀缺资源(如线程、数据库连接、句柄、网络带宽等)的使用量,是否描述并论证了资源管理的策略?
12.是否描述了架构的安全需求?
13.架构是否为每个类、每个子系统、或每个功能域(functionality area)提供空间与实践预算?
14.架构是否描述了如何达到可伸缩性?
15.架构是否关注互操作性?
16.是否描述了国际化/本地化的策略?
17.是否提供了一套内聚的错误处理策略?
18.是否规定了容错的办法(如果需要)?
19.是否正式了系统各个部分的技术可行性?
20.是否详细描述了过度工程的方法?
21.是否包含了必要的"买 vs 造"的决策?
22.架构是否描述了如何加工被复用的代码,使之符合其他架构的目标?
23.是否将架构设计得能够使用很可能出现的变更?
24.你,作为一名实现该系统的程序员,是否对这个架构感觉良好?