很久以前就见过这本1000页的书<代码大全>,觉得应该是说些写代码的东西,没怎么又兴趣去读它,一次偶然的机会,发现自己是误解了它,<代码大全>觉得应该叫软件百科好像更合适一点,因为它里面涵盖了架构,分析,设计,编程,测试,重构,面向对象,调试,规范,管理,软件质量控制,协作,优化,开发工具,注释,甚至个性,开发艺术等等等,让人感觉就是一本软件百科全书.
书读的不多,不过刚开始读了100多页有一点感悟,所以做了一点记录,叫读<代码大全>的一点记录之1.
利用隐喻
隐喻通过把软件开发与你所熟知的事情联系在一起,从而使你对其更有深刻的理解,正是因为如此在计算机中的发展不过仅有数十年的历史,却拥有着所有科学最为丰富多彩的语言
盖房子的隐喻
狗屋
霹雳啪啦,木材加铁钉,犯错了怎么办?无所谓,拆了再来过
盖一栋房子
决定什么类型的房子-->问题定义
和某个建筑师探讨总体的设计-->软件架构设计
画出详细的蓝图-->详细设计
打地基,搭建房屋框架,砌墙,盖好屋顶,同水,电,煤气-->软件构建(编程)
油漆工和装修工把新盖的家进行美化-->软件的优化
监查人员来检查工地,地基,布线-->软件的复查
我们会发现很多软件工程学的名称就是从建筑学演变而来的如
软件架构(建筑学 architecture)
支撑性测试代码(脚手架,scaffolding)
构建(建设,construction)
基础类(foundation classes)
摘录
P70：使用隐喻又是件说不清楚的事情。你需要适当地引申它的含义，才能从其中蕴含的深刻启发中受益。但若你过分地或者在错误的方向上引申了它的含义，它也会误导你。正如人们会误用任何强大的工具一样，你也可能误用隐喻，但它的强大的功效，还是会成为你智慧工具箱中的一个宝贵部分
两条食物链
* 健康的生态环境中，海鸥吃新鲜的鲑鱼，鲑鱼吃新鲜的青鱼，青鱼吃新鲜的水蝽。这是一条健康的食物链。
* 软件开发中，架构师吃掉需求，设计师吃掉架构，程序员，软件食物链的最后一环，消化掉设计。
我们知道毒素是往上递增的,如果在软件开发中,从一开始就被污染了,那么每级的污染程度将递增,而程序员在处在食物链的最高层,也是毒素累积的最高层,就必须抗下所有犯下的错误
需求的 checklist
我们是否一定要做需求checklist?书中作者告诉我们并不一定要写需求分析树,但需求分析必须在大脑中,口头交流上完成,落下文字固然是好的,但并不是重点,关键在于做不做,一份checklist就想事一次"心智健全"的检查,看看你的地基是否坚固
详细的checklist包括是否详细定义了系统的全部输入，包括来源、精度、取值范围、出现频率。是否详细定义了系统全部输出，包括目的，精度，取值范围、出现频率，格式？是否定义了机器内存和剩余磁盘空间的最小值？是否详细定义了系统的可维护性，包括适应特定功能的变更、操作环境的变更、与其他软件的接口的变更能力？…..
构建高质量的子程序
书中作者用大篇幅去介绍如何构建高质量的子程序,在此章,作者用一个有问题的子程序罗列出他所指出的所有引发低质量子程序问题,我把以下的一个子程序认为是作者最好的总结
Procedure HandleStuff ( Var InputRec:CORP_DATA,CrntQtr:integer,
EmpRec:Emp_DATA, Var EstimRevenue:Real, YTDRevenue:Real,
ScreenX:integer,ScreenY:integer,Var NewColor:Color_TYPE,
Var PrevColor:COLOR_TYPE,Var Status:STATUS_TYPE,
ExpenseType:integer);
begin
for i := 1 to 100 do begin
InputRec.revenue[1]:= 0;
InputRec.expense[i]:=CorpExpensse[CrntQtr,i]
end;
UpdateCorpDatabase(EmpRec);
EstimRevenue:=YTDRevenue * 4.0 /real(CrntQtr)
NewColor:=PrevColor;
status:=Success;
if ExpenseType＝1 then begin
for i:= 1 to 12 do
Profit[i]:= Revenue[i]-Expense.Type[i]
end
else If ExpneseType= 2 then begin
Peofit[i]:=Revenue[i] - Expense.Type2[i]
end
else if ExpenseType= 3 then
begin
Profit[i]:=Revenue[i] - Expense.Type3[i]
end
end
下面的问题囊括了作者在此章说明的问题
1.程序的名字让人困惑。HandleStuff()能告诉我们程序是干什么的吗？
2.程序没有被说明
3.子程序的布局不好。代码的物理组织形式几乎没有给出其逻辑组织形式的任何信息。
4.布局的使用过于随心所欲，程序每一部分的布局都是不一样的。关于这一点。只要比较一下 ExpenseType=2 和 ExpenseType=3 两个地方的风格就清楚了
5.子程序的输入变量值 InputRec 被改变过。如果它作为输入变量，那它的值就不该变化。如果要变化它的值，就不该称之为输入变量 InputRec。
6.子程序进行了全局变量的读写操作。它从 CorpExpense中读入变量并写给 Profit。它应该与存取子程序通信，而不应直接读写全局变量。
7.这个子程序的功用不是单一的。它初始化了某些变量。对一个数据库进行写操作，又进行了某些计算工作，而它们又看不出任何联系。一个子程序的功用应该是单一，明了的。
8.子程序中没有采取预防非法数据的措施。如果 CrntQtr 的值为“0” ，那么，表达式YTDRevenue*4.0／real(CrntQtr)就会出现被零除的错误。
9.程序中使用了几个常数：100, 4.0, 12, 2 和 3。关于“神秘”(magic)数的问题见 11.1节“常数”
10.在程序中仅使用了域的 CORP_DATA 型参数的两个域。如果仅仅使用两个域，那就该仅仅传入特定的域而不是整个结构化变量。
11.子程序中的一些参数没有使用过。ScreenX和 ScreenY在程序中没有涉及。
12.程序中的一个参数被错误标定了。PrevColor被标定为变量型参数，然而在程序中又没有对其赋值。
13.程序中的参数太多。程序中参数个数的合理上限应该是七个左右。而这个程序中则多达11个。程序中的参数多得怕人，恐怕没谁会仔细检查它们，甚至连数一下都不愿意。
高扇入 和 低扇出
摘录
高内聚，低耦合很容易被重视。但是高扇入低扇出有时候会被忽略。这里是说，我们应该尽量的大量的使用某个低层次上给定的类(high fan-in) 而每个类都应该尽量少使用其他的类(控制在7个之下)。
小结
书中分别很详细的写了架构,设计,编程等等方面的内容,还不分巨细的讨论了函数,变量,语句等编程要点,这些内容基本上都是围绕着软件构建的核心就是管理复杂度来展开的,产生这个根源就在于人脑智力同软件项目复杂度的矛盾.
而解决这矛盾从作者书中总结可能有以下几点:
1.分割
系统分割,设计分割,代码分割....
2.清晰理解
抽象,封装
3.清晰表达
----------------------------------------
by 陈于喆
QQ:34174409
Mail: dongbule@163.com