继续阅读代码大全这本书，感觉是好厚好难啃啊。刚刚开始读不久到了作者说把主要精力集中于构建活动，可以大大提高程序员的生产率。我想就一个项目来说，思路和设计是站着主导的地位的，你如果不能把思路理清，可能随时都有可能卡在那里，而一旦灵感来了，你就会想泉涌一样的来思路，我们也算是做了一个小的项目的了，虽然很low吧，但是好歹也算有点体会。我们总是在设计的时候会走投无路，不知所措，以至于每一次开始时都是没有思路起手都只能积压在那里，实在是不知道该怎么做。我觉得 P28 的那个食物链的例子更有说服力，健康的生态环境中，海鸥吃新鲜的鲑鱼，鲑鱼吃新鲜的青鱼，青鱼吃新鲜的水蝽。这是一条健康的食物链。 如果环境被污染了，水蝽在污染的水域游泳，那么海鸥，食物链的最后一环吃下的不仅仅是是不健康的鲑鱼体内的垃圾，还有青鱼，水蝽体内的污染物。软件开发中，架构师吃掉需求，设计师吃掉架构，程序员，软件食物链的最后一环，消化掉设计。如果一开始就被污染了，我们就不要指望程序员快乐了。整个软件都会具有放射性，周身都是缺陷，绝对导致程序员脾气暴躁、营养失调。在我们规模不大的团队里，一个人身兼数职，伤害更大。所以，项目一开始就决定了它能否成功。
接着是其实我们不必去照本宣科的写需求分析书什么的，做需求分析即使是在大脑中，口头交流上完成，也是有这么一个过程。落下文字固然是好的，但并不是重点。关键在于做不做。是否详细定义了系统的全部输入，包括来源、精度、取值范围、出现频率。是否详细定义了系统全部输出，包括目的，精度，取值范围、出现频率，格式？是否定义了机器内存和剩余磁盘空间的最小值？是否详细定义了系统的可维护性，包括适应特定功能的变更、操作环境的变更、与其他软件的接口的变更能力？ 书中列的远比我这里列出的多，非常值得一读。定下这些是很重要的，我觉得合理的游戏开发，是有一个相对稳定的策划方案，和一些已经完成完成的美术资源。大部分的变更都留在下一版本去做。策划和美术永远为下一个版本工作，而程序可以根据相对稳定的需求做设计。这样做，即使第一个版本是不可玩的，扔掉，也是能让游戏最终成功。我现在也很迷惑项目文档到底要写什么？这里列举的一些东西解开了我一些疑惑。如果你选择使用一个顺序访问的列表表示一组数据，就应该说明为什么顺序访问比随机访问更好。在构建期间，这些信息让你能洞察架构师的思想。在维护阶段，这种洞察力是无价之宝。 后面 P58 有个更为有趣的例子：Beth 想做丈夫 Adbul 家祖传的炖肉。Adbul 说，先撒上胡椒和盐，然后去头去尾，最后放在锅里盖上盖子炖就好了。Beth 就问了，“为什么要去头去尾呢？” Abdul 回答说，我不知道，我一直这么做，这要问我妈。他打电话回家一问，母亲也说不知道，她一直这么做，这个问题要问奶奶。母亲就打了个电话给奶奶，奶奶回答说，“我不知道你为什么要去头去尾，我这么做是因为我的锅太小了装不下”:D 架构应该描述所有主要决策的动机。
读的虽然很少但是感觉是有一些作者想给我们的东西在里面的，我想前人的经验让我们更好走路，我希望我不是只走老路。