云风的个人空间 : 《代码大全》读书笔记

你的足迹: » 《代码大全》读书笔记

这是一个旧版本的CodeComplete于2006-04-19 18:41:50.

P7 把主要精力集中于构建活动，可以大大提高程序员的生产率。
在最近的一个项目中，对于这一点，我是深有体会。我们花了很长的时间做设计，结果接下来的许多工作都在愉快的心情下完成。我觉得 P28 的那个食物链的例子更有说服力，健康的生态环境中，海鸥吃新鲜的鲑鱼，鲑鱼吃新鲜的青鱼，青鱼吃新鲜的水蝽。这是一条健康的食物链。 如果环境被污染了，水蝽在污染的水域游泳，那么海鸥，食物链的最后一环吃下的不仅仅是是不健康的鲑鱼体内的垃圾，还有青鱼，水蝽体内的污染物。软件开发中，架构师吃掉需求，设计师吃掉架构，程序员，软件食物链的最后一环，消化掉设计。如果一开始就被污染了，我们就不要指望程序员快乐了。整个软件都会具有放射性，周身都是缺陷，绝对导致程序员脾气暴躁、营养失调。在我们规模不大的团队里，一个人身兼数职，伤害更大。所以，项目一开始就决定了它能否成功。

P7 源代码——往往是对软件的唯一精确描述
其实我们不必为没有精确的文档沮丧，不是吗？

P13 常见的软件隐喻
好的隐喻可以让我们思考更多的问题，并走上正确的道路。我们是在 Writing Code，还是 Growing a System 还是 System Accretion 或是 Building Software ? 做不同软件有不同的方法，不要拘泥。

P24 避免使用错误的方法制造正确的产品
往往我们在软件开发中会很强调测试。的确、测试是质量的保证。但是测试只保证有质量的代码，却不保证有质量的设计。

P42 需求的 checklist
其实我们不必去造本宣科的写需求分析书什么的，做需求分析即使是在大脑中，口头交流上完成，也是有这么一个过程。落下文字固然是好的，但并不是重点。关键在于做不做。是否详细定义了系统的全部输入，包括来源、精度、取值范围、出现频率。是否详细定义了系统全部输出，包括目的，精度，取值范围、出现频率，格式？是否定义了机器内存和剩余磁盘空间的最小值？是否详细定义了系统的可维护性，包括适应特定功能的变更、操作环境的变更、与其他软件的接口的变更能力？书中列的远比我这里列出的多，非常值得一读。定下这些是很重要的，我觉得合理的游戏开发，是有一个相对稳定的策划方案，和一些已经完成完成的美术资源。大部分的变更都留在下一版本去做。策划和美术永远为下一个版本工作，而程序可以根据相对稳定的需求做设计。这样做，即使第一个版本是不可玩的，扔掉，也是能让游戏最终成功。

P46 数据设计
我曾经很迷惑项目文档到底要写什么？这里列举的一些东西解开了我一些疑惑。如果你选择使用一个顺序访问的列表表示一组数据，就应该说明为什么顺序访问比随机访问更好。（往往随机访问更为高效）在构建期间，这些信息让你能洞察架构师的思想。在维护阶段，这种洞察力是无价之宝。 后面 P58 有个更为有趣的例子：Beth 想做丈夫 Adbul 家祖传的炖肉。Adbul 说，先撒上胡椒和盐，然后去头去尾，最后放在锅里盖上盖子炖就好了。Beth 就问了，“为什么要去头去尾呢？” Abdul 回答说，我不知道，我一直这么做，这要问我妈。他打电话回家一问，母亲也说不知道，她一直这么做，这个问题要问奶奶。母亲就打了个电话给奶奶，奶奶回答说，“我不知道你为什么要去头去尾，我这么做是因为我的锅太小了装不下”:D 架构应该描述所有主要决策的动机。

P48 国际化和本地化
国际化常常被称为 i18n 是因为 Internationalization 这个单词太长了，I 和n 之间有 18 个字母。同理，通常本地化简写为 l10n 。这个工作一定要在构架期想好啊，到底我们需不需要 i18n 或者支持 l10n 就够了，到底用 utf16 还是 utf8 还是 ascii 串就可以。是代码中嵌入字串，还是封装到一个类，还是可以放去一个配置文件。我们现在的项目，一开始考虑岔了，结果后来花了很多精力重构。好在发现问题不算晚，否则代价更高。引申的想一想，发现问题我们应该最早的解决，不要怕做出错误的决定，因为更可怕的是，意识到错误后，因为害怕修正错误的代价过大，而一拖再拖。代码的 bugfix 大家都知道应该立刻做，但是设计失误却容易被放过，将就着做下去。

P51 过度工程
这个问题把握好并不容易。一方面，我们希望系统健壮，如果组成系统的各个部分只在最低限度满足健壮性要求，那么整体通常是达不到要求的。软件健壮性不取决于最薄弱的一环，而是等于所有薄弱环节的乘积。构架应该指出每个部分，程序员为了谨慎而宁可做过度工程，还是做出简单的能工作的东西就够了。有些东西是不应该过分花精力的，这个错误我们也犯过，尤其一些一开始就知道以后很可能要重构的部分，大量的精力花在里面很浪费。

