找到了一些原来见过和没有见过的专业的名词：
源代码——往往是对软件的唯一精确描述
我们只能做自己最好的去编写源代码。
常见的软件隐喻
我们做软件的不能拘泥于一些死板的东西，要懂得开放思路。
避免使用错误的方法制造正确的产品
经过测试不一定是好代码，但是好代码一定会经过测试并进行修定。
需求的 checklist
CV其实我们不必去照本宣科的写需求分析书什么的，做需求分析即使是在大脑中，口头交流上完成，也是有这么一个过程。落下文字固然是好的，但并不是重点。关键在于做不做。是否详细定义了系统的全部输入，包括来源、精度、取值范围、出现频率。是否详细定义了系统全部输出，包括目的，精度，取值范围、出现频率，格式？是否定义了机器内存和剩余磁盘空间的最小值？是否详细定义了系统的可维护性，包括适应特定功能的变更、操作环境的变更、与其他软件的接口的变更能力？ 书中列的远比我这里列出的多，非常值得一读。定下这些是很重要的，我觉得合理的游戏开发，是有一个相对稳定的策划方案，和一些已经完成完成的美术资源。大部分的变更都留在下一版本去做。策划和美术永远为下一个版本工作，而程序可以根据相对稳定的需求做设计。这样做，即使第一个版本是不可玩的，扔掉，也是能让游戏最终成功。
数据设计
我们写软件一定要先写出来对于这个软件相关数据的设计，由此我们才可以对软件进行下一步缜密的思考。
国际化和本地化
国际化常常被称为 i18n 是因为 Internationalization 这个单词太长了，I 和n 之间有 18 个字母。 同理，通常本地化简写为 l10n 。
这个就是在问我们做出来的软件是想要在当地很小的一个圈子用还是说在整个广阔的天地中使用，这取决于我们软件的能力，也取决于我们的能力。
选择编程语言
CV我曾经也觉得 C++ 是万能的，这种想法很多 C++ 程序员也有。但是无可否认，每种语言的表达力是不同的。书在这页有一张表，如果 C 的表达能力是 1 的话，C++ 和 Java 就是 2.5 。而 perl 和 python 却有 6 。这就是我们选择游戏逻辑脚本编写的原因之一。另外对语言的熟悉程度是很影响程序员的效率的，所以我们不能独立的看语言本身的表达能力。P63 有个例子，用一群 Fortran 背景的程序员去用 C++ 编写一个新系统，结果他们编写出的是伪装成 C++ 的 Fortran 代码。他们扭曲 C++ 来模拟 Fortran 的不良特性并且忽略了 C++ 丰富的面向对象能力。我们这里有个现成的例子，一个 C++ 程序员用 C++/C 的方式写 Lua ，结果可想而知。到现在我还在叮嘱他，一定要理解，再理解 Lua 。lua 不是 C 。
管理复杂度的重要性
我们做软件，就是在和问题的复杂度做斗争。有三个问题需要注意：用复杂的方法解决简单的问题；用简单但错误的方法解决复杂的问题；用不恰当的复杂方法解决复杂的问题。