Categories
程式開發

程序原本(三):开发视角下的工程问题


编者按:本文节选自周爱民著《程序原本》一书中的部分章节。

集成化工具需要有配套的生产过程和管理

应用开发的“集成环境”(IDE,例如Eclipse IDE)不是给一个人用的,开发工具公司的“套件”(Suite,例如VSTS,Visual Studio Team Suite)是为多种角色提供的。但这两点事实,大多数时候为工程人员所忽视。集成环境或套件都是基于工业生产的理念来提供的,这一理念认为:工业生产整体依赖于分工明确的产品过程。因此,开发人员需要代码文本的编辑环境,测试人员需要自动化测试与脚本驱动的工具,构建人员需要包、构件以及面向资源的管理界面,如此等等。

将这一切组织在一起的Suite或IDE,就如同工业生产线上的硬件环境。正如这个比喻所暗示的:在购买这个生产线的同时,也就意味着你需要这个生产线的过程模型与管理体系。大多数时候,我们的应用软件产品开发并不是工具用得不好,而是生产组织与管理得不好。而这其中,“模型”的指导意义尤其被忽略。

MSF(Microsoft Solution Framework)描述了“VSTS生产线”背后的工程模型,其核心并非来自于技术实施,而是来自对管理 “项目/产品过程”所需要进行的权衡(图1)1,这与“项目平衡三角(项目管理三要素)”所阐述的问题是一致的(图2):

1 引自“MSF Process Model v. 3.1”, Microsoft Solutions Framework White Paper。

程序原本(三):开发视角下的工程问题 1

图1 项目要素之间的平衡三角

程序原本(三):开发视角下的工程问题 2

图2 管理平衡三角

于是进一步地,MSF提出了三种模型来解决对应的问题,如图3所示。

程序原本(三):开发视角下的工程问题 3

图3 MSF的三种模型与项目要素之间的关系

其中组队模型讨论项目创建时的团队、资源、沟通模式,过程模型讨论开发过程的控制与管理方法,应用模型则讨论产品定义、产品实现以及产品特性的管理。当这些模型映射到Suite或IDE中时,相关的要素就变成了类似如表9所示的关系2

2 这种对应关系并非是边界分明的,事实上IDE中的同一个功能可能应对的是不同模型中的问题或问题集。

程序原本(三):开发视角下的工程问题 4

表1 模型要素在理论框架与集成环境中的关系

这一类工具在“一致性”上的要求与“统一建模”、“统一过程”等思想同出一源。更确切地说,它们是“方法 + 过程 + 工具”这一传统工程模型的具体实践,即方法论决定了过程模型,工具是对方法论与过程模型的实现及其具体实施手段。

但问题在于:是要懂得使用工具,还是要懂得方法与过程?

敏捷工程实践者其实代表了工具精良派的产业工人的声音

集成环境或套件试图通过统一模型来建立整个团队对话、沟通、工作的一致化的界面,但这一过程其实并非依赖或只依赖特定的工具。

敏捷工程敌视那些强行植入开发工具的决策需求、管理需求以及产品需求3,进而否定“管理者、决策者以及产品相关角色”等在这一环境中的价值,并从“形式上”将这些角色推出团队,同时把产品定义与产品品质这些职责直接交给开发人员与用户。但是从根本上来说,它未能否定“过程模型”的价值。因此,大多数敏捷团队在弱化了管理与产品相关职责之后,仍无法摆脱软件工程过程(例如瀑布模型,以及基于瀑布模型的迭代)的约束4,只是他们有空间、有能力去选择更轻量、适用的工具来应付那些决策、管理与产品的需求。

3 导致这一局面的部分的、且并非关键的原因在于:一方面,开发工具中使用Project、ProjectGroup等关键字来应对项目规模的扩大,而这一问题延伸到工程模型后所得到的抽象概念却是Product、Version以及ProductLine等;另一方面,工程工具与开发工具的提供商试图将这些合而为一,但形式上的统一未能弥补概念与领域上差异。

4 这进一步导致了团队无法摆脱既有的公司组织与管理结构,于是实施敏捷变得在组织层面上既说不通也行不通。

除开这些因素,“敏捷”事实上是在探索用户与工程师进行有效沟通的最简方式。这种方式并不是说不要“模型”,敏捷工程师(也包括“不敏捷”的工程师)其实也试图为用户所描述的业务数据与业务过程进行建模5。一部分建模工作是这些工程师“乐于”去做的,通常它们是面向业务的“数据与过程”的。因为这跟编程世界中的“数据结构与算法”有着近乎天然的映射关系6,只是他们将这些工作换了一门“手艺”来做罢了。例如在UML中,逻辑视图与实现视图构建的就是这两类模型。而他们“不喜欢”做另一些建模工作(例如完整的业务建模与产品建模),只是因为这些内容与开发工作没法关联起来,因而在他们的工作中是不需要的。

5 例如,正如此前所讨论的,敏捷中的原型事实上也是敏捷工程师与用户之间沟通的模型。

6 你可以想象成开发过程中的“定义数据结构和写函数声明”,以及形式化的流程图与部分逻辑代码。

将VSTS等单纯视为“开发工具”是一个根本性的错误。既然这是生产线,那么正确的做法应是明确工程师在生产线上的角色,并将适当的工作交付给他们。但现实是,源于那些错误的认识,一些团队过度地要求工程师在生产线中的职责,反而激化了他们对相应职责的抵制。而敏捷工程与敏捷开发方法,不过是在这样的抵制运动中所诞生的“看起来有点革命性的”产物。

图书简介https://www.ituring.com.cn/book/2429

程序原本(三):开发视角下的工程问题 5

相关阅读

程序原本(一):应用开发基础

程序原本(二):应用开发技术