时隔16年Jeff Barr重返10.23-25 QCon上海站,带你看透AI如何重塑软件开发! 了解详情
写点什么

Kent Beck 建议超短项目跳过测试

  • 2009-06-23
  • 本文字数:1948 字

    阅读完需:约 6 分钟

Kent Beck 《解析极限编程》《测试驱动开发》的作者,他认为软件开发就如同高尔夫一样,是一项长期和短期相结合的运动。JUnit 是适合于长期运动项目的例子——大量的用户,稳定的收入(如果收入不幸是分文无有的话,对所有参与者都是可悲的),其关键目标是要保证开发领先于使用者的需要。

当我开始实现 JUnit Max 时,才逐渐明白规则已经发生了变化。最要命的问题曾经是(现在也是):“哪些功能可以吸引付费客户?”从定义来看,这是一个无解的问题。如果 JUnit(或任何其他免费软件)实现了一个同样的功能,没有人会为 Max 付费。

JUnit Max 的成功之处在于它开始赢利并不断扩大收入:付费用户越来越多,每个用户所带来的收入越来越多,病毒传播系数【译者注】也越来越高。从定义来看,既然取得成功的方式不为人知,那就进行大量实验,并结合实际使用得到的反馈,这就可以使得成功的机率最大化。

JUnit Max 将所有内部错误报告到一台中央服务器,一旦问题出现,Kent 就立即可以获悉。这种错误日志可以帮助找出两个问题。对于第一个问题,他可以写一个简单的测试使之重现,并验证相应的修补程序。第二个问题解决起来很容易,但 Kent 预计需要几个小时才能为它写出一个测试。在这样的情况下,他就直接修复问题并交付了。

Kent 接着说:

当我开始实现 Max 时,在第一个月里没有做任何自动化测试,所有的测试都是我手动做的。有了最初几个付费用户后,我才回头为已有的功能写测试。并且,我认为这种工作次序让我在单位时间内可以验证的实验数量最多。只用少许或根本不写代码、不写测试,这让我可以更快地开始(我花了近一周的时间才写完第一个测试)。一旦前面的代码被证明是有价值的(就这个项目来说,我的一些朋友愿意为它付费),这种测试就能让我能更有信心地快速完成实验。

是否进行自动化测试,需要对一系列因素进行权衡。即使在 Max 项目中我也写了不少的测试。如果我能找到一种简单的方式写测试,我就会先为所有功能开发验收测试。尤其是在我不能确定某个功能该如何实现时,写测试会给我很好的想法。在 Max 项目中,是否写测试这个问题发生了变化,变成了测试能否有助于我在单位时间内验证更多实验。如果有帮助,那我就写测试。如果没有就不写,甭管有啥危险。我正在力图通过 Max 获得更多收入。要论证围绕设计所付出的努力,这个过程同样复杂,只不过那是下一篇文章要讨论的话题了。

Ron Jeffries 是《极限编程实施》的作者,他回应说:“我相信你,此外还包括三个人,你们能在短期项目中做出正确决策。多年来的经验告诉我:在针对短期项目的决策影响曲线中有一个拐点,项目的可靠性和开发进度会从该点急剧下降。

Johannes Link 是敏捷软件教练 ,他说: “我看到有那么几个开发人员能够作出合理的短期或长期决定,但还没见到过能做到这一点的团队,更不用说一个组织了。”

Michael O’Brien 则给出了不同的评论:“在我看来,这是出色的文章,他也作出了正确的决定。我们在写代码时常常陷于追求漂亮和一致,而忘记了写代码的目的 。我写测试,是因为这可以让我写起代码来更容易,而且让我确信代码按我预想的方式工作。如果写测试不能帮我达到上面的目的,我会说:跳过它。”

Olof Bjarnason 认为:“Kent 提出了反馈流的概念。如果我们着眼于让单位时间内的反馈流多起来,那就走对方向了。例如,他提到在JUnitMax 这个短期项目中,他发布的功能都没有经过测试,这样在项目一开始就可以带来最多反馈流,其原因在于编写第一个测试太困难了,竟用了他一个多星期时间。他通过频繁地修改和发布获得了很高的反馈流。他的‘红色测试’是由早期的少数用户和他们的反馈意见构成。”

