技术前瞻、沉浸式体验、人脉拓展......开发者必打卡的技术峰会来啦! 了解详情
写点什么

开发人员将大多数时间花到了探究系统本身上

  • 2021-11-05
  • 本文字数:1959 字

    阅读完需:约 6 分钟

开发人员将大多数时间花到了探究系统本身上

根据论文统计分析,开发人员将很多的时间都用到了探究系统本身的源码上,因为这是确定下一步行为的基础。关于如何提升代码探究的效率,作者 Tudor Girba 给出了自己的解决方案,也就是可塑开发。


本文最初发表于 feenk 网站博客,经原作者 Tudor Girba 授权,由 InfoQ 中文站翻译分享。


我经常被问到,我所说的开发人员将大多数时间花到了探究系统本身上到底是什么意思。那么我们现在就来仔细剖析这句话。

据我所知,关于这个话题,最早的参考文献可以追溯到 1979 年 Zelkowitz、Shaw 和 Gannon 写的一本书,名字叫做“Principles of software engineering and design”。书中说大多数的开发时间都花在了维护上(67%)。



软件开发的成本(1979)


当然,在这本书中,并没有说明这个数字是如何得出的。尽管如此,它被视为一个足够重要的问题,从那之后,吸引了大量的研究关注。


那么,四十多年之后的今天,现状又如何呢?


我们来看一下 Xia、Bao、Lo、Xing、Hassan 和 Li 发布在 IEEE Transactions on Software Engineering, 44, 951-976, 2018 上,名为“Measuring Program Comprehension: A Large-Scale Field Study with Professionals”的论文。这篇论文非常有意思,因为它详细阐述了这些数字是如何获取到的。按照该论文,理解部分(Comprehension)占到了大约 58%。


现在,我们仔细看一下结果的表格。



软件开发的成本(2018)


尤其是,我们关注一下表格中的第三列:它声称导航(Navigation)占到了所有工作量的 24%,在这里导航和理解是被分开计算的。


所以,我们可以看到,40 多年之后,除了学会衡量如何“计算”时间之外,并没有什么真正的改变。

那这又意味着什么呢?


的确,这是我们最大的一笔开销。如果我们想要优化自己领域中的某个事情的话,那么我们首先要去观察一下这一部分。我们会经常讨论如何构建系统,但是我们有多少次讨论“探究系统”本身呢?如果我们不谈论它,它就无法显现出来,如果无法显现出来,那我们就无法优化它。


如果我们谈论“探究系统”的时间是如何花掉的,就会注意到人们的时间用在了阅读上,正如前面的论文所示,理解本质上是通过阅读来衡量的。在大多数情况下,这两者被认为是同义词。


那么,我们该如何讨论怎样探究明白一个系统呢?


鉴于四十年来其实没有什么新的进展,所以我们应该考虑一下,也许应该以不同的方式来解决这个问题。


请耐心听我讲,现在到了有意思的地方了。那么,开发人员究竟为何要读代码呢?因为他们想要搞明白状况,从而能够知道下一步该怎么做。意图是很重要的,这就是做决策。



探究明白的时间也就是决策的时间


从这个角度来看,阅读只是从数据中收集信息的手段。它也恰好是最可能以手动的方式来实现的,所以这就为优化提供了很好的机会。


在你能够对某些事情采取一些重要的举措之前,我们首先要对其进行命名。否则的话,它就会像伏地魔一样。多年以前,我把“探究明白系统以了解下一步该做什么”所做的努力称为评估(assessment)。


当时,我就断言我们要围绕着它进行开发的优化。


在整整十年的时间内,我和我的同事一直在探索这个想法。它引导我们产生了我们现在称之为可塑开发(moldable development)的理念。


那这又是什么呢?


阅读是从数据中获取信息的一种纯手动的方式。它无法进行规模化,会导致不完整的信息和不确定性。

软件本身就已经很困难了。不了解目前的系统是什么样子的这件事不应该成为这方面中可接受的变量。关于当前系统的一张手绘图充其量只能说是一个理念。决策不应该建立在理念之上,在工程领域是不应该这样的。


一旦我们接受了系统是数据的观点,那么很明显我们就要像对待数据那样对待它。数据科学家告诉我们,首先要从问题出发,然后使用一个与上下文相匹配的工具来进行推断。



由于软件是与上下文高度关联的,我们无法预测具体的问题。我们只能预测问题的类别。为了实现这一点,可塑开发的关键理念就是在了解问题之后,工具应该是可塑的。通过这种方式,它可以处理上下文中的重要内容,也正因为如此,它可以处理阅读过程中最无聊的部分。当然,为了让它切实可行,创建自定义工具的成本必须非常小。


