软件的“一生”，读《软件开发本质论》

前言

这个专栏的初衷是自下而上的学习与记录.net core软件开发中需要掌握的知识技能，但慢慢发现知识点真的非常非常多，以一己之力无法很快的勾勒出.net core开发的全貌。所以本篇文章从整个软件开发过程的视角来鸟瞰软件开发， 借着最近读了《软件开发本质论》的热度，继续学习软件开发的过程与其中挑战。

软件，“软件危机”及软件工程

1983年IEEE为软件下的定义是：计算机程序、方法、规则、相关的文档资料以及在计算机上运行程序时候所必须的数据。所以软件不仅仅是程序，而是程序与一系列文档、资料、数据的集合。

“软件工程”一词则是1968年由北大西洋公约组织（NATO）的计算机科学家在联邦德国召开的国际会议上首次提出来的。产生软件工程这门学科的时代背景是“软件危机”，软件工程的发展和应用不仅缓和了“软件危机”，并且促使了一门新兴的工程学科的诞生。软件工程的定义：和所有的工程学科一样，应用计算机科学、工程学、管理学以及数学的原则和方法来创建软件的学科。

软件工程的发展可以分三个时代：

1，程序设计时代（1946年至1956年），这个时代的特点是由于硬件的限制，程序的开发非常强调程序员的技巧，需要充分的节约CPU时间和内存，这导致了程序非常难读，难懂，难修改。

2，程序系统时代（1956年至1968年），这个时代的特征是“软件作坊”的出现。由于集成电路的变革，硬件性能有了一定的提高，以及软件规模的扩大导致单个人员无法开发，“软件作坊”也就应运而生了。在程序设计上，这个时代基本沿用上个时代的开发方法，但开始提出了结构化的方法来开发软件。不过此时的软件可修改性仍然很差，无法适应多变的用户需求与使用环境，所谓的“软件危机”便产生了。

“软件危机”的含义可以用一个案例来描述，IBM的OS/360的开发花费了5000人年以及数千万美金仍然没有达到预期，OS/360项目的负责人Boorks(《人月神话》作者)生动的描述了研制过程中的困难与混乱：“......像巨兽陷入泥潭垂死挣扎，挣扎的越猛，泥浆就沾的越多，最后没有一个野兽能逃脱淹没在泥潭的命运.....程序设计就像这样的泥潭，一批批程序员在泥潭中挣扎.....没有料到问题会这样棘手.....”。

3，软件工程时代（1968年至今），这个时代的背景就是高性能低成本的硬件大量出现，但硬件只提供了潜在的计算能力，大型软件项目仍然需要十分复杂的软件才能实现。在这个时代，软件的维护费用，软件价格不断上升，仍然没有完全摆脱软件危机。

个人觉得“软件危机”是相比传统工程时出现的，如基建工程，一座大桥的复杂程度我们可以有非常直观的感受，但对于软件的复杂性我们无法有同样直观的感受，所以在我们获得能直观感受复杂度的“能力”之前“软件危机”会因为软件的特殊性而必然存在（当然软件的特殊性不只复杂性这一点），所以个人更喜欢把上文中所述的“软件危机”看作是“软件挑战”。

软件工程的诞生让我们开始审视软件开发过程的各个阶段并运用工程的方法来高效的“生产”软件。软件的各个阶段即软件的生命周期，即软件的“一生”。

软件的生命周期

软件开发生命周期也可以称为软件开发过程，它指代一个软件开发的整个过程以及其中全部的活动和任务。随着软件行业的发展我们提出了不同软件开发过程，软件工程将这些不同的软件开发过程称为软件开发模型（软件开发模型指软件开发全部过程、活动和任务的结构框架），可以说不同的软件开发模型是对软件开发生命周期的经验总结和探索，这些不同的软件开发模型针对不同的软件开发中的挑战来保证开发的效率与质量。下面介绍三个经典的模型。

1、瀑布模型，这个模型的特点就是软件的开发被清晰的按照顺序分为计划，需求分析，设计，编码，测试等各个阶段，每个阶段的工作都依赖上一个阶段的完成，并且阶段之间使用文档来进行联系。这样的模型适用于需求非常明确的软件项目。

2、快速原型模型，快速原型模型与上面的瀑布模型相比主要的变化在需求阶段，快速原型模型的特点是先使用辅助软件快速的开发一个用户可以“使用”的软件原型，并根据用户的反馈支持的改进原型，在原型确定后开始设计开发。这个开发模型特别适用于由用户界面驱动开发的软件项目。

3、螺旋模型，上面介绍的瀑布模型最大的问题就是如果需求没有明确并且要在后期存在修改的情况，那么软件开发就有巨大的风险，螺旋模型的出现就是为了降低这样的风险。

螺旋模型结合了快速原型模型以及增量模型的特点，首先它是一个迭代模型，然后在每次的迭代过程中加入原型与风险分析的活动来降低风险。螺旋模型适用于大规模高风险的软件项目。

