【ArchSummit架构师峰会】探讨数据与人工智能相互驱动的关系>>> 了解详情
写点什么

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

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

关注

评论

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

uni-app技术分享| uni-app转小程序-实时消息

anyRTC开发者

小程序 uni-app 音视频 实时消息 呼叫邀请

2022年记一次慢查询优化指南,MySQL 优化学习第9天

梦想橡皮擦

5月月更

未来以体验为中心的数字化战略前景 已经变得愈发明朗

易观分析

精细运营 渠道融合

一场会带来啥改变?三翼鸟引领行业进入有脑时代

脑极体

人工智能超大规模预训练模型浅谈

百度Geek说

智能运维应用之道,告别企业数字化转型危机

云智慧AIOps社区

大数据 监控 数字化转型 智能运维 自动化运维

如何使用 Authing 单点登录,集成 Discourse 论坛?

Authing

低代码 单点登录 Idaas 应用集成方案 Discourse

作业帮在线业务 Kubernetes Serverless 虚拟节点大规模应用实践

阿里巴巴云原生

阿里云 云原生 客户案例 作业帮 Kubernetes Serverless

一文,教你打造员工生命周期解决方案

Authing

单点登录 零信任 数据泄露 B2E 元气森林

TiDB Cloud GA,助力全球企业在云上构建新一代云原生应用

PingCAP

程序员转型产品经理:懂技术或许是把双刃剑!

博文视点Broadview

为什么前端不能没有监控系统?

杨成功

大前端 构架 5月月更

WorkPlus统一门户:企业信息互通,实现业务协作

WorkPlus

ironSource 推出 Luna Views,通过定制化数据面板呈现多渠道广告效果

Geek_2d6073

易仓跨境Saas全球租户,如何做到数据秒级响应?

阿里云大数据AI技术

数据库 flink SaaS

在虚拟机上搭建单机k8s环境

红莲疾风

Java遇上SPL:架构优势和开发效率,一个不放过

华为云开发者联盟

Java stream 应用架构 SPL 结构化数据处理

队列同步器AQS

急需上岸的小谢

5月月更

Electron 插件开发实践

网易云信

c++ Electron

干货 | Authing 产品总监佟野:Authing 的产品打磨之路

Authing

身份认证 用户思维 2B 产品 用户旅程 产品功能设计

实力印证!青藤入选第一批“网络安全能力评价工作组”成员单位

青藤云安全

SaaS到底是什么?如何做?

小炮

SaaS

李东山——如何让OpenHarmony支持低功耗蓝牙芯片GR551x

OpenHarmony开发者

OpenHarmony 低功耗蓝牙芯片

Go 学习笔记——函数篇一

为自己带盐

Go 5月月更

直播预告丨OpenHarmony标准系统多媒体子系统之音频解读

OpenHarmony开发者

OpenHarmony 多媒体

深度学习|AI芯片:上游产业率先爆发

Finovy Cloud

深度学习 gpu GPU服务器

PingCAP 宣布 TiDB Cloud 正式商用,助力全球企业在云上构建新一代云原生应用

Geek_2d6073

JavaScript数据类型

源字节1号

软件开发 前端开发 后端开发 小程序开发

集简云 x Authing,助力网校打通用户身份管理屏障

Authing

低代码 单点登录 业务流程优化 小鹅通

架构实战营之毕业总结

IT屠狗辈

架构实战营

TiDB 6.0 新特性解读 | Collation 规则

TiDB 社区干货传送门

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