Unity 游戏框架搭建 2019 (二十一、二十二) 第三章简介&整理前的准备

整理前的准备

到目前为止，我们积攒了很多示例了，并且每个示例也都贯彻了最的约定和规则。
在上一篇的小结也说了一个比较新的东西:编程体验优化。
在之前我们还积攒了一个问题：代码重复问题。
我们可是忍住整理的冲动忍了好久了。

所以现在也是时候准备着手整理了。

知识点和问题总结

遗留问题

我们写列出来之前记录的第一个问题:

• 第八个示例与之前的示例代码重复，功能重复。

这个问题想想就很好解决，只要删除掉第八个示例之前的示例就好了。但是怎么删和删完是否会破坏原来的功能？这两问题要具体看了代码才会知道。现在先不看，先把这个问题暂时列出来。

备份

代码要在之后的一段时间内要进行大幅度地更改，可能会改出问题来，如果问题比较难以解决就麻烦了。所以我们要给做一个份备份，如果出了问题我们可以通过备份恢复。如何备份其实有很多种，比较常见的是放在 git 服务器，不过这部分我们还没有接触过，所以先备份成文件。就用我们的导出功能导出，把文件进行命名。叫什么名字呢？这个问题也先列出来：

• 进行备份，给导出的文件取个名字。

约定和规则总结

首先我们到目前为止 QFramework 目录结构应该如下图所示:

笔者更希望除了除了了这 13 个示例之外，大家自己也收集了一些东西。

之所以目录的结构是这样，是因为我们在做每个示例的时候贯彻了我们的约定和规则。

那么我们的约定和规则现在是什么呢？

1. 每个示例在 QFramework 目录下创建一个文件夹，文件夹的格式是: 数字.示例的功能
2. 每个示例写一个脚本，脚本中包含可复用的静态方法和 MenuItem 方法。
3. 每写一个示例进行一次导出，导出的文件名后边加上日期和时间，这个功能已经在导出功能里内置了。

大概就这些，非常清晰明确。

示例诞生的原因类型

现在呢我们有 13 个示例，每个示例都有它诞生的原因的。但是这些诞生的原因又有点区别，我们逐个进行分析列出。

前七个示例是为了完成导出功能而进行的 Unity、C# API 的练习。因为在初期很多 API 我们是不知道的，大家应该在刚接触 Unity 的时候都经历过这一个阶段。

而完成导出功能的原因是为了优化我们的知识库导出体验，并且打造一个知识库的使用流程。有了导出功能可以让我们的知识库在多个项目之间切换或者在家和公司之间切换，而导出功能中的自动命名功能算是内置了我们的一部分命名规则。命名规则的存在呢是为了解决我们如果有多个文件不知道哪个是最新的问题。

所以前七个示例总结下来是解决了几个问题:

1. 新的知识（API）收集，比如时间操作、文件打开、UnityEditor API 收集等。
2. 内置了部分规则（比如文件命名）。
3. 完成某个功能（导出功能），并完善。
4. 导出功能的目的是为了让知识库的使用流程更平滑，是为了解决最初的问题。根据解决的问题去收集了 API，并逐步完善的导出功能。
5. 逻辑复用，比如 MenuItem 复用。

前七个示例大概是这样。

接下来分析之后的几个示例:
8. 第八个示例诞生的原因，是为了解决我们的代码复用问题，使用 MenuItem 进行复用代码限制太多了，所以为此我们使用了 public 关键字，并且对前七个示例都进行了一次实践。在实践的过程中有逐步摸索出了一点方法设计的方法论。
9. 第九个示例是笔者分享的一个在项目中比较实用的分辨率检测小工具，这种小工具是解决实际的项目问题。
10. 第十个是示例节省了代码行数，因为每次为 transform.localPosition.x 赋值太麻烦了，要写三行代码，算是编码体验优化吧。
11. 第十一个示例是 Transform 重置功能，写了一个 Identity 方法，同样也是编码体验优化。
12. 第十二个示例是 一个概率函数，就是 Persent，是一种数学工具，在项目中也会用到，和第九个分辨率检测小工具一样，算是解决项目实际问题的小工具。
13. 第十三个示例呢是给 GameObject 的 Show 和 Hide 做了一步，原因是笔者刚转过来的时候不太适应 active 的这种命名，也算是编码体验优化。

大概是这些加上前七个总结再进行一次分类总结。

我们的知识库的每个示例诞生的原因分类:

1. 知识、API 收集（为了完成导出功能）。
2. 实现部分规则（命名规则）。
3. 解决库本身使用及流程问题（导出功能）。
4. 逻辑复用（MenuItem 和 public 方法）。
5. 实践新接触的 C# 语法（public 方法）。
6. 项目实用工具收集。
7. 编码体验优化。

大概就这七个原因，其中 1 和 5 可以归为一类。2 和 3、4 、6、7可以归为一类。

如下:

1. 知识学习&收集
   • API 收集
   • C# 语法实践
2. 库本身的功能
   • 规则实现
   • 使用流程提供及优化
   • 效率提升（编码体验、逻辑复用）
   • 项目实用工具收集

OK，总结出了一份非常清晰的分类。大家还记得在第一篇中笔者的关于库的介绍？
贴出原文如下:

有一个自己的库，有什么好处呢？其实好处是非常多的。

从编程角度上:

• 可以提高自己的编码效率。
  从学习角度上:
• 可以积累下来自己所学过的知识。

在第一篇的时候很笔者介绍的很模糊，现在经过以上更具体的分类，大家应该更清楚了吧？

今天的内容就这些。

小结

1. 要做的事情:
   • 备份:导出文件，并取一个合理的名字。
2. 遗留问题:
   • 第八个示例与之前的示例代码重复，功能重复。
3. 约定和规则:
   • 每个示例在 QFramework 目录下创建一个文件夹，文件夹的格式是: 数字.示例的功能
   • 每个示例写一个脚本，脚本中包含可复用的静态方法和 MenuItem 方法。
   • 每写一个示例进行一次导出，导出的文件名后边加上日期和时间，这个功能已经在导出功能里内置了。
4. 示例分类:
   1. 知识学习&收集
      • API 收集
      • C# 语法实践
   2. 库本身的功能
      • 规则实现
      • 使用流程提供及优化
      • 效率提升（编码体验、逻辑复用）
      • 项目实用工具收集

文章就写到这里，我们下一篇开始进行整理。

转载请注明地址：凉鞋的笔记：liangxiegame.com

更多内容

• QFramework 地址：https://github.com/liangxiegame/QFramework

• QQ 交流群：623597263

• Unity 进阶小班：

  • 主要训练内容：
    • 框架搭建训练（第一年）
    • 跟着案例学 Shader（第一年）
    • 副业的孵化（第二年、第三年）
  • 权益、授课形式等具体详情请查看《小班产品手册》：https://liangxiegame.com/master/intro

• 关注公众号：liangxiegame 获取第一时间更新通知及更多的免费内容。