写在前面
《代码大全》是一本编程界的传奇书籍，豆瓣评分高达9.3分：
于是近期就打开了这本书。九百页的大书，慢慢啃吧。
用隐喻来更充分地理解软件开发
为什么隐喻如此重要？
重要的研发成果通常产自类比，通过把不理解的东西和一些较为理解或类似的东西做比较，就可以对这些不太理解的东西产生更加深刻的理解，即"建模"。在科学的历史中，我们可以看到很多由类比产生的发现，如气体的分子运动理论，光的波动领域等等。总的来说从启发能力来看，这种模型有两种，他们的启发能力差别十分之大。从这方面来说会得到完全不同的结果。
人们对于隐喻的力量会产生轻视。科学发展的历史并不是从“错误”的隐喻到“正确”的隐喻的转变，而是从一系列“不太合适”的隐喻到“更好”的转变。事实上，那些被更好的新模型所替代的旧模型依然十分有用，如牛顿力学和爱因斯坦的理论。相对于其他学科而言，软件开发是一门非常年轻的学科，你对隐喻的理解便代表了你对软件开发有多理解。
如何使用软件隐喻？
软件隐喻，比起算法，更像是启示。算法是一套定义明确的指令，他会告诉你为了从A做到B需要做的每一个步骤。启示则不同，他可能不会告诉你怎么从A到B，甚至不会告诉你A和B点在哪。并且答案也会具有很大的偶然性。
算法与启示（启发式方法）之间有着十分微妙的差别，两个术语的意义会有一定的重叠。那么该如何使用软件中的隐喻呢？应该用它来提高自己对编程问题和编程过程的洞察力，用它帮助你思考编程过程中的活动。对于那些使用隐喻来照亮自己的软件开发过程的人，对编程的理解会更加深刻，能够更快的写出更好的代码。
常见的软件隐喻
-
软件中的书法：写作代码
软件开发的最原始的隐喻是从“写作（
writing）代码”这个说法发展来的。对于个人规模的工作乃至小型项目而言，这种隐喻已经足够了。但对于更加复杂的项目而言，这样的隐喻还远远不够——对于软件开发的刻画不够完整。书写通常是个人的活动，而一个软件项目通常会涉及到多个承担不同职责的人。在你写完一封信并发出去之后，他就无法更改了。软件开发不同，大部分软件开发在发布后才刚刚是开始而已。于是，就出现了其他的隐喻。 -
软件的耕作法：培植系统
相对于之前那个呆板的用写作所做的隐喻，一些开发人员认为应当把创作软件想象成类似播种和耕作的情形。你通过不断的小步前进，如一次设计系统的一小部分，写出一段代码，可以把每次可能遇到的麻烦减到最小。但把软件开发类比成耕作是非常不贴切且无意义的，人们很难把耕作这个事引申到“一次做一点事”之外。这个隐喻的最大弱点在于它暗示了人们将无法对软件开发的过程和方式做任何直接的控制，而这显然是错误的。
-
软件的牡蛎养殖观点：系统生长：
当提到生长这个词的时候，我们也都能理解它指的是通过外在的增加或吸收而逐渐地生长或变大。与“生长”密切相关的另一些词语有：增量的，迭代的，自适应的，说明白点就是增量式开发模型，而这种开发模型是目前已知最强力的软件开发概念。作为一个隐喻而言，增量式开发的优势在于未做过度的承诺。比起耕作这个隐喻，这个隐喻更好的表达了软件开发的过程。
-
软件构建：建造软件
比起上述的几个隐喻，这个隐喻就要更加贴切了。它和软件生长的概念是相通的，且提供了更详细的指引。建造这种说法暗示了软件开发中存在着诸多阶段，如计划、准备和执行等。进一步研究这个隐喻，会发现还有很多与软件开发的相似之处。如果你只是为你家的狗狗造一个窝，那么就算忘造了一个门，或者少了一个设计，完全可以推倒重来。如果类比到我们的软件开发过程，比如一个一千多行代码的程序，如果你写着写着发现不好，那么完全可以推倒重来，成本完全是可以接受的。但如果是建造一个房子呢？我们整个过程就会变得十分复杂了。首先我们要决定建什么样的房子——在软件开发中这种被叫做问题定义。接下来我们需要跟某个建筑师探讨这一总体设计，也就是软件架构设计。之后画出具体的蓝图，即详细设计。之后便开始建房子了，这就类似于软件的构建过程。在建好之后会进行装修，也就是软件优化。在整个建造过程中会有人不断的监工，类似于软件复查和审查。
在这两种活动中，更高的复杂度和更大的规模都会带来更多的结论。比如如果你在盖房子的过程中发现出现了一些问题，你是不可能随意推倒重来的。所以你只能在最开始的时候尽可能的把房子设计好，即把软件设计好。从这个方面来说，这个隐喻可以向许多其他的方向引申，这也使得这个隐喻如此的强力。
-
组合各个隐喻
因为隐喻是一种启发式方法，而不是算法。因此他们彼此并不相互排斥。你可以同时使用两个或多个隐喻来理解。只要它能激发你的思维灵感，并让你和团队其他成员更好地沟通。使用隐喻是一件说不清的事，用我自己的话来说就是得自己悟，是一个有些玄学的东西。
总结
总的来说，这一篇章主要讲了软件隐喻的重要性，如何使用和常见的软件隐喻。通过这些隐喻可以帮助我们更好的理解软件开发的过程。