你是否曾经看过代码并低声说出一些 "WTF"？ 是的，我也是。 很多时候，代码都是我自己写的。

我整个职业生涯都在努力编写让我感到自豪的软件。编写 "有效" 的软件很难。编写既 "有效" 又没有 bug、可读性强、可扩展、可维护且安全的软件，是一项艰巨的任务。

幸运的是，我身处一个社区，这个社区聚集了业内最优秀的开发人员、QA 和安全人员。Mozilla 的成员们通过 Webmaker、MDN、Firefox 和 Firefox OS 等项目一次又一次地证明了自己的实力。这些项目复杂，规模庞大，经过多年开发，需要数百人共同努力。

我们的社区令人惊叹，充满了技能，并且有很多东西可以教给我们。

访谈和反馈

这是访谈系列的第一部分，在这部分中，我将扮演学徒的角色，向 Mozilla 的一些最优秀的人才提问

"作为开发者，我们如何编写更优秀的软件？"

由于将软件交付给数百万用户不仅仅是编写代码，所以我从多个角度来思考这个问题：QA、安全和开发都参与其中。

目标受众是任何编写软件的人，无论他们偏爱的语言或经验水平如何。如果您正在阅读本文，那么您就是目标受众的一部分！大多数问题都是高层次的，可以应用于任何语言。少数问题是关于工具或特定于语言的功能。

问题

每次访谈都有一组独特的问题，围绕着找到以下问题的答案

• 其他开发者如何编写高质量、可维护的软件？
• "高质量、可维护的软件" 究竟意味着什么？
• 正在使用哪些流程/标准/工具？
• 其他人如何进行代码评审？
• 开发/安全/QA 如何协同工作以互相支持？
• 安全方面重视什么？他们在进行安全评审/审计时会寻找什么？
• QA 重视什么？他们在签署发布版本之前会寻找什么？
• 我作为一名开发者，可以做些什么来编写优秀软件并促进整个过程？

我将在每篇文章中介绍一到两个访谈的亮点。每个访谈都包含对受访者的简短介绍，以及一系列问答。

如果访谈内容已录音，我会提供完整文字记录的链接。如果访谈通过电子邮件进行，我会链接到原始电子邮件的内容。

现在，让我们开始第一个访谈吧！

介绍 Fernando Jimenez Moreno

第一个访谈对象是 Fernando Jimenez Moreno，他是来自 Telefonica 的 Firefox OS 开发人员。去年秋天，我们一起将 Firefox 账户集成到 Firefox OS 中，我有机会与 Fernando 合作。我不仅对他精湛的技术能力印象深刻，而且对他能够将来自三个公司、六个国家/地区的员工汇聚在一起，为共同的目标而努力的能力印象深刻。

Fernando 谈到了 Telefonica 如何参与 Firefox OS、如何将不同群体整合在一起、通用标准、代码评审，以及最重要的，务实。

您和您在 Telefonica 的团队在做什么？

我是我们所谓的平台团队的一员。Telefonica 有不同的团队，一个专注于 Gaia 的前端开发，另一个专注于平台本身，例如 Gecko、Gonk 和外部服务。我们参与了 Firefox OS 的多个部分，从 Gecko 到 Gaia，再到 SimplePush 服务器等服务。我个人参与过 Radio Interface Layer (RIL)、支付、应用程序 API 和其他 Web API 等项目，几乎总是从 Gecko 切换到 Gaia，然后再切换回来。最近，我开始为 Firefox OS 开发 WebRTC 服务。

Telefonica 如何参与与 Mozilla 的合作？

嗯，这是一个比较长的故事。我们开始着手一个类似于 Firefox OS 的项目，但不是基于 Gecko，而是基于 WebKit。所以我们创建了这个基于 WebKit 的开放式网络设备平台。当我们听说 Mozilla 在做同样的事情，但基于 Gecko 时，我们决定联系你们，并开始致力于相同的事业。我们之前的实现基于 WebKit 的闭源移植版本，以这种方式工作非常困难。从那时起，我的日常工作就和 Telefonica 的 Firefox OS 团队中的任何其他成员一样，我认为这与其他任何在 B2G 上工作的 Mozilla 工程师的工作方式都非常相似。

您是一位杰出的架构师、开发人员和跨公司协调员。在 Firefox OS 上的 Firefox 账户项目中，您将来自 Telefonica、Telenor 和 Mozilla 的人员汇聚在一起。在需要跨三个不同公司进行合作时，会遇到哪些挑战？