虽然不同的开发模型之间有着各种各样的差别，但是像需求分析，设计，编码实现，测试这些软件开发最基本的活动，所有模型都是具备的。不同模型的区别主要是如何安排这些活动并根据软件开发中的挑战相应的调整这些活动或添加特定的活动，如风险分析，原型制作等等。

所有这些方法论都是对各种各样软件开发实践的总结、分类与尝试，它们都有各自不同的适用场景。那么如何在实际的开发过程中选择或者“定制”自己的开发模型呢？

《软件开发本质论》

本书全称《软件开发本质论：追求简约、体现价值、逐步构建》，作者Ron Jeffries是极限编程的创始人之一，同时也是敏捷宣言的签名人之一。本书发布于2015年，英文全名为:《The Nature of Software Development: Keep It Simple, Make It Valuable, Build It Piece by Piece.》，题目不仅很好概括了书本内容，也表达作者的主要观点。作者的其他著作包括:2000年的《Extreme Programming Installed》以及2014年的《Extreme Programming Adventures in C#》。

《软件开发本质论》开门见山的打了个比喻：软件开发就像是穿越一片岩浆，但在这片岩浆中存在一条“自然之路”，我们的目标就是找到这条路并尽量行走在上面，而不是陷入岩浆之中。那么如何做到这一点呢？下面就是书中主要阐述的几个方面。

价值，软件开发的目的是追求软件的价值，这里的价值通俗的说就是“我们想要的东西”，对于软件来说功能特性就是我们想要的东西，也就是软件价值的体现。软件开发的过程就是让软件价值最大化的过程，所以在开发过程中首要的任务就是找出那些能让价值最大化的功能特性，这些功能特性应该是我们在开发过程中优先去实现的。需要说明的是只有交付的功能特性才是有价值的，而不是那些没有经过测试仅仅是编码完成的功能特性。

团队，团队应该根据功能特性来组织，对于项目中的每个小团队首先确保都有一个能够理解功能特性的产品推动人（Product Champion），并且都拥有构建目标功能特性所需的所有人员与技能，这两点既是对团队的要求也是团队的组织原则。这样的组织体现了责任与权力的一致，并且减少了跨团队的交流。

计划，艾森豪威尔将军曾说过：“计划本身是无用的，但是做计划是必要的”。 计划的制定仍然以功能特性为基础，尽早确定哪些核心功能特性必须尽快有，哪些功能特性不能没有。对于价值很小的想法，我们需要无限期的延迟实现。制定计划的过程中还要避免过度计划，因为详细的计划是无用的，因为实际的控制比准确的预测更加重要。

除了功能特性，计划另外一个要考虑的重要因素就是预算，下面的方法可以尽量避免开发过程中预算失控：一是确定项目的时间期限和开支预算；二是优先开发那些最有价值的功能特性；三是确保产品能够随时发布，并在时间结束时立即停止。

另外还要注意，根据“挑战性的目标”制定计划，危害性很大，赶工将会给整个项目带来更多的缺陷。与防止缺陷发生相比，修复缺陷需要花费更长的时间。糟糕的代码同样也会影响进度，压力具有破坏性，尽量避免向团队试压。

节奏， 团队应该以固定的节奏工作，这样的工作周期通常被称为迭代（iteration）或冲刺（sprint），其长度一般为几周。迭代可以让我们在每个开发阶段都能明确的了解我们要完成的功能特性，并且可以良好的控制进度。所以迭代应该以明确细化的需求开始，并以实现可验证、可运行的功能特性作为迭代的完成。这样每次迭代都能让我们头脑中最终产品的样子越来越清晰。对于迭代的进度，我们不能接受诸如“完成了90%”这样的表述。功能特性要么“已完成”，要么“未完成”，不存在中间地带。

上述这些原则或者说方法是书中的主要观点，关于它们的说明与论述以及其他细节，因为篇幅就不在这里展开了，有兴趣的朋友可以自行深入阅读。

读后感

这本书用非常通俗的语言，由浅入深的为大家介绍了软件开发中的基本原则，并对具体原则的实践方法做了说明。作者介绍的这套方法也就是敏捷方法，我个人认为它非常针对性的处理了我们软件开发过程中的主要挑战：需求改变的风险，以及难以详细计划得进度。以造一座大桥做比较：造桥项目的需求在设计确定后是非常明确的，而且设计方案几乎是所见即所得，并且设计图纸的细节可以精确到每个铆钉的位置，这些都是软件项目目前无法做到的。

但是书中的实践是否是万能的呢？在收集资料的过程中看到这么一篇文章，

虽然我无法确定文化是否能如此大的影响软件开发模型的实践，但我相信不同的团队在软件开发的过程中应该根据自己的团队文化做适合自己的调整，不然就变成教条主义了。

希望各位工程师都能在软件开发过程中找到最适合的开发模型。欢迎在评论中发表意见和观点来一起讨论，在软件工程的道路上与大家共勉。

最后祝大家2019新春快乐！

参考资料：《软件工程》，维基百科，《软件开发本质论》