我认为在开发过程中构建自定义工具的流程,是软件开发的下一个重大飞跃,甚至在理想的情况下,针对每一个开发问题构建自定义工具。


在十年之后,我们不应该用阅读来衡量“探究系统”。我们应该将精力花在解决实际的问题上。为了达到这个目的,我们应该从讨论如何不读代码开始。我们必须要这样做。


我们创造了 Glamorous Toolkit,为“如何不读代码”方面提供了一个具体可行的开端。Glamorous Toolkit 是一个可塑的开发环境,使我们能够以低廉的成本创建关于软件系统的定制工具。


所以,去 gtoolkit.com 了解一下这些工具吧,感受 #MoldableDevelopment。


原文链接:


https://blog.feenk.com/developers-spend-most-of-their-time-figuri-7aj1ocjhe765vvlln8qqbuhto/

2021-11-05 10:062198

评论 1 条评论

发布
用户头像
哦,原来是外网软文。。。
2021-11-15 10:07
回复
没有更多了
发现更多内容

.net core增强工作流组件,基于稳定平台,多项目整合开发

雯雯写代码

微服务架构中的“参天大树”:SpringBoot+SpringCloud+Docker

小Q

Java 学习 容器 面试 微服务

基于Vue实现一个有点意思的拼拼乐小游戏

徐小夕

Java GitHub 开源 H5游戏 H5

影视剪辑类自媒体运营心得:如何抓住观众的痛点

石头IT视角

接口测试并不只是测试参数和返回值

测试人生路

接口测试

区块链交易所软件,数字货币场外交易系统搭建

13530558032

深圳区块链钱包系统开发,区块链钱包app源码

13530558032

直播卖货已成趋势

anyRTC开发者

音视频 WebRTC RTC

支撑2715​亿元海量订单 揭秘京东大促背后的数据库基石

京东科技开发者

数据库 数据仓库 云服务 云数据库

容器和虚拟机到底有啥区别?

网管

容器 虚拟机

【JVM】肝了一周,吐血整理出这份超硬核的JVM笔记(升级版)!!

冰河

性能优化 内存模型 JVM 堆栈 JVM笔记

《程序员面试金典》.pdf

田维常

面试

【应用运维】公司业务迭代迅速,运维如何高效进行应用发布?

嘉为蓝鲸

可视化 PaaS 运维自动化 部署与维护 发布

区块链币支付系统开发搭建,USDT支付平台源码

13530558032

SQL数据库集合运算

正向成长

SQL表联结 SQL集合运算

2020双十一,阿里云GRTN拉开直播和RTC技术下半场的序幕

阿里云视频云

架构 云直播 直播 流媒体 直播架构

区块链IM即时社交通讯系统开发,区块链社交平台源码搭建

13530558032

响应式关系数据库处理R2DBC

程序那些事

MySQL R2DBC 程序那些事 响应式系统 响应式数据库

6个JDK自带JVM调优工具,一次性打包给你说清楚

田维常

jvm调优

SpringBoot-技术专题-Hystrix学习介绍

洛神灬殇

为什么容器内存占用居高不下,频频 OOM

996小迁

Java 架构 容器 面试 k8s

这才是图文并茂:我写了1万多字,就是为了让你了解AQS是怎么运行的

鄙人薛某

Java 并发编程 AQS 并发 ReentrantLock

go-zero 如何扛住流量冲击(一)

万俊峰Kevin

microservice go-zero goctl Go 语言

Java中NullPointerException的完美解决方案

Silently9527

java8 Optional

区块链数字货币商城系统开发模式

薇電13242772558

区块链 数字货币

解读登录双因子认证(MFA)特性背后的TOTP原理

华为云开发者联盟

算法 totp 密钥

这份算法攻略,我拿到了5个大厂的offer

yes

面试 算法 笔试

2020年底备战—从技术到面试合集

iOSer

ios 编程 面试

渣本全力以赴33天,四面阿里妈妈(淘宝联盟),拿下实习岗offer

小Q

Java 学习 编程 架构 面试

什么是服务器租用?

德胜网络-阳

史上最通俗Netty入门长文:基本介绍、环境搭建、动手实战

JackJiang

网络编程 Netty nio 即时通讯 IM

开发人员将大多数时间花到了探究系统本身上_文化 & 方法_Tudor Girba_InfoQ精选文章