[答疑]软件方法学这30年没有进步吗

软件方法(下)分析和设计第8章连载[20210518更新]>>


九云 2021-5-19 20:22

常见的几种编程模式:函数式、面向对象、面向过程

然后映射到软件方法的话(我不知道,软件方法具体应该怎么划分,百度搜了下,说有8种方法来着,很多都没见过了)

函数式,只听说编程范式,没有分析和设计方法

面向过程,我理解对应了:结构化分析设计

面向对象,就对应了:面向对象分析设计,比较流行的工具是UML

看面向对象的历史,60-70年代好像就提出了编程范式,90年代分析设计思想好像就成熟了

我有个问题,90年代到现在,30年过去了,技术改变了很多,进化了很多代(编程语言、平台、框架等等,一直在变化)

难道软件方法这30年没有进步吗?我们是不是还停留在90年代?

UMLChina潘加宇

前面的业务建模、需求、分析进步不大,当然也是有的,例如《软件方法》就是进步嘛。但从大众普及面上来说,是倒退的(如果说方法水平是铁器时代,大众平均估计是石器时代甚至还要落后)。原因刚发布的第8章里面有描述。

按照一致的标准来看,编程语言也没啥进步,函数式编程语言60年代就有了,现在面向对象语言的很多所谓“更新”,就是把函数式编程混杂进来。

编程语言能力,从普及层面上也是倒退的。二十多年前我去应聘程序员,人家让我做“餐馆安排座位”的题目,现在招程序员,考“哪个是Thread类的方法”。

也就是说,人现在根本还没有充分掌握并利用现在技术来解决问题,还没达到抱怨技术进步慢的地步。

一个破伤风都不知道怎么应对,动不动就死翘翘的水平,就先不要抱怨“怎么还没攻克癌症”。

===========

业务建模→需求→分析→设计,新技术要能够封装某个环节中间的推导智慧,才能取得大的进步,否则在小的环节上折腾已经很难。

比较容易的是分析→设计的推导,这个映射比较有规律。想办法提高人脑需要编辑的“源代码”的抽象级别,只需建模清楚领域逻辑,就能映射为最终可运行的实现,这个目前某些工具在某些平台是可以做到的,例如Rhapsody在嵌入式开发中。

我们在下册中提到的工具,是希望封装业务建模→需求的智慧。

(本文无图片,尝试在封面放一张B站截图看能否多一些点击)

[2020.01加一套题]UMLChina建模竞赛题大全-题目全文+分卷自测(11套110题)


全程字幕-25套UML+Enterprise Architect/StarUML建模示范视频


[幻灯更新]5月27-30晚-剔除“伪创新”和“无领域”的领域驱动设计-网课


[新增:鸵鸟]软件开发团队的脓包:皇帝的新装、口号党、鸵鸟、废话迷


《软件方法》书中自测题-题目全文+分卷自测(1-8章)16套111题


怪论:东北公司用用例做需求,反映了东北互联网落后?


别把洋垃圾当宝贝-评InfoQ中国“敏捷……”文章(一)


中文书籍中对《人月神话》的引用(完结,共110本):软件工程通史1930-2019、实用Common Lisp编程……


CTO也糊涂的常用术语:功能模块、业务架构、用户需求……[20210217更新]


UMLChina服务介绍


评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值