P62 选择编程语言
我曾经也觉得 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 。

P68 Programming into a Language
注意，这里是 into 而不是 in 。书这里用了一个 vb 的例子来说明，恰好我也有个例子。我们现在用 C++ 构建系统，C++ 里有个相当麻烦的东西，就是单件的生存期问题。一个 singleton 到底什么时候创建出来，什么是否析构，相信很多 C++ 程序员在构建大系统的时候都头痛过。据我所知，我们公司别的项目的同事到现在还在头痛这个问题。这次我做了一个约定，禁止任何模块的代码构造静态对象，也就是说，任何在 main 函数前自动的对象构造过程和 main 函数之后的自动析构过程都是不允许的。然后我们有一整套管理单件的方法供使用，这个问题被很好的解决了。我们再也没有为某个单件什么时候构造出来的，或是为什么他提前析构了的问题烦恼过。

P78 管理复杂度的重要性
我们做软件，就是在和问题的复杂度做斗争。有三个问题需要注意：用复杂的方法解决简单的问题；用简单但错误的方法解决复杂的问题；用不恰当的复杂方法解决复杂的问题。

P80 high fan-in 和 high fan-out
高内聚，低耦合很容易被重视。但是高扇入低扇出有时候会被忽略。这里是说，我们应该尽量的大量的使用某个低层次上给定的类(high fan-in) 而每个类都应该尽量少使用其他的类(控制在7个之下)。

P83 子系统间尽量减少联系
书里的例子很贴切。一个通用的规则是，如果 A 系统用到 B ，B 又用到 C ，那么 C 就不要再用到 A 了。系统层的设计图应该是无环图。

P91 封装不仅仅是有简化过的模型看到复杂的概念，而且同时还不能让你看到复杂概念的任何细节
隐藏信息的重要性毋庸质疑。所以我们现在不仅用 C++ 的 private 隐藏信息。还用接口的方法，不在头文件暴露任何设计细节。另外，任何一个不满足现状的程序员，对自己以前的代码一定不会满意。但是复用老的不满意的代码并非坏事。我们需要做的是，重用的时候，把老的东西隐藏起来。

P99 预料不同程度的变化
好的设计人员应该对以后可能变化的部分很敏感。这点很有体会，我自己就是这样一步步过来的。做一个决定之前，想想如果他做错了的后果。估计未来改变的成本，以作出合适的设计，非常的重要。系统为了适应每种变化而做过度设计又是不合适的。到底怎样设计，需要良好的感觉。

P101 耦合的种类
松散耦合是每个系统设计人员所追求的东西。但是其标准往往把握不准。举个简单的例子，不一定恰当。在我最早的设计里，系统把坐标这个东西封装成一个叫做 point ，以后参数传递都传 point * ，而不是 x,y 。这看使很合理。但是，这的确增加了耦合度。因为每个类都需要知道 point 的细节。很多情况下，用简单类型做参数传递反而更合适。(到底传 point * 还是 x,y 依旧要根据实际情况靠量) 参数过多也会导致耦合度的增加，从这个角度看，x,y 是两个参数， point * 是一个参数。关于耦合程度的问题，没有绝对唯一的标准。书里的阐述和总结非常值得一看。

P103 查阅常用的设计模式
设计模式这个东西，给程序员带来的最大的好处就是增加了交流的便捷。一个人可以思考的深度取决于他用于思考的语言掌握的词汇量。设计模式也可以给程序员带来这种便捷。其实常用的设计模式，即使你没有看过《设计模式》这本书，只要你是一个经验丰富的程序员，这些估计大多考虑过。但是，给设计模式起个名字，却可以加快伙伴间的交流。不过必须警惕一个陷阱，那就是为模式而模式。强迫代码去使用某个模式是很危险的。

P106 避免失误
失败的经验比成功的经验重要。如今网游开始尤其。我们的游戏能成功，是因为我们在失败后吸取教训，小心谨慎。我们的代码未必质量高很多，但是很多业内同任做出的东西吸取了许多人家成功的经验却失败了，正是因为他们缺少对失败教训的学习。

P111 自上而下和自下而上的设计方法
很多人都赞同自上而下的设计方法，把问题逐步分解，再分而治之。而我喜欢至下而上的设计方法。先把绝对要做的模块做了，再考虑怎么把他们搭起来。但是我在实际操作的时候往往是，自下而上的做，自上而下的思考。书这里对两种方法的优缺点的总结非常精辟。我特别同意最后的结论，这两种方法并不是互相排斥的——你会受益于二者的相互协作。

P114 开发人员不把原型代码当作可以抛弃的代码。
这个问题很严重，我多次看到过了。做原型真的是一个好方法，但一定要明白，有些代码写出来就是为了以后扔掉的。

XHTML 1.0 ::构建于

CooCooWakka 0.0.9rc1