最新发布《数智时代的AI人才粮仓模型解读白皮书(2024版)》,立即领取! 了解详情
写点什么

Naresh Jain 讨论“简单设计与测试”及其专题会议

  • 2010-07-04
  • 本文字数:2565 字

    阅读完需:约 8 分钟

“简单”这个价值观是敏捷的核心理念,特别是说到软件设计之时,甚至也是软件测试方法关注重点。从 2006 年开始,Gordon Pask 大奖得主 Naresh Jain 就在运作一个全球化的、以“开放空间”为形式的会议——“简单设计与测试会议”,让实践者们能够聚在一起,推动这个话题的发展,说明其真正含义和深层意义。

最近一次会议于印度孟买在6 月26 日、27 日召开,InfoQ 让Naresh 在百忙之中空出几分钟,告诉我们在这个小型却广为人知的会议之后都发生了什么,并说明他之所以对此话题充满激情的原因。

InfoQ:“简单测试与设计”(下文简称 SDT)对你来说意味着什么?为什么人们应该关注这个理念?

Naresh Jain:
“简单设计是什么?”“你的简单是否就是我的简单?”“我们是否总能为复杂问题找到简单的解决方案?”这些年来,我一直在寻找类似问题的答案。我觉得我还没有找到所有的答案,但是我已经可以肯定地告诉我自己:不影响我的工作进度的设计,就是简单设计。这个设计是否还能更简单?也许吧。有必要再简单么?不一定,除非它阻碍了你的前进。

测试是非常有意思的实践。它的深入程度和多样性可以与设计媲美。在测试和设计中,我们都能找到很强的对立性。一方面,存在测试妄想狂,他们希望能测试自己写的每一行代码。在另一个极端存在这样的开发人员,他们认为测试最好让第三世界国家的低等劳动力完成。很难找到能够正确平衡的人,这既需要具备对相关话题的真知灼见,还得有多年的一线真实实践。以我个人之见,社区必须要能找到正确的平衡点,这非常重要。不然我们就会错失良机。

InfoQ:因此,要找到这个平衡,对于你个人和其他人来说,也许就是推动你举办 SDT 会议的核心动力了?对于这个会议的意图,你还有什么要说的么?

Naresh Jain:
没错,提供能上手的、不断突破的环境,找到这些答案,这就是我一直渴求 SDT 会议达成的目标。再说,你去参加大型的敏捷会议,就会陷入大量关于流程的话题之中。即使你能参加一些技术方面的讨论,也是很基本的,很多时候还是在向与会者们(心存疑心的人们)说明进行演进式设计、TDD、自动化测试、低精度设计、持续集成、结对编程、持续部署等实践的价值。

我们在什么时间、什么地点才能推动这些话题的发展呢?我们如何才能不再讨论最基础的东西?人们在尝试这些实践,并在某些时候遇到问题;或者做出了某些决策,希望从真正的实践者那里得到反馈。他们应该去哪里寻求帮助?

我对于这个会议的目标,是希望创立一个安全的环境,让实践者们能够面对面交流,并尽最大可能拓宽他们的学习渠道,提升学习速度。

InfoQ: 是什么因素触动你要做这件事?为什么选择百分百“开放空间”的形式?

Naresh Jain:
我过去一直认为开放空间会议不适合技术话题,直到最近参加了第一届“持续集成和测试会议”。会上的学习质量让我大为吃惊。开发大型企业应用,要想产生“简单设计”并易于测试,是非常困难的。回溯到2006 年,这是我在手上所做的项目中遇到的2 个最大的难题。

于是我对自己说:我应该围绕着这两个话题组织一个会议,而且使用与“持续集成和测试会议”同样的开放空间形式。我跟Agile Philly 用户组的人们谈了谈,他们很喜欢这个主意。David Bogus 把我介绍给West Chester 大学,他们提供了第一次会议的场地。一年年下来,就这样发展起来了。我也挺惊喜的,真的。

InfoQ: 接下来的会议将是第五次了,恭喜!是什么激励你一直把这些 SDT 会议举办并领导下来呢?你从中学到的最重要的东西又是什么?

Naresh Jain:
在每次的会议上,我都能学到东西改变、提升我的编程风格。

举个例子,在第一次会议上,我们有一个非常有趣的话题——“没有勺子”,是 Corey Haines 带领的。后来我跟 Corey 一起结对编程,我们用这种方法尝试着写了一些测试驱动代码。当我处于“素描模式”——也就是不知道我需要什么对象的时候,用这种技术来推动测试驱动是非常棒的。

