- 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 就够了,到底用 UTF-16 还是 UTF-8 还是 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 开发人员不把原型代码当作可以抛弃的代码。
这个问题很严重,我多次看到过了。做原型真的是一个好方法,但一定要明白,有些代码写出来就是为了以后扔掉的。
- P118 使用数码相机
设计文档不一定要详细的写成规范的文档,重要的是我们做了设计并保留下来,而不是写出漂亮的文档(去蒙投资?)数码相机似乎是一个好东西,这样可以把草稿纸上的乱涂乱画保留下来。我一直觉得铅笔是设计师最好的伙伴。开会的白板也是,虽然现在已经有电子化的白板,但是,昂贵的东西不是所有开发人员都需要的。
- P131 不要让 ADT 依赖于储存介质
这点早就意识的到,类里面最好不要有 readfromfile , writetofile 这样的方法。但是为了方便,往往又会加上这些方法。最终的结果是,依赖文件带来的不便总是比便利要多。同理,依赖文件名也是不恰当的。可悲的是,有些错误犯一次往往不够。意识到这样做的不好是很容易的,真正杜绝它是另一件事。
- P143 在万不得已时通过 private 继承来实现“has a”的关系
private 继承的主要原因是让外层的类能够访问内层被包含类的 protected 成员。根据我自己的经验,让类有 protected 成员本身就不是一件好事。我刚学 C++ 的时候,很多类都有大量的 protected ,但现在,只剩下了 private 和 public 。虽然偶有 protected ,但是我相信,那些都是可以通过改良设计然后去掉的。我不喜欢教条,如果有教条说,不准用 protected ,我会很反感。而实现上,我的感觉会排斥 protected 的使用。
- P174 对于超过 200 行代码的子程序来说,没有哪项研究发现它更够降低成本和/或降低出错率
这是个谁都懂的道理,但是错误我自己也犯过。早几年,我为大话西游编写了一个图文混排的函数,可以在聊天或是其他屏幕文字中同时显示不同的文字,有不同的颜色,状态,效果,还可以显示动画图标。当时图一时方便,还有一些效率原因,我写了一个几百行的函数。再接下来的几年里,我为这个函数多次头痛过,出过不只三次的 bug 。直到在梦幻西游的项目里,这些模块得到全部重写才舒了一口气。长达千行的子程序我也在一些地方见过,那也是非常可怕的。并非所有程序员可以真正认识到这样做的可怕程度吧。
- P176 使用 C++ 中的 const 关键字来定义输入参数
能够正确充分的使用 const 是合格的 c++ 程序员评判标准之一。
- P176 不要把子程序的参数用做工作变量
不要因为想当然的效率因素使用输入参数做工作变量,编译器会帮你优化的。如果这样做,至少在我们公司内部的 codeview 上是要被严重警告的。
- P210 确认留在代码中的错误消息是友好的
读这段的时候想到同事给我讲的一个故事:他以前的同事因为敲出脏话被开掉了,起因是他的老板(也是一个程序员)在调试代码的时候被某个模块的出错信息骂了一通 :D
- P220 通过伪代码编程过程创建子程序
并非所有的代码编写前都要有伪代码的。更古老一点的编程方法里,要求编写程序前先画框图。这种方法我也学习过,但始终不觉得自然。伪代码如果也有条条框框,说不定我也不会去用。但是,实现复杂算法时,这种方法依旧被我使用的最多。一个附带的好处就是,先有了注释,然后删掉多余的;而不是先有代码,再加上注释。
- P238 数据认知测试
哈哈,我得了 28 分(或者是 27.5) ,而且没有被作者的陷阱框住。
- P240 隐式变量声明对于任何一种语言来说都是最具危险性的特性之一
早年,我们用 Lua 的第 4 版写脚本,结果在这个问题上吃过几次大苦头。好在 lua 在第 5 版后增加了 metatable 可以有办法避免这个问题。那就是给 _G 定义一个 __newindex 的 method 。例子在 lua 包里的 test 目录下可以找到,pil 里也应该有提到。
- P244 Rob Pike 建议使用 0xDEADBEEF 这一常量来填充内存,因为在调试器里很容易识别它。
其实还可以用 0xBADF00D 也很有趣,可惜是 7 个字母。有个朋友用这个做网名,我还蹭过一顿饭。:D
- P246 尽可能缩短变量的存活时间
这是一个浅显但实用的道理。p248 里还提到,全局变量的存活时间最长,就凭这一点,我们也应该避免使用。使用全局变量和不使用,是关易写代码和易读代码的区别;也是“方便性”和“智力可管理性”的理念区别。这一节还有个被量化的概念,变量的跨度。把一个临时变量重复使用,在增加了存活时间的同时也增加了其跨度,所以出现了很糟糕的味道。这一点在 P255 又谈了一次。
- P253 绑定时间
一般说来,变量的绑定时间越晚,灵活性越好。这里的关于绑定时间的总结很不错。分别为:- 编码时绑定 (使用 magic number)
- 编译时绑定 (使用命名常量)
- 加载时绑定 (读注册表,配置文件等)
- 对象实例化时绑定 (创建对象时读入)
- 即时 (每次操作时读入)
- P256 避免让代码具有隐含含义
这里有个例子其实我曾经也类似的干过,变量 pageCount 在非负的时候表示已打印纸张的数量,否则,-1 表示有错误发生。这在技术领域里被称为“混合耦合”是应该避免的。pageCount 客串了一个 boolean 类型。如果真的想节省一个变量的空间的话,我觉得使用 union 可能能好些。
-
union { int pageCount; struct { unsigned int unused:31; unsigned int pageError:1; }; };
或许这也不是个更好的方案。
- P298 在程序生命期中尽早决定国际化/本地化策略
关于这个问题,我们吃过的苦头足够说明问题。另外,MS 倡导的 _T() 宏不一定是一个优秀的方案。如果要支持 unicode ,UTF-8 是个不错的选择,虽然不总是最好的。UTF-8 表示汉字时 50% 超出的储存空间好好考虑一下。
- P301 更安全的做法是使用 strlcpy() 或 strcpy_s()
很高兴看到这句话是在译注里列出,可见译者是用了心的。类似的译注,我在侯杰的译书中见过。不过 strlcpy 和 strncpy 的行为还是有区别的,strcpy 往往可以简单的用 strncpy 取代,但是 strlcpy 却没有这个效果。不过我也倾向于用 strlcpy ,它同 strcpy 一样的高效,而且的确也更安全。strncpy 在参数为 NULL 时会出错。
- P305 把 enum 的第一个元素留做非法值
这是这本书读到现在碰到的第一个以前没想过的技巧。一直我都是把非法值定义成最后一个 enum 值,或者定义成一个很大的特殊数字。书这里的道理很充分,因为一些没有合理初始化的变量往往是 0 ,把 0 作为非法值更容易捕捉到错误。
- P309 Monty Python 为 20 世纪 60 年代英国经典电视连续剧,python 语言由此得名。
还是译注,很有趣 :) 我以前并不知道python 的名字是怎么来的。
- p329 简化复杂的指针表达式
上学的时候,我经常写 p->q->r->s.data 这种表达式,当我工作后,被这种表达式坑过几次后,用额外的指针变量来提高代码清晰度(p327) 同样成了我的信条。另外 p329 介绍的画一个图的方法也是被经常使用。
- P330 分配一片保留的内存后备区域
用样来保证程序崩溃的紧急处理所需要的内存是个简洁的方法。
- P364 滥用case语言
把不同的控制结构混在一起用的确是非常糟糕的习惯。不过有时候的确可以带来高一些的效率。我们可以不用它,但是不能读不懂它。这让我想起上次去跟同事一起出差,在火车上他谈到的一个例子:
-
int n = (count + 3) / 4; switch (count % 4) { case 0: do { dosomething0(); case 1: dosomething1(); case 2: dosomething2(); case 3: dosomething3(); } while (--n>0); }
- P374 在 while 循环更适用的时候,不要使用 for 循环
道理早就明白,可是就是老不遵守 :( 我想还是因为懒。
- P376 一个循环只做一件事情
我在自己的书中谈性能时也提到过这一点,其实,合并几件事情在一个循环做不一定可以得到更高的性能。
- P377 避免出现依赖循环下标最终取值的代码
还是一个早就明白的道理,但是错误一犯再犯。
- P384 for 循环变量的作用域
VC 中的语义跟 C++ 标准定义的不一样。MS 推荐一种解决方法:
-
#define for if (0); else for
- P397 如果为我工作的程序员用递归去计算阶乘,那么我宁愿换人
说的好。如果我带的新同事在 C 语言里用递归计算斐波纳契数列,估计我也会教育一下的。
- P399 让代码不包含 goto 并不是目的,而只是结果,把目标集中在消除 goto 上面是于事无益的。
p408 还有一句,如果程序员知道存在替换方案,并且也愿意为使用 goto 辩解,那么用 goto 也无妨。
- P408 软件开发这一领域是在限制程序员对代码的使用中得到发展的
这里举的例子,允许根据行数或者标号调用子程序,是我早年用 basic 时梦寐以求的。不过那个时候 basic 过于简陋,期待这种功能是迫不得已。实在不行的时候还要自己扩展 basic 解释器。
- P429 最后是去找一个好的方案而且同时避免引发灾难,而不要试图去寻找最佳的方案。
我想补充,如果你知道一种更好的方案但是不能完全避免灾难的时候,请注释这种更好的方案。
- P442 这项建议(在等于表达式中的常数写在前面以避免把 == 错误的敲成 = 的问题)与按造数轴排列的建议相冲突。我个人偏向于使用数轴排序法,让编译器来告诉我有没有无意写出的赋值语句。
我也不希望把常数写在前面,但老说不清楚原因。
- 关于剩下的 400 页:代码大全》的确是本好书,虽然厚达九百页,但是却没有什么废话。读书笔记只做到这里,云风也意尤未尽的看完了书的最后一页。缺少后一半的读书笔记并不是说书的后半本不及前半本精彩。相反,我认为后面的某些章节对我的启发更大。只是,后半本书是我花了半个月时间,每天临睡前躺在床上看完的。早上起来,已经懒的在机器上敲下什么文字了。喜欢这篇读书笔记的同学,推荐去买一本《代码大全》耐心的阅读全部。
- laiyuan :http://blog.codingnow.com/cloud/CodeComplete/