我们在最近几篇的文章里,学习了刘钢老师的《Unity 项目架构设计与开发管理》的部分内容。到这篇为止,学习的这些内容已经够我们消化一段时间了。
那么我们今天开始进行正式的整理。
我们先回顾一下当前的目录,如下:
![73b54770970b349d992bc90250bab20d.png](https://i-blog.csdnimg.cn/blog_migrate/7d1573cb370c58f416c18a3e4a03825c.jpeg)
我们收集了十四个示例。
在正式整理之前,我们进行一次备份。我们目前已经导出的版本如下:
QFramework_v0.0.0: 第一次整理前备份
QFramework_v0.0.1: 第一次整理后备份
QFramework_201YMMDD_H: 第十四个示例完成后的备份
那么我们的这次备份文件的版本应该是_v0.0.2 版本。那么其实不用再进行导出了,而是,直接把 QFramework_201YMMDD_H 这个文件名改成 QFramework_v0.0.2: 即可。
当然如果童鞋在第十四个示例完成之后忘记导出了,那就以现有的版本再进行一次导出就可以了,导出之后记得改名字。
OK,导出的步骤就算完成了。
我们开始准备整理,还记得我们的约定和规则嘛?列出如下:
约定和规则:
每个示例在 QFramework 目录下创建一个文件夹,文件夹的格式是: 数字.示例的功能
每个示例写一个脚本,脚本中包含可复用的静态方法和 MenuItem 方法。
每写一个示例进行一次导出,导出的文件名后边加上日期和时间,这个功能已经在导出功能里内置了。
每次有 API 变更的时候做一次备份,备份的名字采用 QFramework_vX.Y.Z 格式。
每次进行整理的时候要确保是在功能有效的情况下进行删除和变更。
确保菜单名和文件夹名一致。
要给类/代码文件取合适的命名。
在删除弃用代码的步骤:
消除弃用警告。
搜索弃用方法的引用,并逐个升级为最新的方法。
全局搜索方法名,并根据情况逐个升级为新的方法。
如果按照这个规则,把每个 Manager Of Managers 里的 Manager 都实现一遍,那么我们的示例就会从 14 个变成 20 多个。这样在 QFramework 的一级目录下文件会非常多。而在未来我们会收集越来越多的工具,框架的东西也会越来越多,那么如果每个工具和功能都写一个示例,那么当展开 QFramework 的目录的时候可想而知是有多壮观了。我们在这次,不得不解决掉这个问题。
目录结构设计
我们要重新组织目录。从我们自身出发思考,我们是框架是用来干什么的?
知识库
工具库/类库
框架
第一个知识库,其实就是我们的示例本身,我们在未来,通过查看一下示例,就能知道一些知识点或者 API 如何用?从这个使用目的去思考,知识库部分,其实就是 Example。所以,可以把我们的知识库相关的部分提取成 Example。
第二个工具库/类库,全部都是可复用的代码库,当然有的功能是适用于 Editor 环境下的,有的功能是适用于 Runtime 环境下的。不过这个到时候细分一下就好了。那么它是属于框架的一部分,所以所在的文件夹是 QFramework/Framework/Util 和 QFramework/Framework/Editor。
第三个框架,框架部分就是我们目前的核心部分,目前只有一个 QMonoBehaviourSimplify,而之后呢,需要加入很多 ManagerOfManagers 的 Manager,这部分内容的目录结构,暂时还没有想法,所以就全部扔到 QFramework/Framework 下方就好了。所以到此,我们的目录结构如下:
QFramework
Editor
Util
Examples
Framework
Examples 里在未来还是充当知识库的作用。
而 Framework 里到时候放的就是货真价实的框架。这就算是这次目录的结构的设计了。它能满足我们的学习需求,也能满足框架文件的合理存放需求。但是还不够,肯定之后会有很多问题的,不过没关系,遇到了问题再说,大不了就再整理一次,而且现在的版本才 0.0.3 版本,用的人也是自己,用不着去发布给别人用。所以我们不着急一开始就设计一个非常严格且合理的文件结构。
目录结构就设计到这,我们有了一个还不错的结论。
菜单栏的设计
关于菜单栏的设计,目前可以先不考虑,可以是等到目录全部分好了之后再去设计。
转载请注明地址:凉鞋的笔记:liangxiegame.com
订阅全套专栏:liangxiegame.com