#游戏编程模式# --- 框架、性能、游戏

---恢复内容开始---

一、软件框架

1.1 好的软件框架

  好的设计意味着当我们做出一个改动时，就好像整个程序都在期待它一样。我们可以调用少量可选的函数来完美地解决一个问题，而不会为软件带来其他的多余的副作用。

  “只管写我们自己的代码，框架会帮我们收拾一切！”。

  关键部分：框架意味着变化。衡量一个设计好坏的方法就是看它应对变化的灵活性。

1.2 如何做出改变

  好的改变，是在下一个人在添加代码的时候不会察觉我们的代码的变动。

  

1.3 我们如何从解耦中受益

  我们可以用一堆方式来定义“解耦”，不过只要我们明白，如果两块代码耦合，意味着我们必须同时了解这两块代码。如果我们使它们解耦，那么我们只需要了解其一。

  软件框架的一个关键目标：在我们前进前，最小化我们的脑海中的知识存储量。

  当然，对于解耦的另一个定义就是当改变了一块代码的时候，不必更改另外一块代码。耦合得越低，更改所波及的范围就会越小。

 

1.1.4 代价是什么

  一个框架良好的程序工作起来会让人感觉愉悦，每个人都会变得更加高效。良好的框架会在生产力上产生巨大的差异。

  但是！良好的框架需要很大的努力及一系列准则，每当我们做出一个改变或者实现一个功能时，我们必须很优雅的将它们融入到程序中的其余部分。我们必须非常谨慎地组织代码并保证其在开发周期中经过数以千计的小变化之后任然具有良好的组织性。我们必须考虑程序的哪一个部分应该要解耦然后在这些地方引入抽象。同样地，我们要确定在哪里做一些扩展以便将来很容易应对变化。

 

1.5 性能与速度

1.6 坏代码中的好代码

1.7 寻求平衡

  开发中我们需要考虑的几个因素：

  1.我们想要获取一个良好的架构，这样在项目的生命周期中便会更容易理解代码。

  2.我们希望获得快速的运行时性能。

  3.我们希望快速完成今天的功能。

1.8  简单性

  我们应该致力于保持数据结构和算法的正确性（在这个顺序下），然后继续往下做。如果能保持简单性，代码量就会少很多。这意味着更改代码时，我们的脑袋里只需装在更少的代码。但是请注意，并不是简单的代码会花费较少的时间来编写。我们可能会觉得最终的代码量更少了，但是一个好的解决方案并不是更少的实际代码量，而是对代码的升华。

 

总结：

  1.抽象和解耦能够使我们的程序开发变得更快和耕简单。但不要浪费时间来做这件事，除非我们确信存在问题的代码需要这种灵活性。

  2.在我们的开发周期中要对性能进行思考和设计，但是要推迟那些降低灵活性、底层的、详尽的优化，能晚则晚。

  3.尽快地探索我们的游戏的设计空间，但是不要走得太快留下一个烂摊子给自己。毕竟我们将不得不面对它。

  4.如果我们将要删除代码，那么不要浪费时间将它整理得很整洁。

  5.最重要的一点，若要做一些有趣的玩意儿，那就乐在其中地做吧。

  

 

 

 

 

 

 

 

---恢复内容结束---