FreeBSD 本月动态
作者：Dru Lavigne
上一期中，我们了解了 FreeBSD 项目参与谷歌 Summer of Code（GSoC）的情况。本月，我有机会采访了 Julio Merino——一位前编程之夏学生，如今在谷歌工作。他从一名参与开源的学生起步，其经历横跨多个 BSD 项目，颇为引人入胜。他对自动化测试与代码审查的关注，让他的职业生涯与他仍参与的项目双双受益。
Julio，跟我们说说你自己。你的技术背景是什么，如何对自动化测试与代码审查产生兴趣，又是什么吸引了你加入 FreeBSD 项目？
“我差不多从出生起就接触计算机。那时我父亲买了一台 Amstrad CPC 6128 来打发时间，并教我编程基础。从那里我开始学习更低级的编程语言，并尝试 Windows 之外的操作系统——先后用过 OS/2、Linux，最终在 2000 年左右接触到 BSD。一路走来我拿到了计算机科学学士学位，然后是硕士学位。我现在为谷歌工作，是 FreeBSD 与 NetBSD 的提交者。
我是在 2005 年做第一个谷歌编程之夏（GSoC）项目时对自动化测试产生兴趣的。那时我为 NetBSD 开发了一个新文件系统（tmpfs），由于采用的是探索式方法，我需要脚本来验证代码能工作，且每次改动不引入回归。编写测试本身很有趣，但看到没有基础设施把它们串起来，令人沮丧。从那里，我在 2007 年作为另一个 GSoC 项目编写了 ATF（Automated Testing Framework）。
自 2009 年加入谷歌以来，我编写了大量测试，接触到更好的测试实践。这结合我此前对纯函数式编程范式的兴趣，教会了我许多关于如何正确组织代码以便于测试的知识。2010 年，我得出结论：ATF 提供的工具无法成长到覆盖我的测试目标，于是我开始了 Kyua 的工作。
代码审查过程有类似的故事。我参与开源已有多年（大约从 1997 年起），为各种项目贡献过。那时有以邮件列表补丁形式存在的代码审查，但我总觉得流程不够“对”。另一方面，谷歌以要求每次改动都经过代码审查而闻名，过去几年让我学到了很多。虽然一开始烦人（字面意义上），但正式的代码审查极有价值。代码审查不会捕捉到每一个问题，但取决于你如何挑选审查者，你能避免令人尴尬的错误、潜在的重大设计缺陷。事实上，现在我自己写开源代码时，如果没有代码审查来验证我的工作，我会觉得“赤裸裸”的。”
你参与创建和实现测试框架已有一段时间，先是 ATF，然后是 Kyua。为初识测试框架的用户着想，请概述使用测试框架的动机与益处、将这些框架整合到大型既有软件项目中涉及哪些工作。
“现阶段，ATF 与 Kyua 是互补的。Kyua 是一款“面向基础设施软件的测试框架”。这意味着 Kyua 提供一个运行时引擎来运行单元与集成测试，并提供汇总其结果的机制。Kyua 不打算提供持续集成（CI）系统，尽管这原本在我的计划中。如今已有完全可行的解决方案——参见 Jenkins 或 Travis CI。Kyua 试图填补系统中的空白，即提供从这些 CI 系统运行测试程序的机制。
我认为 Kyua 的主要优势在于其模块化系统，对各种测试程序类型有无缝支持。这是把既有测试程序以最小代价集成到新测试套件的关键特性，无需把它们重写来使用当下流行的测试库。
ATF 是一组用多种语言编写测试程序的库。ATF 支持 C、C++ 与 shell，所有用 ATF 实现的测试程序在彼此之间提供一致的用户界面。如果你是 atf-sh 用户，我建议你看看 shtk 的 unittest 模块，那是我最近一次尝试为 shell 实现更现代的测试库，遵循常见的 xUnit 范式。如果你用 atf-c++，可考虑以 googletest 为替代，那是一个成熟得多的 C++ 测试库。”
你在将 Phabricator 引入 FreeBSD 的过程中也发挥了重要作用。代码审查为何如此重要？从技术和文化角度看，整合有多困难？关于项目从代码审查过程中受益，你有什么轶事吗？
“哈哈，说我在将 Phabricator 引入 FreeBSD 中发挥重要作用有点“夸张”了！真的，我所做的只是对这个新工具表现出热情。我是早期采用者，并写了一篇最受欢迎的博客文章来宣扬这种对某些人来说新的实践（http://julipedia.meroh.net/2014/05/code-review-culture-meets-freebsd.html）。
代码审查重要，因为没人能写出完美代码。尤其因为开发者（包括我自己）在评估对自己不熟悉的代码部分的改动时通常过度自信。正是在这些情况下，来自“专家”的预先二次审视才有价值。
从技术层面看，我很高兴看到开源生态中有合理的工具实现来支持这一点。我不会说把 Phabricator 整合到 FreeBSD 的用例中特别困难——尽管我确实不知道，因为我不管理 FreeBSD 的机器。
把代码审查引入既有社区的棘手之处在于政治。首先，因为从未接触过代码审查的人起初把它视为负担；其次，因为有些开发者根本不相信代码审查。总而言之，我认为 FreeBSD 在克服这些障碍方面做得相当好。截至本文撰写时，FreeBSD 的 Phabricator 实例已有 2,200 多次审查，平均每天约 6 次。考虑到这仅部署了一年，在我看来这就是成功！”
FreeBSD 项目内自动化测试的现状如何？你认为五年后 FreeBSD 项目在测试与代码审查方面会发展到什么地步？
“FreeBSD 在测试方面处于合理位置。我们有能构建和运行测试的工具链。我们通过 Jenkins 持续执行这些测试。这些都很重要。
但从现状到我们期望的目标——在每次提交时运行测试、并仅运行受该提交影响的测试——还有很长的路要走。这个问题极其困难，哪怕仅仅因为 make(1) 并非一个能在如此高语义层级上跟踪依赖的友好构建系统。更不用说我们所需的额外资源量也很可观。
另一个值得改进的方面是内核级测试。目前 FreeBSD 中无法对内核级代码进行非侵入性测试——即非特权、无副作用的测试。在我看来，NetBSD 通过采用 rumpkernel 在这方面做对了（https://wiki.netbsd.org/rumpkernel/）。我认为在 FreeBSD 中实现这种方式将是一大进步。”
你对那些没有 FreeBSD src 提交权限、但有兴趣协助测试的读者有什么建议吗？
“简单：贡献测试！测试不必复杂才有用，也不必触及系统的晦涩部分。只要为每个命令行工具编写简单的集成测试、为所有公共库函数编写单元测试，我们就能走得很远。即便最简单的测试也会在开发过程中的某个时刻失败。它们之所以如此重要，是因为有助于防止回归。如果开发者破坏了一个测试，即便是最简单的，他也不得不思考破坏原因，并决定是该修复/更新测试，还是他的原始改动其实是错的。（这个问题的答案并不总是容易！）”
另一种帮助的方式是为可测试性重构代码库。编写可测试的代码需要预先规划/知识，而 BSD 中的许多代码并非以测试为考量编写。许多代码已存在多年，而自动化的持续单元测试在当时并非热门话题。”
你还有什么其他项目在酝酿吗？
“目前没什么。家里有个 3 岁的孩子，又有个宝宝即将出生，我的空闲时间很少。此外，我也喜欢写技术文章，那也很花时间。
所以只要时间允许，或者当我提醒自己使用谷歌的 20% “自由时间”时，我就把时间用在 Kyua 上。我的计划是今年推出 Kyua 1.0，为此我一直在努力工作——这某种程度上是个问题，因为我一直专注于向 Kyua 添加并行支持的编码方面，而忽略了所有相关邮件。如果你因此受到影响，深表歉意！”
Dru Lavigne 是 FreeBSD 基金会董事，BSD 认证小组主席。
以下资源提供了关于本次访谈所讨论主题的更多信息：
最后更新于