源自: http://www.seaskyblog.com/?p=4 海阔天空的博客
《代码大全》是到目前为止,让我感触最深的一部计算机书籍了,可以说是计算机书籍中的进阶提高班。这是第二遍读《代码大全》,之前看的有些遗忘,这次决定看书过程中打个标签(Kindle 的多看系统支持 pdf 标记书签,并上传同步到 Evernote 笔记中),而后结合实际的开发经历,写点读书笔记。
《代码大全》--读书笔记
第一章 软件创建的世界
P1:“问题定义、需求分析、实现计划、总体设计、详细设计、创建即实现、系统综合、单元测试、系统测试、校正性维护、功能强化。”
在正式的开发环境中,我们所说的编程包括上述所有,而在非正式或者更简化的环境中,往往只有“创建即实现”的过程。这个过程可以根据实际情况来简化,但是如果做计划的话,编程的时间最多只能占到时间预算的 50%,剩余的时间一定要留给足够的设计和测试(包括自我调适)的时间,设计可以留20%的时间,测试要留30~50%的时间。假如是两周的开发任务,那么必须要在第一周的时间完成设计和编码的工作,在第二周开始则着手测试及调适优化的工作。
第二章 利用隐喻对编程进行更深刻的理解
P9:“建造隐喻暗示了许多诸如计划、准备、执行等工作阶段”。
软件工程和建筑有很多类似的地方。如多大的工程就要费多大的精力去设计,以及多大的人力去建造。但也有更多不同的地方如,软件构建不以人力增加而减小工期,软件构建在后期允许推倒重构设计,但建筑却不行。(不过现在还没想到比“建造”一次更适合软件工程的隐喻)。
第三章、软件创建的先决条件
P30:“如果想开发一个高质量的软件,必须自始至终重视软件质量问题。在开始阶段强调质量往往比在最后强调质量更为有效”、“如果问题定义的不好,那么在编程阶段,所解决的问题可能并不是用户真正要解决的问题。”、“如果需求做的不好,在编程后修改的要比在需求分析时修改的成本要高20~100倍。”
拿到需求就开始写代码的程序员注定是个悲剧。
不搞清楚需求的程序员注定是个悲剧。
编码过程中还没想清楚原理,还没搞清楚问题本质的程序注定是个悲剧。
任何马马虎虎、想蒙混过关的程序员注定是个悲剧。
第四章 建立子程序的步骤
P31:“设计程序、子程序编码、检查代码”。
实际开发中可能从来没有想到过的事情,在这里都有充足的描述。而且每一个过程都极其重要,比如设计程序要求你必须充分理解这段程序的意图,输入,输出,面向对象、过程或模块设计;子程序编码要求代码规范,布局美观已读,逻辑最简化最清晰化;检查代码要求自我阅读排错,减少后期出现bug时调适的时间,我们往往会犯这种2的事情,测试后期出了问题,结果花费了几天的时间才解决,最终才发现可能就是一个逻辑判断出错的原因,导致耗时耗精力,这种消耗毫无意义,不要觉得自己找个bug很厉害,你应该感到耻辱,去反思问什么会出现这么2的事情。良好的设计、编码、检查,会大大减低这类事情的出现。
第五章 高质量子程序特点
P51:“创建子程序的目的:降低复杂性、避免重复代码、限制改动带来的影响、隐含顺序、改进性能、进行集中控制、隐含数据结构、隐含指针操作、隐含全局变量、重用代码、形成公用基础库、改善可读性、分割复杂性”。
“子程序的命名恰当:动词+名词、避免无意义或者模棱两可、描述子程序的过程、长度要合适(9-15个字符)”
P52:“强内聚:功能、逻辑、过程内聚”
P60:“子程序的长度:100~150行是最佳子程序长度,较强的可维护性、较低代码错误概率。”
P61:“防御性编程:多用断言、做好异常处理、做好返回值处理、提早加入DEBUG信息”。
P67:“子程序参数:顺序是输入、修改、输出;最大参数是7个;考虑怎样区分输入、修改、输出,如加宏定义”
第六章 模块化设计
P75:“模块化:内聚性与耦合性,信息隐藏”
P90:“创建模块的原因很多与创建子程序相同。但模块的概念意义比子程序深远得多。它是比子程序更高层次的设计工具”。
子程序、模块、面向对象。本质上都是一样的,是对问题的抽象思考,抽象的水平越好,代码能力越强。
第七章 高级结构设计
P93:“设计的层次:划分子系统,划分模块,划分子程序,子程序内部的设计”
P97:“自底向上的合成、自顶向下的分解”
P98:“面向对象:抽象、封装、模块、继承”
P105:“往返设计即重构设计,在代码的某一阶段,鼓励重构代码”
设计其实是一个抽象的过程,把问题和事情想清楚了,简单化,抽象化是基本的原则,不论是何种设计、何种工具,目的都在于此。代码的重构,要求的是在考虑到后期维护费劲,且本次修改能有效改善后期阅读和维护的效果,完全可以鼓励重构,要记住代码编写出来后剩下的时间都是在阅读代码,宁愿现在写好点也不要以后阅读耗费更多时间和精力。
第八章 生成数据
第九章 数据名称
P121:命名的首要素是自解释,9~15字符。在常用名称中,要注意其反义词,如insert/delete,open/close,start/stop。循环变量可以用i,j,k,注意临时变量也要好好命名。逻辑变量要用肯定的逻辑,如Done、Error、Success,而不要用 NoDone、NoError、NoSuccess等;枚举内部加前缀,表示在同一组,如Type_Red,Type_Blue。类成员用 m_nBookCounts,临时变量用 nBookCounts。最重要的核心思想是代码自解释。如果你后期再读一遍代码时候感到费劲,那么你可以考虑修改你的代码命名了。
第十章 变量
P142:
尽量减少作用域的范围,不要把一个变量到到处放置,最好集中管理,减少人在同一时间内的要记忆的东西。
变量功能单一
尽量避免全局变量使用,如果必须使用则建立明显标示,如 s_BookCounts,用存取子程序来控制成员变量,而不是随意读写。
第十一章 基本数据类型
P154:
避免使用魔术数字,如 60 秒,可以使用宏 ONE_MINITE_PER_SECONDS = 60 来代替。
检查数据溢出,浮点数不能直接 == 判断
字符串应该初始化为 0
小心数组越界
第十二章 复杂数据类型
P179:
用结构体或者类来代替一堆变量。
表驱动法。例如在 HTTP 请求函数里,可以加一个 map,<string, point>让变量对应函数指针,查找时只需要find map的变量名即可。
抽象数据定义。如类对象的操作,把数据和对数据的操作封装一个类。
第十三章 顺序程序语句
P201:
程序能够由上而下的阅读,变量存活尽量短。相关的语句组织在一起。
DealWindows_1();
DealWindows_2();
DealMessage_1();
DealMessage_2();
第十四章 条件语句
P208:
if else,先写正常,再写异常。
case 也是先正常,后异常处理
第十五章 循环语句
控制好 while 循环,最好只保持在一个地方break,不要在很多地方判断 break,如
if( bSucess || bOver || bTimeout) break;
循环的层次不要超过三层,否则就要考虑使用子函数类处理复杂逻辑。
第十七章 常见的控制问题
简化复杂语句,防止深层嵌套,
第十八章 布局与风格
基本原则是清晰易懂,风格统一。
空格来区分变量和字符串,
空行来划分逻辑分区,分段
对齐和缩进是最基本的语段内逻辑显示控制。
注释和上一段落保持一行
第十九章 文档
P313:
综合资料,软件的非正式文档,可以是查阅的参考资料等,放置在一起,供参考用。
详细设计文档,低层的代码设计和实现文档,可以有,也可以在代码中自解释。
有效的注释,是对一段代码的意图做说明。
第二十章 编程工具
选择固定好用的 IDE 作为开发工具,不要让工具成为累赘,而要让工具成为利器。让更多的精力花费在文档、代码、思考上,而不是花费在捉摸 IDE 工具!!!
第二十一章 项目大小如何影响创建
第二十二章 创建管理
强调代码是公用财产,写代码的目的之一是要让别人看的。
程序员怎样花费自己的时间。每天8小时,只要有5个小时全心投入工作就可以了,剩余的3个小时完全可以休息。
能力差别。同样工龄的程序员,最高效和最低效的比是 25:1 。这个数字比较震撼,看似同样经验的程序员,能力有天壤之别。
第二十三章 软件质量
可维护、可理解、灵活性、可移植性、可重用、可读性。
多设计文档的检查、非正式组内检查、设计检查、正式代码检查、人工代码检查、单元测试、功能测试、系统测试。
阅读代码改错的效率要比调适bug的效率高很多
第二十四章 评审
当局者迷,旁观者清,让别人检查你的工作时正确的。
代码阅读要比其他调适方式多发现 20~60%的bug
第二十五章 单元测试
第二十六章 调试
P417:
调试的误区:靠猜发现错误,不花费时间理解问题,不理解代码就盲目的修改,不注意编译器警告
第二十七章 系统集成
递增基层法
第二十八章 代码调整策略
第二十九章 代码调试技术
第三十章 软件优化
第三十一章 个人性格
P501:
优秀的程序员不一定最聪明,但一定是最谦虚,因为谦虚保持了持续的学习性。
写代码之前先做好分析再下手。
读别人的代码,好的代码或者差的代码,对自身都是一种学习。
大师:大师有着专家对语言环境很深的造诣,并意识到编程知识 15%和计算机交流,其余85%是和人打交道。大师的代码是给人看的,不是给计算机看的,很浅显易懂
第三十二章 软件开发的有关问题
P511:
减少复杂,抽象复杂。以人为本,代码是给人看的,不是简单的应付编译器。