这是一个不小的挑战，特别是在 Firefox OS 的初期。我们早在 2011 年就开始与 Mozilla 合作，两家公司都花了些时间才找到一个适合双方的工作流程。我的意思是，我们来自电信文化，在这种文化中，默认情况下，许多东西都是封闭和保密的，而 Mozilla 则崇尚开放和透明。对于我们中的一些来自其他开源项目的人来说，开始公开工作，并准备在公开论坛上讨论和维护我们的工作并不难。但是，对于团队中的其他成员来说，需要一些时间才能适应这种新的工作方式以及新的工作展示方式。

另外，由于我们在 Telefonica 使用敏捷方法，而 Mozilla 当时还没有，所以我们不得不找到一个适合双方的通用工作流程。这花费了一些时间，进行了很多管理会议，也进行了很多讨论。至于与其他电信公司合作，到目前为止，经验都相当不错，特别是与 Telenor 的合作。我们仍然需要注意与他们分享的信息，因为最终，我们仍然是竞争对手。但这并不意味着我们不能在像 Firefox 账户这样的共同目标上与他们合作。

Mozilla 和 Telefonica 在开始这个过程时，双方都必须做出改变。你们是如何决定使用哪些通用实践以及如何建立一种共同文化的？

我认为对于敏捷方法，我们更多地关注前端部分，因为 Gecko 已经拥有非常成熟的流程和开发方式。它有自己的 6 周迭代机制。前端团队是努力寻找通用工作流程的人，因为我们开始着手 Gaia 项目，而 Gaia 是一个没有固定方法的新项目。

我不知道我们是否真正找到了工作流程，即完美的工作流程，但我认为我们做得很好。我的意思是，我们参与了敏捷方法，但当我们发现需要进行 Gecko 开发，并且需要专注于 Gecko 开发时，我们就按照他们的方式去做。

在一个多学科、多公司项目中，通用标准（如样式指南、工具和流程）有多重要？

嗯，我认为在谈论软件工程时，标准总的来说非常重要。但是，我不在乎你称之为 SCRUM、KANBAN、SCRUMBAN 还是其他什么，也不在乎你使用 Git 工作流程还是 Mercurial 工作流程，也不在乎你使用 Google 还是 Mozilla 的 Javascript 样式指南。但是，您绝对需要一些通用流程和标准，尤其是在大型工程团队中，例如开源团队，或者更一般地说是 Mozilla 开发团队。在谈论这个问题时，界限很模糊。很容易陷入过分关注定义和维护这些标准和通用流程，从而失去对真正目标的关注。因此，我认为我们不应该忘记，这些只是工具，它们很重要，但它们只是帮助我们和我们的管理者。我们应该足够聪明，在需要时能够灵活地使用它们。

我们对代码风格进行了很多代码评审，但最终你想要的是提交补丁并修复问题。如果有代码风格问题，我希望你能修复它们，但如果你需要提交补丁来完成迭代，那么就提交补丁并创建一个后续 bug 来修复问题，或者如果审阅者有时间，也可以由他们来修复问题。

Firefox OS 由 Gonk、Gecko 和 Gaia 组成。每个系统都庞大、复杂，对于新手来说很令人望而生畏。您定期向 Gecko 和 Gaia 提交补丁。每当您深入一个现有项目时，您是如何了解系统的？

我担心没有神奇的技巧。对我有效的方法对其他人可能无效。我尽量做的是，尽可能阅读代码内部和外部的文档。如果可能的话，我会尝试询问代码的拥有者，如果可能的话，因为有时他们并不在同一个代码上工作，或者他们不可用。我尝试避免一开始就逐行阅读代码，并且总是试图在深入代码细节之前了解全局概况。我认为随着时间的推移，你会不知不觉地培养出识别代码模式和识别通用架构的能力，这有助于你理解所面临的软件问题。

当你开始在不熟悉的领域编写代码时，你如何确保你的更改不会造成意外副作用？测试是其中很大一部分吗？

是的，基本上是测试、测试再测试。你需要测试、冒烟测试、黑盒测试，以及各种测试。此外，在一开始，你很大程度上依赖于审查者所说的话，并且你信任审查者，或者你可以要求 QA 或审查者为补丁添加测试。

让我们换个角度，假设你是审查者，你正在审查某人的代码。同样，当你看到“好的，这段代码添加了这个功能，我们如何确保它不会破坏其他地方？”时，你会依赖测试吗？

如果我认为补丁可能会造成任何回归，我通常会测试我需要审查的补丁。我也会尝试在“尝试”服务器上运行测试，或者要求开发人员触发“尝试”运行。

