程序原本(七十三):应用开发基础——开发视角下的工程问题(原型是轻量级的试错,它并没有减少问题的总量,但改变了达到解的方式)

阅读数:25 2019 年 10 月 3 日 14:36

程序原本(七十三):应用开发基础——开发视角下的工程问题(原型是轻量级的试错,它并没有减少问题的总量,但改变了达到解的方式)

但问题是:为什么不能将“原型”也理解为“模型”?为什么非得将画在图纸上、用几何线条描绘的东西才视为模型,并将这些东西的抽象与绘制过程才称为建模呢?建模的目的是得到一个“可讨论对象”,而(多数情况下)原型就是——在敏捷工程所设定的场景中——可以被多方认可并予以讨论的对象。一旦我们承认这一点,那么再讨论“是做原型还是画图纸”的问题就没什么价值了。

从实施推进的角度来看,模型事实上允许我们将系统拆分成多个阶段,并尽早地预期了系统的每个阶段所依赖的(前一个阶段的、可能的)事实基础,因此模型具有可描述、可分析、可预期等性质1。而敏捷工程本质上是把决策域与产品域中的需求拉到了实施域中,就地决策与设计(产品),并将这一过程开放给用户,如图 39 所示。

1 正因为如此,在“第 12 章 应用开发技术”一开始就讲到:它适于解决时间因素所致的复杂性。

图 39 敏捷工程并不能消灭上述需求

程序原本(七十三):应用开发基础——开发视角下的工程问题(原型是轻量级的试错,它并没有减少问题的总量,但改变了达到解的方式)

问题的总量并没有减少,但是这里的“可讨论对象”(即原型),变成了纯粹用于工程师与用户之间沟通的桥梁。这符合一些应用开发工程的现实场景,例如用户通常更关心产品特性是否能够得到满足,他们多数时候并不关注市场、产品或实施阶段等问题。因此敏捷(以及类似基于原型、快速迭代的)工程模型有着很强的实用性。

然而原型不能解决一切问题。在一定程度上来说,原型是轻量级的试错,而抽象模型则可以通过严密的论证与分析过程来得到决策依据。因此,原型与模型的适用领域也有所不同。原型适合于在参与者之间建立简单的、直观的、允许快速纠错的讨论对象,更适用于快速推进以及短周期、逼近式的产品开发。而模型则适合于抽象出系统中方向性、支撑性、不易频繁变化的关键环节,在此基础上进行论证,以尽可能减少出错或预期风险,甚至更进一步地提供中长期的系统演进规划(例如产品版本、产品线等)。

评论

发布