下一年,我主持了一个名为Avatars of TDD 的议题,我们讨论不同的人有不同的TDD 风格。我有机会与很多人一起结对,而且真得可以尝试很多想法,这些想法会影响我的 TDD 风格。同年,我们有另一个有趣的讨论——对于我的设计,我的测试告诉了我什么?这些年来,我已经在这个话题积累了很多模式。向大家解释不是测试的问题,而是设计需要改进(别把测试这个送信的打死),这让我受益良多。

去年,一个有趣的讨论是:消除某个代码异味(最大的臭味),将会解决代码库中80% 的设计问题。我学到的是:原始强迫症(Primitive Obsession,缺少正确层次的抽象)会导致大多数问题,包括代码重复和条件复杂度。

我提到了刚刚想到的一些内容,不过大家可以去看我们的wiki ,我们积累了很多有趣的话题(记录得也很周全)。是这些讨论和学习让我不断进步。

InfoQ: 随着 SDT 会议的前进,你希望看到哪些进展?

Naresh Jain:
啊,我希望人们不要再把“SDT 会议”与“STD 会议”【译注】这两个名字产生疑惑,后者当然会引起完全不同联想!不过也确实能让人们开怀大笑,所以那也不坏!

在目前的会议上,我们的确有很多关于设计和测试话题的密切讨论。我们有上手实做的课程,但没有我希望的那么多。我希望能有更多演示,而不仅是讨论。因为说到编程,最好是动手做,而不仅仅是空谈。空谈误国。

过去几年中,我们曾计划让人们在参会前先分享他们的代码,其中包括他们面对的设计问题。有了这样的语境,人们就能重构 / 重写他们的代码,并且在会议上看到不同的人展示不同的解决方案。这会引发更多学习。

我个人认为:参加这样质量的会议对所有的人都非常重要。因此,将其扩展到世界的其他部分很重要。我希望更多的人能够采纳会议的理念,并在他们自己所在的地方组织会议(类似于 Agile Coach Camp 发生的事情)。

InfoQ: 有哪些结论是你希望分享给社区的?

Naresh Jain:
我们正在看到更多更小规模的、上手实做的、以实践者为中心的、互相学习和探索的专题会议在世界各地涌现。这非常令人兴奋,因为我相信这些更小规模的会议设置能够激发真正的学习。实践者们需要找到经验验证的方法来提升他们的技巧和视角,而且与他人一起互相学习。不要等待别人组织,如果你对于某个话题充满热情,你也可以开始这样的活动。

感谢 Naresh!

译注:STD,sexually transmitted disease,你懂的。

查看英文原文: Naresh Jain Discusses “Simple Design & Testing” And The Conference Dedicated To It

2010-07-04 23:291118
用户头像

发布了 479 篇内容, 共 152.4 次阅读, 收获喜欢 47 次。

关注

评论

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

单例模式

猴子胖胖

设计模式 Go 语言

架构师 01 期,第七周课后作业

子文

工厂方法模式

猴子胖胖

设计模式 Go 语言

服务器性能监控神器nmon使用介绍

MySQL从删库到跑路

Linux nmon 性能监控

第8周作业

静海

性能优化(1)

wing

极客大学架构师训练营

第三周作业

皮蛋

架构师

性能压测的时候,随着并发压力的增加,系统响应时间和吞吐量如何变化,为什么?

知行合一

LeetCode题解:77. 组合,回溯+for循环,JavaScript,详细注释

Lee Chen

算法 大前端 LeetCode

三周 作业

水浴清风

第三周 命题作业

willson

第三周 总结

willson

极客大学架构师训练营

Week_07 总结

golangboy

极客大学架构师训练营

架构师训练营第七周作业

吴传禹

极客大学架构师训练营

架构师训练营-第七周

袭望

第 3 周 代码重构总结

心在那片海

架构师训练营 - 第 7 周课后作业 -性能压测

树森

架构师训练营第三周心得

小兵

Chrome浏览器引擎 Blink & V8

曲迪

Java chrome 大前端 blink V8

架构师训练营第 1 期 -- 第七周学习总结

发酵的死神

极客大学架构师训练营

设计模式 - 学习总结笔记

Xuenqlve

架构训练营第三周作业

小兵

性能测试 课后作业

ABS

架构师训练营第二期 Week 3 总结

bigxiang

极客大学架构师训练营

第三周作业

hunk

极客大学架构师训练营

架构师训练营第七周学习总结

吴传禹

极客大学架构师训练营

架构师训练营第 1 期 week7 总结

张建亮

极客大学架构师训练营

抽象工厂模式

猴子胖胖

设计模式 Go 语言

成为架构师 - 架构师训练营第 03 周

陈永龙Vincent

性能压测的时候,随着并发压力的增加,系统响应时间和吞吐量如何变化

Jacky.Chen

第 3 周 代码重构作业

心在那片海

Naresh Jain讨论“简单设计与测试”及其专题会议_研发效能_Mike Bria_InfoQ精选文章