过去几十年的大型系统开发就犹如这样一个焦油坑,很多大型和强壮的动物在其中剧烈地挣扎。他们中大多数开发出了可运行的系统——不过只有极少数的项目满足了目标、进度和预算的要求。
各种团队,大型的或小型的,庞杂的或精干的,一个接一个地淹没在了焦油坑中。表面上看起来好像没有任何一个单独的问题会导致困难,每个问题都能获得解决,但是当它们相互纠缠和累积在一起的时候,团队的行动就会变得越来越慢。
图1-1的左上部分是程序( Program)。它本身是完整的,可以由作者在所开发的系统平台上运行。它通常是车库中产出的产品,以及作为单个程序员生产率的评估标准。
有两种途径可以使程序转变成更有用但是成本更高的产物,这两种途径表现为图中的边界。
水平边界以下,程序转变成编程产品( Programming Product)。这是可以被任何人运行、测试、修复和扩展的程序。
它可以在多种操作系统平台上运行,供多套数据使用。
要成为通用的编程产品,程序必须按照普遍认可的风格来编写,特别是输入的范围和形式必须广泛地适用于所有可以合理使用的基本算法。
接着,对程序进行彻底测试,确保它的稳定性和可靠性,使其值得信赖。这就意味着必须准备、运行和记录详尽的测试用例库,用来检查输入的边界和范围。此外,要将程序提升为程序产品,还需要有完备的文档,每个人都可以加以使用、修复和扩展。
经验数据表明,相同功能的编程产品的成本,至少是已调试的程序的成本的3倍。
回到图中,垂直边界的右边,程序转变成编程系统( Programming System)中的一个构件单元。它是在功能上能相互协作、具有规范的格式、可以进行交互的程序集合,并可以用来组装和搭建整个系统。要成为编程系统构件,程序必须按照一定的要求编制,使输入和输出在语法和语义上与精确定义的接口一致。同时程序还要符合预先定义的资源限制——内存空间、输入输出设备、计算机时间。
最后,程序必须同其他系统构件单元一道,以任何能想象到的组合进行测试。由于测试用例会随着组合不断增加,所以测试的范围必须广泛。因为一些意想不到的交互会产生许多不易察觉的bug,测试工作将会非常耗时,因此相同功能的编程系统构件的成本至少是独立程序的3倍。如果系统有大量的组成单,成本还会更高
图1-1的右下部分代表编程系统产品( Programming Systems Product)与以上的所有的简单的程序都不同的是,它的成本高达9倍。然而,只有它才是真正有用的产品,是大多数系统开发的目标。
职业的苦恼
首先,苦恼来自追求完美。
其次,苦恼来自由他人来设定目标、供给资源和提供信息。编程人员很少能控制工作环境和工作目标。用管理的术语来说,个人的权威和他所承担的责任是不相配的。不过,似乎在所有的领域中,对要完成的工作,很少能提供与责任相一致的正式权威。而现实情况中,实际(相对于形式)的权威来自于每次任务的完成。
对于系统编程人员而言,对其他人的依赖是一件非常痛苦的事情。
他依靠其他人的程序,而这些程序往往设计得并不合理、实现拙劣、发布不完整(没有源代码或测试用例)或者文档记录得很糟。所以,系统编程人员不得不花费时间去研究和修改,而它们在理想情况下本应该是可靠的、完整的。
下一个苦恼—概念性设计是有趣的,但寻找琐碎的bug却是一项重复性的活动。伴随着创造性活动的,往往是枯燥沉闷的时间和艰苦的劳动。程序编制工作也不例外。
另外,人们发现调试和查错往往是线性收敛的,或者更糟糕的是,具有二次方的复杂度。结果,测试一拖再拖,寻找最后一个错误比第一个错误将花费更多的时间。
最后一个苦恼,有时也是一种无奈—当投入了大量辛苦的劳动,产品在即将完成或者终于完成的时候,却已显得陈旧过时。可能是同事和竞争对手已在追逐新的、更好的构思;也许替代方案不仅仅是在构思,而且己经在安排了。