> For the complete documentation index, see [llms.txt](https://freebsd-journal-cn.bsdcn.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://freebsd-journal-cn.bsdcn.org/20150506-ce-liang-liang-ci-dai-ma-yi-ci-xie-hao/this-month-in-freebsd.md). # FreeBSD 本月动态 * 原文：[This Month in FreeBSD](https://freebsdfoundation.org/our-work/journal/browser-based-edition/measure-twice-code-once/) * 作者：**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 中发挥重要作用有点“夸张”了！真的，我所做的只是对这个新工具表现出热情。我是早期采用者，并写了一篇最受欢迎的博客文章来宣扬这种对某些人来说新的实践（）。 代码审查重要，因为没人能写出完美代码。尤其因为开发者（包括我自己）在评估对自己不熟悉的代码部分的改动时通常过度自信。正是在这些情况下，来自“专家”的预先二次审视才有价值。 从技术层面看，我很高兴看到开源生态中有合理的工具实现来支持这一点。我不会说把 Phabricator 整合到 FreeBSD 的用例中特别困难——尽管我确实不知道，因为我不管理 FreeBSD 的机器。 把代码审查引入既有社区的棘手之处在于政治。首先，因为从未接触过代码审查的人起初把它视为负担；其次，因为有些开发者根本不相信代码审查。总而言之，我认为 FreeBSD 在克服这些障碍方面做得相当好。截至本文撰写时，FreeBSD 的 Phabricator 实例已有 2,200 多次审查，平均每天约 6 次。考虑到这仅部署了一年，在我看来这就是成功！” * FreeBSD 项目内自动化测试的现状如何？你认为五年后 FreeBSD 项目在测试与代码审查方面会发展到什么地步？ “FreeBSD 在测试方面处于合理位置。我们有能构建和运行测试的工具链。我们通过 Jenkins 持续执行这些测试。这些都很重要。 但从现状到我们期望的目标——在每次提交时运行测试、并仅运行受该提交影响的测试——还有很长的路要走。这个问题极其困难，哪怕仅仅因为 **make(1)** 并非一个能在如此高语义层级上跟踪依赖的友好构建系统。更不用说我们所需的额外资源量也很可观。 另一个值得改进的方面是内核级测试。目前 FreeBSD 中无法对内核级代码进行非侵入性测试——即非特权、无副作用的测试。在我看来，NetBSD 通过采用 rumpkernel 在这方面做对了（）。我认为在 FreeBSD 中实现这种方式将是一大进步。” * 你对那些没有 FreeBSD src 提交权限、但有兴趣协助测试的读者有什么建议吗？ “简单：贡献测试！测试不必复杂才有用，也不必触及系统的晦涩部分。只要为每个命令行工具编写简单的集成测试、为所有公共库函数编写单元测试，我们就能走得很远。即便最简单的测试也会在开发过程中的某个时刻失败。它们之所以如此重要，是因为有助于防止回归。如果开发者破坏了一个测试，即便是最简单的，他也不得不思考破坏原因，并决定是该修复/更新测试，还是他的原始改动其实是错的。（这个问题的答案并不总是容易！）” 另一种帮助的方式是为可测试性重构代码库。编写可测试的代码需要预先规划/知识，而 BSD 中的许多代码并非以测试为考量编写。许多代码已存在多年，而自动化的持续单元测试在当时并非热门话题。” * 你还有什么其他项目在酝酿吗？ “目前没什么。家里有个 3 岁的孩子，又有个宝宝即将出生，我的空闲时间很少。此外，我也喜欢写技术文章，那也很花时间。 所以只要时间允许，或者当我提醒自己使用谷歌的 20% “自由时间”时，我就把时间用在 Kyua 上。我的计划是今年推出 Kyua 1.0，为此我一直在努力工作——这某种程度上是个问题，因为我一直专注于向 Kyua 添加并行支持的编码方面，而忽略了所有相关邮件。如果你因此受到影响，深表歉意！” *** **Dru Lavigne** 是 FreeBSD 基金会董事，BSD 认证小组主席。 ## 以下资源提供了关于本次访谈所讨论主题的更多信息： * * * * * * --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://freebsd-journal-cn.bsdcn.org/20150506-ce-liang-liang-ci-dai-ma-yi-ci-xie-hao/this-month-in-freebsd.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.