什么是好的软件架构

架构是关于改动的

        总会有人改动代码。如果没人碰代码，那么它的架构设计就无关紧要。

        评价架构设计的好坏就是评价它应对改动有多么轻松。没有了改动，架构好似永远不会离开起跑线的运动员

如何处理改动

在改动代码去添加新特性，去修复漏洞，或者随便用文本编辑器干点什么的时候， 需要理解代码正在做什么

除非改动很小，否则还需要一些微调新代码的工作，使之无缝对接到程序的其他部分。如果这部分做到位，那么下个编写代码的人无法察觉到哪些代码是新加入的。

代码解耦

如何理解“解耦”

1、如果有两块代码是耦合的， 那就意味着无法只理解其中一个。 如果解耦了它们俩，就可以单独地理解某一块。

2、从后期阶段来看。 解耦的另一种定义是：当一块代码有改动时，耦合程度越小，改动会波及的范围就越小。

这是软件架构的关键目标： 最小化在编写代码前需要了解的信息

如何维护“解耦”

编码过程中，需要花费精力管理代码，使得程序在开发过程中面对变化也能保持它的结构

考虑程序的哪部分需要解耦，然后再引入抽象。 同样，需要决定哪部分能支持扩展来应对未来的改动。

维护成本&代价

解耦是为了更好的维护代码

但很多时候开发者并不清楚这个模块是否需要足够的灵活性，更多时候是在“赌”以后这里需要灵活性，并为此花费更多的时间开发、调试和维护。

模块化如果最终无益，那就有害。毕竟得为此处理更多的代码。

当过分关注这点时，代码库就容易失控了。开发过程中很容易沉浸在代码中，而忽略了目标是要发布游戏，对可拓展性的过分强调使得开发者花费更多时间制作“引擎”，却没有搞清楚引擎为了什么。

性能和速度

软件架构和抽象有时因损伤性能而被批评。

让代码更灵活的许多模式依靠虚拟调度、 接口、 指针、 消息和其他机制， 它们都会加大运行时开销。

很多软件架构的目的是使程序更加灵活，作出改动需要更少的付出，编码时对程序有更少的假设。 使用接口可以让代码可与任何实现了接口的类交互，而不仅仅是现在写的类。

但并不意味着灵活性不好，它可以让我们快速改进游戏，开发速度对创造更好的游戏体验来说也很重要。

如何做好平衡

要么在损失一点点性能的前提下，让你的程序更加灵活以便更快地做出原型；

要么就优化性能，损失一些灵活性。

并没有绝对的答案，这种的办法就是保持代码灵活直到确定设计，再去除抽象层来提高性能。

糟糕代码的优势

需要坚持用正确的方式写代码，但也需要理解糟糕代码并非一无是处

编写架构良好的代码需要仔细地思考，这会消耗很多时间。 在项目的整个周期中保持良好的架构需要花费大量的努力。

但游戏设计需要很多实验和探索。 特别是在早期，写一些明确将会扔掉的代码是很普遍的事情。

良好的架构就意味着在屏幕上看到和获取反馈之前要消耗很多成本。 如果最后证明这点子不对，那么删除代码时，那些让代码更优雅的工夫都会付诸东流。

该怎么正确编写一次性代码？

        当你写一次性代码时，必须保证将来可以扔掉它。

        即使看上去能工作，也不能被维护，必须重写。 如果有可能要维护这段代码，就得防御性地好好编写它。

如何保持平衡

主要三个因素：

        1、为了在项目的整个生命周期保持其可读性，需要好的架构

        2、需要更好的运行时性能

        3、需要让现在想要的功能更快实现

核心只有“权衡”，很多时候“没有正确的答案，只有不同的错误”。

没有必要过分抵触权衡后所造成的负面后果，合理的规划成本、代价，挑选出当下所能决策的最优解即可。

简单的编码思路

尽可能写最简单，最直接的解决方案，在读完代码后，能完全理解它在做什么。

但简单的代码不意味着需要更少的时间编写，但好的解决方案不是往代码中注水，而是蒸干代码。