好的，所以是测试...很多测试。

是的，现在我们开始在 Firefox OS 中拥有良好的测试，我们必须利用它们。

当你进行审查时，你会寻找什么？

总的来说，我首先看的是正确性。我的意思是，补丁应该真正修复它被编写来修复的问题。当然，它不应该有副作用。它不应该引入任何回归。正如我所说，如果我有时间或补丁足够重要，我会尝试自己测试这些补丁，看看它的工作原理，看看它是否引入了回归。我也会看代码是否高效安全，以及如果可能的话，我会始终要求为补丁编写测试。最后，我会查看代码的整体质量，包括文档、编码风格、贡献和流程正确性。

你审查了我将 Firefox 账户集成到 Firefox OS 的一个大型补丁。与我收到的任何其他审查相比，你在一致性方面更加重视。

嗯，这肯定会帮助提高代码整体质量。当进行审查时，我会将这类评论标记为“nit：”，这在 Mozilla 中很常见，意思是“我希望看到更改，但即使你没有更改，你仍然会得到我的正面评价，但我真的很希望看到它们被更改。”

有两个问题。作为审查者，你如何确保你的评论不会被开发人员过度解读？第二部分是，作为开发人员，你如何确保自己不会过度解读？

说实话，我自己也收到了不少硬性的修改意见。我从不把它当回事。我的意思是，我总是试图把它，审查，当作一个积极的学习体验。我知道审查者通常没有太多时间在他们生活中进行审查。他们还需要编写代码。所以，他们会很快地写下“需要修复”，而不会花太多时间考虑用最友好的方式说出来。审查者只会在你的代码中指出负面的东西，不是负面的，而是他们认为不正确的东西。但他们通常不会说你代码中正确的东西，我知道一开始这可能很难。

但是一旦你开始做，你就会明白为什么他们不这样做。我的意思是，你有你的工作要做。这对我来说尤其困难，因为我不是英语母语人士，有时我试图用尽可能友好的方式表达，但词汇的缺乏使审查意见听起来比本意要强硬。而且，我尝试尽可能多地使用笑脸。而且，我一直尽量避免使用“r-”标记，如果我的意思是，“r-”真的很糟糕。我只是把它去掉，使用“feedback +”或其他什么。

你已经提到过，当你作为开发人员时，你试图把它当作一种学习体验。如果你作为审查者，你会把审查当作一个潜在的教学时刻吗？

是的，当然。我的意思是，仅仅审查一个补丁本身就是一个教学体验。你告诉编码者你认为什么是更正确的。有时评论中缺乏理论和理由，但我们都应该这样做，我们应该解释理由并努力使流程尽可能好。

你有没有来自你或其他人的代码片段，你认为它特别优雅，其他人可以从中学习？

我对自己的代码非常挑剔，所以我真的想不出任何我特别自豪到愿意展示的代码片段。但如果我必须选择一个简单的例子，我对 Gaia 拨号器应用程序 的最新重大重构结果，或者最近的 移动身份 API 实现 感到非常满意。

你希望鼓励人们参与哪些开源项目，他们可以去哪里参与？

当然，Firefox OS！不，说真的，我相信 Firefox OS 为软件工程师提供了机会，让他们参与到一个令人惊叹的开源社区中，其中充满了从底层到前端代码的各种技术挑战。有机会在一个如此开放的环境中深入研究 Web 浏览器和移动操作系统的内部结构，真是莫大的荣幸。一开始参与其中，并跳入流程和代码中，可能看起来很难，但已经有一些非常 优秀的 Firefox OS 文档在 MDN 上，以及很多乐于在 #b2g 和 #gaia 上提供帮助的人 邮件列表（dev-b2g 和 dev-gaia）或 ask.mozilla.org。

人们如何才能及时了解你的工作？

我没有博客，但我有一个公共的 GitHub 账户 和我的 Twitter 账户。

记录

非常感谢费尔南多接受这次采访。

完整记录 在 GitHub 上提供。

下一篇文章

在下一篇文章中，我将采访来自云服务团队的布莱恩·沃纳。布莱恩是一位安全专家，他分享了关于安全架构、威胁分析、“双保险”以及编写可审计代码的思考。

最后，做这些访谈我玩得很开心，我希望你能告诉我如何让这个系列更有用。我也在寻找莫芝拉人来采访。如果你想推荐某个人，甚至是你自己，请告诉我！请发邮件至 stomlinson@mozilla.com。