《Game Programming Pattern》游戏编程模式读书笔记之架构、性能和游戏

前言：

《游戏编程模式》是一本关于游戏的设计模式的书籍，主要讲解如何架构代码；原版为英文版，有电子版本，网络上也有翻译的中文版本，另外我也参考了知乎的一些读书笔记，结合个人理解做了点笔记；

参考：

1.《Game Programming Pattern》英文原版

2.游戏编程模式中文翻译

3.其它读书笔记，知乎-游戏设计模式(一) 序言：架构，性能与游戏

正文：

本文主要内容就是关于游戏编程模式的序言，在序言中，作者高屋建瓴地提出了一些非常深刻的概念，大大加深了读者对代码设计的理解，以下标红加粗部分基本为书中原文提炼；

一、什么是软件架构

什么是好的架构：好的设计意味着当我作出改动，整个程序就好像正等着这种改动；说明在架构过程中就考虑到了需求的扩展，就已经把未来需要的变动抽离出来了；

架构的关键点是架构是关于改动的，所以评价架构设计的好坏就应该是它应对改动有多么简便；（这里单纯考虑架构，不考虑性能）；

如何在实际开发中证明一个架构是好的架构：当你为项目需求扩展代码后，其它人察觉不出哪段代码是新的；如果你已经提前为需要变动的部分做了抽象，那后来的变更仅仅是调用接口就好了，否则，就需要做大量多余的工作，就像打了个补丁一样，一眼就能看出来是后来加上的；

如何处理改动

当我们需要去修复漏洞或者添加新特性的时候，我们需要理解代码正在做什么；在很多关于重构的书籍内都会讲到，当我每次添加新需求的时候，如果之前没有考虑到扩展，那就需要重新审视这个问题，然后重构自己的这段代码（这里就是延迟设计的概念）；

所以处理改动，就是要将所有相关的东西纳入思考范围，考虑到正确的上下文，然后给出解决方案，而实际的编码有时是微不足道的；我们在处理改动时，应该把更多的时间花在设计上，而不是急于编码；下面借了一张流程图，其实这就是一个不断重构的闭环流程；

 解耦的好处

解耦的好处有很多，这里集中从代码的可维护性和复用性阐述一下；

首先是可维护性，如果我们需要修改一段其它人模块的代码，注意上文，当我们需要改动的时候，我们需要将所有相关东西纳入思考范围；如果代码耦合度过高，那么我们就需要考虑非常多的东西，而如果我们能够解耦成多个模块，就只需要思考单独的一个模块就够了；

然后就是复用性：耦合的代码很难去复用，而DRY(dont repeat yourself)是软件工程的核心；

如何解耦：最小化在编码前需要了解的信息；也就意味着，不要让你的信息过于庞杂，而是类似于单一职责的思想，去细分它的粒度；

二、代价

解耦任何东西，然后像风一样编码，每一个改动都只需要修改一两个特定方法，这就是抽象、模块化、设计模式和软件架构带来的好处；

但是为了做出好的架构：就需要每次做出改动或实现特性时，都要将它优雅地继承到程序的其它部分；所以，必须要考虑到那部分需要解耦，然后再引入抽象，同样考虑哪部分需要支持扩展，从而应对未来的改动；不要到处都是抽象接口，如果没有确定的扩展需求，就不需要抽象，可以等到需求到来时再重构；

三、糟糕代码的优势

编写架构良好的代码需要仔细思考，而在整个项目周期中保持良好的架构需要花费更多的努力；但是有时候，特别是项目早期制作原型时，写一下一次性代码很正常；但是必须保证以后可以将一次性代码扔掉；要记住：一次性代码即使看上去能工作，也不能被维护，必须重写；如果需要维护，就不要写一次性代码；

四、一些建议

抽象和解耦让扩展代码更快更容易，但除非确信需要灵活性，否则不要在此浪费时间；这也就是之前总结的延迟设计的概念；

在整个开发周期中为性能考虑并做好设计，但是尽可能推迟那些底层的、基于假设的优化；对于假设的，未知的，可以暂不考虑；