《代码大全》读后感1

最近在看代码大全，觉得这本书写非常好，这本书没有涉及太多的算法和代码，讲的是一种编程的一种思维模式。下面是节选，我觉得把写软件比喻为建房子非常形象。

“建造”一词的想象比“写”或者“种植’软件的想象更为贴切，它与“增量”软件的想
法是基本一致的。建造隐喻暗示了许多诸如计划、准备、执行等工作阶段。如果你仔细研究这
个隐喻，你还会发现它还暗示着其它许多东西。
建造一个四英尺高的塔需要一双稳健的手、一个平台和十个完好的啤酒罐。而建造一个四
百英尺高的塔却决不仅仅是需要一千个啤酒罐就够了，它还需要一种完全不同的计划和创建方
法。
如果你想建一个简单的建筑物，比如说一个狗舍，你买来了木板和钉子，到下午的时候，
你已经给你的爱犬造好了一幢新房子，假设你忘了修一个门，不过这没关系，你可以补救一下
或推倒一节重新开始。你所浪费的不过是一个下午的时间罢了。这与小型软件的发展失败非常
类似。如果你有 25 行代码设计错了。那你重新再来一遍好了，你不会因此浪费许多的。
然而如果你是在造一幢房子，那修建的过程就要复杂些了，而拙劣设计的后果也严重得多。
首先，你必须决定造一幢什么样的房子，这就像软件开发中的问题定义。然后，你与建筑师必
须搞出一个你们都同意的总体方案，这和软件的总体设计是一样的。接着，你又画出细节蓝图
并找来一位承包商，这相当于软件中的详细设计。下面的工作是选好房址、打地基、建造起房
屋的框架、建好墙壁并加上屋顶、用千斤锤检查墙壁是否垂直，这同软件创建基本差不多。当
房屋的绝大部分工作已经完成时，你请来园艺师和装修师，以便使你的房间和空地得到最好的
利用，这可以与软件优化相类似。在整个过程中，会有各种监督人员来检查房址、地基、框架、
供电系统和其它东西，这也可以与软件开发中的评审和鉴定相类似。
较大的规模和复杂性往往意味着可以产生较大的成果。在修房子的时候，材料可能比较贵，
但更大的花费是劳动力。拆掉一面墙并把它移到六英尺之外是很昂贵的，但并不是因为你浪费
了许多钉子，而是因为你需要付出劳动。你应该尽可能精心设计，以避免那些本可避免的错误，
以降低成本。在开发软件过程中，材料更便宜，然而劳动力成本却更高。改变一个报告的格式，
可能与移走一幢房子里的墙壁一样昂贵，因为二者成本的主要部分都是劳动力。
这两个活动之间还有什么类似之处呢？在建房子中，你不会去建造那些你可以现成买来的
东西，比如洗衣机、烘干机，电冰箱、吸尘器等，除非你是个机械迷。同时，你也会去购买已
经做好的地毯、门、窗和浴室用品，而不是自己动手建。如果你正在建造一个软件，你也会这
样做。你会推广使用高级语言的特点，而不是去编写操作系统一级的代码。你也会利用已经存
在的显示控制和数据库处理系统，利用已经通过的子程序。如果样样都自己动手是很不明智的。
如果你想修建一幢陈设一流的别墅，情况就不同了，你可能定做全套家具，因为希望洗碗
机、冰箱等与你的家具协调一致，同时你还会定做别具风格的门和窗户。这种定制化的方式与
一流软件开发也是非常类似的。为了这一目的，你可能创建精度更高、速度更快的科学公式。
你也会设计自己的显示控制、数据库处理系统和自己的子程序，以使整个软件给人以一气呵成，
天衣无缝的感觉。
当然这两种建造方法也要付出代价，工作的每一步都要依据事先制定好的计划进行。如果
软件开发工作的顺序有误，那么这个软件将是难以编码、难以测试和难以调试的。这可能会使
整个计划延误甚至失败，因为每个人从事的工作都非常复杂，把它们综合到一起后会使人无所
适从。
如果你在盖办公楼时工作做得不好，那么在楼内办公的人便可能面临危险。同样，如果你
在创建医药、航空电子、空中交通管制、加工控制等软件时工作做得不好，后果也可能是灾难
性的。危及别人生命是劣质软件的最可怕后果，但并不是它的唯一危害。如果公司的股东们因
为你编写了错误软件而赔钱，那也是令人遗憾的。无论如何，无辜的人们没有义务为你的工作
失误而付出代价。
对于软件作修改与建造建筑物也有类似之处。如果你要移走的那面墙壁还要支撑其它东西
而不仅仅是隔开两个房间，那么你要付出的成本将会更高。同样，对软件做结构性的修改也将
比增加或减少外设特征付出更高昂的代价。
最后，建筑类比对于超大型软件也是同样适用的。一幢超大型建筑物存在错误的后果将是
灾难性的，整个工程可能不得不返工。建筑师们在制定和审查计划时是非常仔细的，他们往往
留出安全裕度，多用 10％的材料来加强结构总比一幢大楼坍塌要好得多，同时还必须仔细注意
工时计划，在修建帝国大厦时，每辆卡车的每次卸货时间都留出了十五分钟的裕度。因为如果
有一辆卡车不能在指定时间到达指定的位置，整个计划就有可能被延误。
同样，对于超大型软件来说，计划工作需要比一般的大型软件在更高的层次上进行。1977
年，Capers Jones 估计说，对于一个拥有 750，000 行代码的系统来说，可能需要多达 600 页的
功能定义文件。对于一个人来说，不要说理解这种规模全部的设计，就是读完它也是非常困难
的。安全系数对于这种项目是必须的，制定该系统的工时计划尤为重要。当我们在建造与帝国
大厦同等经济规模的软件时，我们也需要同等严密的计划。而我们现在才刚刚开始考虑这种规
模项目的计划技术。
这两者之间的相似还可以推广到其它方面，这就是为什么建筑物创建隐喻是如此强有力的
原因。许多常用的软件词汇来源于建筑学，如：软件体系结构、搭结构架、构造、分割代码、
插入子程序等等。

在过去的十几年中，优秀的软件开发人员们积累了几十条关于开发软件的技术和技巧，有

些像咒语般灵验，这些技术不是规则，它们是分析工具。一个优秀的工匠知道用什么样的工
具干哪一样工作，而且知道该如何使用它们。程序员也是如此，关于编程你理解得越深入，
你的工具箱里的工具也就越多，何时何地该如何运用它们的知识也就越多。
把方法和技巧当作工具是很有益处的，因为这样可以使我们对其有一个正确的态度。不
要把最新的“面向对象设计技术”当作上帝赐予的法宝，它不过是一件在某些场合下有用，
而在某些场合下又无用的技术。如果你拥有的唯一工具就是一把锤子，那么你就会把整个世
界都当作一个钉子。好在没有人会花 500 美元一天的费用来雇佣一个仅告诉你去买一把可以
解决一切问题的锤子的研究小组，也没有人建议你丢掉你的改锥、手钻和电烙铁。
在软件开发中，常常会有人告诉你用一种方法来代替另外一种方法。这实在不幸，如果
你仅仅采用一种方法，那你就会把整个世界都当成那个工具的作用对象。你会失去用更适合
的方法解决问题的机会。工具箱隐喻有助于我们保留一切方法、技巧、技术等，并在适当的
时候使用它们。