第一部分地址 https://gpp.tkchu.me/architecture-performance-and-games.html
什么是好的软件架构？
对我而言，好的设计意味着当我作出改动，整个程序就好像正等着这种改动。 我可以仅调用几个函数就完成任务，而代码库本身无需改动。评价架构设计的好坏就是评价它应对改动有多么轻松。
这听起来很棒，但实际上不可行。“把代码写成改动不会影响其表面上的和谐”就好。
你如何处理改动？
在你改动代码去添加新特性，去修复漏洞， 你需要理解代码正在做什么。
你将一些代码加入了游戏，但肯定不想下一个人被留下来的小问题绊倒。 除非改动很小，否则就还需要一些微调新代码的工作，使之无缝对接到程序的其他部分。
解耦帮了什么忙？
可以用多种方式定义“解耦”，但我认为如果有两块代码是耦合的， 那就意味着无法只理解其中一个。 如果解耦了它们俩，就可以单独地理解某一块。
解耦的另一种定义是：当一块代码有改动时，不需要修改另一块代码。 肯定也得修改一些东西，但耦合程度越小，改动会波及的范围就越小。
代价呢？
天下没有免费的午餐。好的设计需要汗水和纪律。 每次做出改动或是实现特性，你都需要将它优雅的集成到程序的其他部分。 需要花费大量的努力去管理代码， 使得程序在开发过程中面对千百次变化仍能保持它的结构。
你得考虑程序的哪部分需要解耦，然后再引入抽象。 同样，你需要决定哪部分能支持扩展来应对未来的改动。 每当你添加了抽象或者扩展支持，你就是在赌以后这里需要灵活性。当你过分关注这点时，代码库就失控了。导致接口和抽象无处不在，插件系统，抽象基类，虚方法，还有各种各样的扩展点。
性能和速度？
软件架构和抽象有时因损伤性能而被批评，而游戏开发尤甚。 让代码更灵活的许多模式依靠虚拟调度、 接口、 指针、 消息和其他机制， 它们都会加大运行时开销。
一种折中的办法是保持代码灵活直到确定设计，再去除抽象层来提高性能。
糟糕代码的优势？
但就像早先提到的，游戏设计需要很多实验和探索。 特别是在早期，写一些你知道将会扔掉的代码是很普遍的事情。
原型：一坨勉强拼凑在一起，只能完成某个点子的简单代码，是个完全合理的编程实践。 虽然当你写一次性代码时，必须保证将来可以扔掉它。可抛弃的代码即使看上去能工作，也不能被维护，必须重写。 如果有可能要维护这段代码，就得防御性地好好编写它。
保持平衡？
有些因素在相互角力：
1. 为了在项目的整个生命周期保持其可读性，需要好的架构。（需要时间维护，思考可能的扩展）
2. 需要更好的运行时性能。（代码更容易变到不灵活，很难改动）
3. 需要让现在想要的特性更快地实现。（更容易考虑不周）
总有今日事今日毕的压力。但是如果尽可能快地实现特性， 代码库就会充满黑魔法，漏洞和混乱，阻碍未来的产出。没有简单的答案，只有权衡。
糟糕的代码很少是运行时最快的，提升性能需要很多的开发时间。而高度优化的代码不灵活，很难改动，会污染代码库。
简单？
最近，我感觉如果有什么能简化这些限制，那就是简单。在我现在的代码中，我努力去写最简单，最直接的解决方案。正确获得数据结构和算法，然后再从那里开始。注意我并没有说简单的代码需要更少的时间编写， 好的解决方案不是往代码中注水，而是蒸干代码。
最后？
还有些建议给你，希望对你有用：
抽象和解耦让扩展代码更快更容易，但除非确信需要灵活性，否则不要在这上面浪费时间。
在整个开发周期中为性能考虑并做好设计，但是尽可能推迟那些底层的，基于假设的优化，那会锁死代码。
快速地探索游戏的设计空间，但不要跑得太快，在身后留下烂摊子。毕竟你总得回来打扫。
如果打算抛弃这段代码，就不要尝试将其写完美。摇滚明星将旅店房间弄得一团糟，因为他们知道明天就走人了。
但最重要的是，如果你想要做出让人享受的东西，那就享受做它的过程。