2025上半年,最新 AI实践都在这!20+ 应用案例,任听一场议题就值回票价 了解详情
写点什么

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:421894
用户头像

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

关注

评论

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

‘区块链’3M互助模式系统开发技术(源码搭建)

I8O28578624

2023年了,做SEO还有必要吗?

京东科技开发者

搜索引擎 SEO 搜索算法 SEO优化 企业号 3 月 PK 榜

XView 架构升级之路

京东科技开发者

架构 框架 企业号 3 月 PK 榜 xview

深入浅出玩转监控宝|网站监控之管理网站监控任务

云智慧AIOps社区

安全 监控宝 云智慧 监控软件 网站监控

js对象和原型、原型链的关系

hellocoder2029

JavaScript 前端

进行软件开发,需要掌握什么知识和技能?

飞算JavaAI开发助手

热点面试题:箭头函数与普通函数的区别?

沉浸式趣谈

JavaScript 箭头函数 前端面试题 #热点问题 普通函数

数据库自治平台 KAP 监控告警架构及实例演示

KaiwuDB

数据库· KaiwuDB 数据库自治

软件测试/测试开发 | 软件项目管理与跨部门沟通协作

测试人

软件测试 自动化测试 测试开发

PostgreSQL:启动与停止

天翼云开发者社区

那些高级前端是如何回答面试题的

hellocoder2029

JavaScript 前端

架构训练营第10期模块8作业

Geek_4db2d5

关于 App Store 苹果商店价格的那些事(历上最全版)

37手游iOS技术运营团队

apple In App Purchase App Store Connect API app store iTunes Store

软件测试/测试开发 | 被测系统架构与数据流分析

测试人

软件测试 自动化测试 测试开发

软件测试/测试开发 | 被测项目需求你理解到位了么?

测试人

软件测试 自动化测试 测试开发

推荐一款好用的数据一致性校验工具

NineData

MySQL 数据一致性 数据校验 IDC SqlServer

OpenHarmony 3.2 Beta Audio——音频渲染

OpenHarmony开发者

OpenHarmony

带你认识3个J.U.C组件扩展

华为云开发者联盟

开发 华为云 华为云开发者联盟 企业号 3 月 PK 榜

中国电信天翼云喜获2022中国电子学会科技进步奖一等奖!三等奖!

天翼云开发者社区

SREWorks数智运维平台开源一周年 | 回顾与展望

阿里云大数据AI技术

大数据 开源 运维 企业号 3 月 PK 榜

高校技术导师云集 OpenHarmony技术峰会“高校技术俱乐部分论坛”举办

极客天地

NFTScan 与 BNB Chain 达成战略合作,成为BNBChain Kickstart 官方数据服务提供商

NFT Research

NFT 数据基础设施

安全可信| 天翼云全栈云原生安全防护平台入选工信部“2022年网络安全技术应用试点示范项目”!

天翼云开发者社区

云上贵州:基于鲲鹏DevKit快速开发智能运维平台,性能提升75%

极客天地

湖北文旅虚拟数字代言人“胡贝儿”首秀,一点资讯助力地方文旅元宇宙落地

科技热闻

采编式AIGC视频生产流程编排实践

百度Geek说

服务编排 AIGC 企业号 3 月 PK 榜 引擎架构

量化合约系统开发程序技术(源码搭建)合约量化开发逻辑方案

I8O28578624

由浅入深,揭秘企业级OLAP数据引擎ByteHouse

字节跳动数据平台

Clickhouse 数据引擎 企业号 2 月 PK 榜

Zepoch节点持有人数大突破,Nautilus Chain 或有海量空投

西柚子

数字先锋| 云端来养牛,致富有“犇”头

天翼云开发者社区

通过源码分析RocketMQ主从复制原理

京东科技开发者

Java 源码分析 RocketMQ 端口 企业号 3 月 PK 榜

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