我曾在 5 家不同的软件公司工作过,做过游戏开发、手机开发和网页开发。在这些工作经历中,有一个话题一直没有得到应有的关注:迭代时间。原本我打算写一篇关于构建时间的文章,但我认为,迭代时间的视角能够更准确地切中要害。我将迭代时间定义为看到代码变更按照预期工作所花费的时间

这篇文章的目的是帮助你反思当前的开发过程。你的管道中是否有某些部分花费了过多的时间?是否有方法做一些调试工具,使变更测试更容易?单元测试是否会带来好处,但你却一直回避它,只因它的前期成本比较大?

2014 年,我以实习生的身份加入了 FIFA 团队。3A 游戏开发世界对于我来说是全新的体验。我记得当我看到我的桌面有 16 个(也许更多?)CPU 核心时,眼睛瞪得像铜铃。而后我按照指示进行设置,被告知初始构建至少要 30 分钟,在此之后增量构建将会变快。

 

虽然增量构建确实快得多,但编译一行代码变更仍然很可能需要至少 10 秒种。当时作为一名相对稚嫩的 C++开发人员,我犯了很多语法错误。每次我修改代码,都要等待 15 秒,看看我做错了什么

改 3 行代码需要一整天的时间

 

在等待时间里,我可能会随便上网搜点什么,试着想想其他的变更,或者看看聊天工具上的即时消息。毫无疑问,我的注意力可能被分散了,一分钟之后我才想起来去看看编译状态。

 

编译只是第一步。现在需要将应用程序打包部署到我所使用的平台上。当我首次打开 PS Vita、任天堂 3DS 和任天堂 Wii 时,要等 30 秒钟左右,游戏才可以在主机上运行。而后我需要启动游戏,导航到我正在改的那个游戏功能,最终可能看到我的变更。

 

我经常负责改竞赛的逻辑。测试这里的变更可能意味着要在职业模式中过上几个赛季,才能测出改了什么。不开玩笑地说,改 3 行代码需要一整天的时间,这样才能知道它实际上是否正确运行。

调试工具

我最终转向了较新的平台,被安利了一个“试验台”。它精简了一些包,试图通过只关注特定的代码区域来减少迭代时间。我找到职业模式试验台之后,就几乎再也没有运行过游戏。这个测试平台将在几秒钟内构建,并包含各种调试功能。这一切都运行在个人电脑上,事情变快了。

 

我很兴奋!但我观察了一下周围的人,我发现很多人很明显不知道如何利用这个工具。相反地,他们在沿用启动整个游戏的老方法,即通过 UI 手动导航到他们需要测试变更的功能。我很快就成为了这个试验台的拥护者,并频繁地添加新功能,使开发新内容变得更容易。

 

我仍然需要偶尔运行完整的游戏,但这个测试平台让我能够快速试验并了解代码是如何运行的,从而让我保持专注。它还使我能够以合理的(以我的标准来看)速度来修复实际的问题。

单元测试

最后,我换了团队,我发现这个团队已经在开始做单元测试了。虽然我当时有一些单元测试的经验,但我从未在游戏开发中使用过。

 

有人向我简单介绍了代码、各种测试,以及如何运行。我发现测试包基本上只包含我们团队特定游戏领域的代码。一次全新的构建可能需要 10 秒,之后的增量构建可能不到 1 秒。

 

很难强调这个阈值有多重要。实际情况是,在不到一秒钟内编译(和运行)测试,我现在可以持续关注这一个任务。编译和逻辑错误在所难免。但当我能够快速发现错误并重新编译时,就进入了一种流畅的状态。

 

第一次,我开始喜欢在工作中编写代码了。重构和移动大块代码是件轻而易举的事。修改别人的代码变得容易得多,并且知道我没有造成什么破坏。变更代码焦虑症消失了

 

我接着重写了竞赛逻辑,以加快速度并添加单元测试。各种各样的边缘情况,使单元测试成为确保覆盖所有主要内容的完美方法。

 

当我最终离开这家公司时,我感觉倍儿爽,因为我留下了一个有自我检查的系统。我花了很多时间去弄清楚一些东西应该如何工作,这些都被编入了测试规格说明书中。

结语

在很多方面,我都很感激自己在电子艺界的那段时光。我多次看到长期工程计划生根发芽带来了真正的日常收益,而这就是其中的一次。

 

在某些时候,有人会站出来说:“测试这些变更需要很长时间,有没有更好的方法?”这个问题我们每天都应该问问自己。

 

原文链接:3 Lines of Code Shouldn’t Take All Day

 

译者简介:

冬雨,小小技术宅一枚,从事研发过程改进及质量改进方面的工作,关注编程、软件工程、敏捷、DevOps、云计算等领域,非常乐意将国外新鲜的 IT 资讯和深度技术文章翻译分享给大家,已翻译出版《深入敏捷测试》、《持续交付实战》。

 

本文文字及图片出自 InfoQ

余下全文(1/3)
分享这篇文章:

请关注我们:

发表评论

邮箱地址不会被公开。 必填项已用*标注