架构、性能、游戏
-
在开始读第一章的时候会觉得有点混乱，作者提出了什么是架构这个问题，但是并没有像其它书里那样给出一个明确的定义，而是提到了：
这本书是关于上面这一切要使用的代码的组织方式。这里少谈代码，多谈代码组织。
-
仔细品读这句话，你会发现这里面其实已经提到了什么是架构：所谓架构就是代码的组织方式。但是从我个人的认识来看这并不够全面，在这里在引用几段《架构漫谈》中的文字来阐述什么是架构：
在每个人都必须自己完成所有生活必须品的生产的时候，是没有架构
的(当然在个人来讲，同一时刻只能做有限的事情，在时间上还是可能会
产生架构的)。一旦产生的分工，就把所有的事情，切分成由不同角色的什么是架构
人来完成，最后再通过交易，使得每个个体都拥有生活必须品，而不需要
每个个体做所有的事情，只需要每个个体做好自己擅长的事情，并具备一
定的交易能力即可。这实际上就形成了社会的架构。那么怎么定义架构呢?以上面这个例
子为例，把一个整体(完成人类生存的所有工作)切分成不同的部分(分 工)，由不同角色来完成这些分工，并通过建立不同部分相互沟通的机制， 使得这些部分能够有机的结合为一个整体，并完成这个整体所需要的所有 活动，这就是架构。软件架构实际上包括了:代码架构， 以及承载代码运行的硬件部署架构。实际上，硬件部署架构最终还是由代 码的架构来决定。因为代码架构不合理，是无法把一个运行单元分拆出多 个来的，那么硬件架构能分拆的就非常的有限，整个系统最终很难长的更大。
关于架构和性能的冲突，我认为这个点写的很好，可以说我之前没有这样的认识。长久以来我都希望写出非常面向对象的代码，在我长久的认知中，代码的灵活性、高扩展性和可维护性是最重要的，因此设计模式是我在编写代码时所追求的。
但是作者提出良好的架构是需要很大的代价的，因为这需要遵守一些列的准则，Coder必须谨慎的组织代码，而且在引入了抽象，引入了可扩展性，引入的某个设计模式时，我们在增加了代码的灵活性的同时也增加了不可读性，增加了代码复杂度，这就增加了理解的难度。过度的架构设计往往会导致代码库失控，也许你会看到接口和抽象无处不在，我们可能需要花费大量时间才能找到真正功能的代码。关于这一点我也是深有体会，最近在看UniRx库，发现各种接口齐飞，大量的重载，梳理起来确实很费劲。
同时，从代码本身执行角度来说，灵活的代码往往意味着执行速度比较慢。从UNITY的角度来说，因为有类似CLR的东西，当使用面向接口编程时，往往意味这具体类型的判断需要在运行期，JIT做的越多，性能也越差。而且还很可能导致无法实现代码缓存，每次运行都需要实时的做判定。
原型代码
- 原型代码中可能包含大量的一次性代码，但是原型代码往往意味着不可维护，必须被重写。目前在项目的开发过程中，往往出现原型代码被最终使用在项目中，简直就是灾难。
寻求平衡
快速编写出的代码未必是执行最快的代码，而且这样的代码在后面往往需要花费很多时间来优化，这都是需要时间的。这些都需要平衡。
我们在工作中就是在不断的寻找平衡，有时候看到自己写的或者别人写的代码，就想去重构一下，但是现实又往往不给这个时间。
