改3行代码不应该花一整天的时间

我曾在 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 资讯和深度技术文章翻译分享给大家，已翻译出版《深入敏捷测试》、《持续交付实战》。