1.1 什么是软件架构
代码的组织方式
1.1.1 什么是好的软件架构
衡量一个设计好坏的方法就是看它应对变化的灵活性
1.1.2 你如何做出改变
- 大脑加载相关代码（有“亿”点痛苦）
- 想出解决方案并执行
- 清理
- 测试（最好是自动化的）
1.1.3 我们如何从解耦中受益
- 如果两块代码耦合，意味着你必须同时了解它们
- 如果解耦了，那么只需了解你关注的（减少加载到大脑的成本），且改动影响越小
- 目标：在你前进前，最小化脑海中的知识储存量
1.2 （解耦）有什么代价
- 良好的架构需要很大的努力及一系列准则
- 你必须考虑程序的哪一部分应该要解耦然后引入抽象，和考虑哪些地方需要为扩展做准备
- 增加了代码量、复杂性和程序的理解难度
- 找到有实际功能的代码花费的时间变长了
1.3 性能和速度
- 许多设计模式让代码更加灵活，但是它们依赖于至少有一些运行成本（虚函数、接口、消息）的机制，从而会影响到游戏的性能
- 开发速度是让游戏变得有趣的关键性因素（快速迭代）
- 将一款有趣的游戏做得高效要比将一款高性能的游戏做得有趣更简单些（先考虑有趣，即迭代速度，再优化性能）
- 一种折中的办法是保持代码的灵活性，直到设计稳定下来，然后去除一些抽象，以提高游戏的性能
1.4 坏代码中的好代码
- “原型”是一个完全正确的编程实践（虽然通常不那么优雅）
1.5 寻求平衡
没有简单的答案，只有权衡
- 良好的架构、运行性能、开发速度，这三者不可能同时兼顾的，得根据开发阶段有所取舍
- 架构：好的架构从长远来看，改进了生产力，但维护它意味着每一个变化都需要更多的努力
- 性能：优化需要消耗工程时间。一旦完成，也会使代码僵化：高度优化过的代码缺乏灵活性
- 速度：若我们尽可能快完成功能，则代码库中就会充满补丁、bug和不一致的混乱，消磨掉架构的灵活性（未来的生产力）
1.6 简单性
若有任何方法来缓解这些限制，那便是简单性了
- 在我现在的代码中，我努力去写最简单，最直接的解决方案
- 目标是正确获得数据结构和算法，然后再从那里开始。我发现如果能让事物变得简单，最终代码就更少，就意味着改动时需要更少的代码载入脑袋
- 它通常跑得很快
- 注意并不是说简单的代码只需要更少的时间来编写，好的解决方案是将代码升华（先繁多后精简）
1.7 准备出发
建议：
- 抽象和解耦能够使得你的程序开发变得更快和更简单。但不要浪费时间来做这件事，除非你确信存在问题的代码需要这种灵活性（勿过度设计）
- 在你的开发周期中要对性能进行思考和设计，但是要推迟那些降低灵活性的、底层的、详尽的优化，能晚则晚（先保证开发速度与灵活性）
- 尽快地探索你的游戏的设计空间，但是不要走得太快留下一个烂摊子给自己。毕竟你将不得不面对它
- 如果你将要删除代码，那么不要浪费时间将它整理得很整洁
