《代码大全》第二章：通过隐喻更充分的理解软件开发

现在来到第二章。

这一章依旧讲的是软件开发的过程，首先就抛出“用隐喻来描述软件开发的过程”的思想，也就是说，并非详细的去指出软件开发是什么，而是用认知中已有的事物来描述软件开发像什么这么一个思想。用这个想法，除了能更好的理解软件开发中的问题之外，我认为还有对于自己能力的认知。如果一个程序员对于软件开发的过程讲不清楚或是单纯认为只是代码搬砖，那显然还需要学习。

在计算机专业里通常会有《软件工程》的必修课，甚至还有软件工程这个专业。但实际上，软件、网络甚至计算机到现在还算年轻，如今的软件工程对于项目的管理经验有不少是照搬自其它理工类项目。但软件跟这些项目又有一些差别导致经验无法通用，这件事在上世纪的《人月神话》中就有指出，软件的开发并不会出现“一个人干十天的活，十个人就只需要干一天的活”，人数的增多也会带来沟通、项目协调等等问题。

这种情况实际就是所谓的“隐喻与实际的偏差”，软件开发只是与理工类项目类似，一味的套用经验是不行的。不过按目前来看，《人月神话》没有过时，软件工程在未来依旧还是会与实际存在不少偏差。

这就是为什么隐喻比较重要了。

然后作者就讲了讲主流的软件开发隐喻，然后一一指出了其优缺点。

首先是“软件开发就是编写代码，编写代码就像是软件开发的书法”这一想法，写作或者写信（《人月神话》里提出的隐喻就是写信）就是软件开发的全部，或者说大部分。像我刚接触软件开发的时候就是这样的想法，认为软件开发最重要的无疑是代码。

作者的意见是，对于小型项目或者个人项目还算说的过去，但是对于其它场景，这个隐喻就不够恰当，不够完整，不够充分。这点其实写过一些稍微复杂一点项目的人应该都能理解，像当初写毕设的时候，最耗时的还是需求分析拆解、UI设计、数据库数据表设计这些（因为是毕业设计所以不用过多考虑发布等生产问题），而代码呢？不少代码直接用代码生成器，也就当时还没有生成式AI，不然会有更多的代码让机器来写。这个隐喻在情况稍微复杂一点的时候就会出现非常大的偏差，比如说现在这样的情况，如果代码真的占据大多数内容的话，那恐怕以后就不需要程序了。

然后就是“代码如同农耕：培育系统”，认为软件开发跟种地一样，有种子，有投入，不断的播种收获播种，最终就可以达成交付。这个隐喻的不恰当之处挺多的，除开作者提到的“播种收获的过程有很大一部分要看天，但软件开发所有东西都掌握在开发人员手上”之外，软件项目的开发模式也有很多，并不是所有的模式都契合这种一步一步来一个功能一个功能去迭代的情况。

接着一个隐喻是“软件如牡蛎养殖：系统生长”，认为软件的开发就是在确立骨架之后一步步迭代增量。这个隐喻作者认为比农耕好一些，也找不出什么反例，只是认为实际开发里不会做出过度承诺，总体来说还是符合增量开发的。基本上这个模型也跟现在大部分公司的软件管理差不多，从结果上来看确实几乎没什么偏离。

然后是篇幅比较多的，作者比较推荐的隐喻：构建。这部分就用修房子作为隐喻，图纸（设计）、建造（代码）、装修（优化）、检查（评审）、买家电（用别人写好的工具）、定制家电（自己写定制的工具）。实际上，这种隐喻也是现在软件行业中不少名词的来源，比如脚手架、架构、基础等等。越是大型的项目，关联的文档就越多，与建筑构建的隐喻就越接近。

不过我觉得虽然这个隐喻描述的过程较为准确，但如果把整个软件工程的寿命（三到五年）与房屋的寿命（七十年）比较的话，还是会有一些偏差。同理，技术的迭代这些要素也要考虑进来的话，修房子这个隐喻依旧不太恰当。

最后简单提了一个“应用软件技术：智慧工具箱”的隐喻。这个隐喻本身就是对于“代码复用”之类场景的概括，也只概括这部分，所以还是比较恰当的。

然后在本章末尾，作者也提到，人们看待软件开发实际上可以用不止一种隐喻去理解，与之相对的，也不要过于强调隐喻，反而用隐喻去改变软件开发，这就本末倒置了。

总之，这章相比第一章的引言，更多的是通过一些举例与反驳来描述作者认为的代码开发工程的样子，如果有学过《软件工程》或者实际工作经验的朋友应该也有自己的想法。我个人以前接触过一份非常完善的游戏企划书，里边从游戏的封面、背景故事再到玩法设计、系统循环、UI设计、模拟效果都应有尽有，程序员拿着这玩意只需要照着把功能实现出来就可以完事。这份企划书给了我不小的震撼，也是第一次让我思考起“代码只是实现需求的工具”这句话到底有什么含义。因此对于软件开发，我心里的隐喻就像这份企划书一样：能做什么、要做成什么样、有什么要求，然后用代码去完成这些。