Guilherme Chapiewski 有这样的顾虑:在很多情况下人们会误认为某些项目是短期项目。Guilherme 遇到的情况是:之前为了验证某个想法,他打算开发一个没有任何测试的小项目。项目完成后人们开始使用它,很快就找到一些无法修复的 bug。最后,他得出结论: 代码写得太烂,根本无法测试。他只得扔掉已有代码,再从头来过。

Kent 对许多评论做出了回复:“我同意,实践和原则的混乱会导致问题。测试会产生更好的设计。这就是为什么我有大概 30 个功能测试和 25 个单元测试(奇怪的平衡吧,这是由于 Eclipse 应用很难进行测试)。几乎所有的新功能我都先加了验收测试。这样做减少了整个周期耗费的时间。”

这个想法能安全应用到不止一、两个人的团队中吗?除了 Kent Beck,人们是否有能力去判断该不该采用这种方式呢?

译者注:病毒传播系数,英文名为 viral coefficient,用来度量每个已有用户带来的新用户数,与“病毒营销(viral marketing)”相关。可参考: http://robert.zubek.net/blog/2008/01/30/viral-coefficient-calculation/

查看英文原文: Kent Beck Suggests Skipping Testing for Very Short Term Projects

2009-06-23 04:422058
用户头像

发布了 90 篇内容, 共 16.7 次阅读, 收获喜欢 11 次。

关注

评论

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

跟ChatGPT聊天、需求润色优化,禅道OpenAI 插件发布!

禅道项目管理

项目管理 openai ChatGPT

【一行代码秒上云】Serverless六步构建全栈网站

华为云开发者联盟

云计算 华为云 华为云开发者联盟 企业号 4 月 PK 榜

升级企业数智化底座,用友iuap助力企业高质量发展

用友BIP

用友 技术大会 iuap平台

【云享专刊】开源遇上华为云,OCP架构变身“云原生框架”

华为云开发者联盟

开源 云原生 华为云 华为云开发者联盟 企业号 4 月 PK 榜

阿里云 EMAS & 魔笔:3月产品动态

移动研发平台EMAS

阿里云 DevOps 测试 低代码开发 移动端开发

软件测试/测试开发丨容器编排K8S 下部署分布式UI自动化解决方案

测试人

k8s 软件测试 #Kubernetes#

540p秒变1080p!小红书端侧实时超分带你免流量玩嗨短视频

小红书技术REDtech

AI 算法 短视频

被吐槽 GitHub仓 库太大,直接 600M 瘦身到 6M,这下舒服了

程序员小富

Java git

如何在移动应用开发中,用小程序实践灰度发布策略

FinFish

灰度发布 APP开发 小程序容器 小程序技术

打造 API 接口的堡垒

Apifox

API API 安全 API 接口

基于HashData湖仓一体解决方案的探索与实践

酷克数据HashData

MobTech MobLink|裂变拓新,助力运营

MobTech袤博科技

没有研发过程数字化,DevOps就是水中月、雾中花

行云创新

DevOps 研发管理 云原生IDE

AIGC:数字内容创新的新引擎,还有藏着更多你知道的细节

加入高科技仿生人

人工智能 AI AIGC

高效前端代码编辑器:Sublime Text 4 Dev for Macv4.0(4148) 中文版

真大的脸盆

Mac 代码编辑器 Mac 软件 前端代码编辑

PCB为什么常用50Ω阻抗?6大原因

华秋PCB

科普 电路 阻抗 PCB PCB设计

青海等保测评机构有几家?分别是哪几家?

行云管家

等保 等级测评 青海

运维堡垒机定义以及作用简单讲解-行云管家

行云管家

堡垒机 运维堡垒机

DSW-Gallery使用体验+生成吸引人眼球的新闻标题

六月的雨在InfoQ

模型训练 机器学习PAI DSW-Gallery EasyNLP

应用火山引擎DataTester“避坑”,抖音实现用A/B实验快速试错

字节跳动数据平台

大数据 抖音 实验 A/B测试 企业号 4 月 PK 榜

我们与AI共生的未来 | 社区征文

TiAmo

人工智能 AI 三周年征文

Adobe全新AI工具引关注,生成式人工智能Firefly助力创作更高效、更有创意

极客天地

实践分享:如何在自己的App 中引入AI画图!

FN0

小程序 小程序容器 AI绘画

低代码开发,是稳打稳扎还是饮鸩止渴?

引迈信息

前端 低代码 JNPF

Kent Beck建议超短项目跳过测试_研发效能_Mark Levison_InfoQ精选文章