腾讯亿级用户规模自研业务的上云实践解读,立即报名 了解详情
写点什么

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

  • 2020-02-12
  • 本文字数:2047 字

    阅读完需:约 7 分钟

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

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


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

应用开发的“集成环境”(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 项目要素之间的平衡三角



图 2 管理平衡三角


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



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


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


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



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


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


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


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

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


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


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


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


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


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


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


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


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



相关阅读


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


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


2020-02-12 14:001626

评论

发布
暂无评论
发现更多内容

食堂就餐卡系统架构设计

~就这样~

就餐卡系统架构设计

祝好

架构师训练营第01周——UML练习

李伟

极客大学架构师训练营

架构师训练营-学习总结

~就这样~

关于架构师这个角色的感悟

祝好

第一节课的总结

王锟

实例学习绘画UML图

张瑞浩

Lesson 1 架构师如何做架构 心得笔记

edd

编程好习惯 极客大学架构师训练营 架构总结

架构方法学习小结

梅子黄时雨

极客大学架构师训练营

架构师训练营第0期-第1周-作业一

极客大学架构师训练营

什么叫架构师

平淡人生

极客大学架构师训练营

架构师训练营 Week 01 学习总结

Kun

极客大学架构师训练营

食堂就餐卡系统设计

八两

架构师训练营-食堂就餐卡系统设计

彭灵俊

极客大学架构师训练营

架构文档编写

清风明月

就餐卡系统(时间太紧张,阅读了很多,我转载的这篇)

王锟

作业2-学习心得

蒜泥精英

什么是架构师?

呆呆栋

第一课 架构师的自我修养

Geek_bobo

架构师训练营第0期-第1周-作业二

极客大学架构师训练营

就餐卡设计文档

chengjing

食堂就餐卡系统设计(第一周)

聊聊架构师

Jerry Tse

随笔杂谈 极客大学架构师训练营 作业

作业一:食堂就餐卡系统设计

独孤魂

极客大学架构师训练营

食堂就餐卡系统架构视图

梅子黄时雨

极客大学架构师训练营

【第一周】学习总结——架构方法、软件建模与设计文档

三尾鱼

极客大学架构师训练营

就餐卡系统设计

平淡人生

极客大学架构师训练营

第一次课作业

lai

作业1:食堂就餐卡系统设计(UML)

蒜泥精英

编译运行Zookeeper源码

CoderLi

Java zookeeper 程序员 源码分析 后端

食堂就餐卡系统设计

Acker飏

极客大学架构师训练营

程序原本(三):开发视角下的工程问题_文化 & 方法_周爱民_InfoQ精选文章