Fuchsia FIDL 团队的文化原则

以下是四条有助于 Fuchsia FIDL 团队成员保持专注的文化原则。当多个看似合适的路径可用时,使用这些值有助于选择适当的操作方案。这些文化原则旨在指导我们处理工作、项目、介绍团队的方式,并帮助定义我们合作的方式。

控制设计目录

我们致力于将“已设计但尚未部署”的广告资源保持在较低水平。我们把想法编写成代码,避免在未来遥不可及。

我们希望将已接受但尚未实现的 RFC 数量保持在较低水平,或者避免参与那些我们已知在合理时间内(即时间水平)内无法见到光明的计划。随着时间的推移,“合理的时间”从几个月,到半年,再到现在约为 1 到 2 年。各种因素推动了这种地平线扩张1。我们还发现,未实现的设计不会老化,而且在首次蚀刻时有意义的要求和架构很少适合我们在未来的现实环境中发现。

我们通过保持快速以构建未来、主动将客户群迁移到这些新功能,以及总体上保持较低正在运行的迁移数量,努力避免“当前已弃用,未来无法实现”陷阱。

此外,我们还努力提供有关如何使用当前工具解决问题的具体答案,而不是推迟到未来的功能提供无法解决的问题,“它将使用 [在此处插入过时的设计文档] 进行修复”。当我们知道即将发生更好的事情时,为当前工具提供建议很困难,这也很好地提醒了我们应该有一种紧迫感,那就是通过临近的代码库将这一价值提供给用户(而不是在设计文档中,因为设计文档只会产生潜在影响)。

一种声音

在代表 Fuchsia FIDL 团队的立场时,我们口吻相同。我们力求向同行提供清晰一致的信息。我们每个人都应该以一致的方式回答问题,一致地谈论我们的路线图,始终如一地描述技术发展方向,在确定优先级方面达成一致,等等。

例如,在 fidl-dev@fuchsia.dev 上提供帮助时,所有团队成员都应该提供同样的建议。如果我们在团队中有不同的意见,我们有责任解决这些意见,以便为用户提供共同的观点。

另一个例子是,在代表 FIDL 团队编写 RFC 时,我们暗示所有团队都支持设计的总体方向(尽管 CL 中通常会讨论细节)。这意味着在 RFC 进入迭代步骤之前,团队内部已经达成一些一致意见,这可能是通过在 Gerrit CL 之外的其他媒介(例如 Google 文档)中进行的准备工作。

如果内部未能达成一致,我们的用户就会不知不觉地流露出犹豫不决或质疑,而他们对于我们所做的技术权衡不太了解。有时,这意味着我们必须承认“我们还不知道”或“尚未采取最佳做法”。在这种情况下,我们应该描述这些方案及其优缺点,并与我们的用户一起指导他们确定最适合他们的操作方案。

操作偏差

我们以行动为主导,重视工作和交付成果。我们会在想要演讲的地方发表评论、引导和评判。

在做任何事情时,都应该思考一下积极的成果是什么,我们前进的基石是什么。例如,如果我们在团队同步期间有一个有趣的设计对话,可以快速按几个要点总结我们讨论的内容。下次,这一上下文将随时准备以更坚实的基础重新打开对话。或者,如果我们在 1 对 1 的对话中讨论某个代码库中存在技术债务,并抱怨现状,我们可以选择将此问题转化为具体问题,即使这只是让所有人意识到问题、指出问题和期望的最终状态。

我们先从小规模入手2

我们一步步执行宏大愿景,分解工作,从小的概念验证开始。我们能够游刃有余地采取临时的捷径,专注于持续推动我们实现长期目标。

这关乎作业优先级、分解工作,并逐步做出改进,以最终达到理想状态。例如,我们自由做了一些无序的工作,有时无序地先解决用户面临的问题,因为知道稍后可以弥合架构差距。

例如,引入 Dart FIDL JSON 模板存在问题,因为它利用了谨慎组装(通过直观的审核,确保不存在任何句柄)并且最初收到负面消息。此 Dart FIDL JSON 功能所利用的架构差距在 18 个月以后才被 RFC-0057:默认无句柄 (RFC-0057: Default No Handles) 缩小。

另一个示例是分析代码大小(请参阅 PS1/76)。我们决定从一个不完美的解决方案开始,它能够为我们提供一些数据。然后,我们逐渐地迭代和优化了这个解决方案关键是,在改进测量结果的同时实施具体更改,以缩减 FIDL 自有代码中的二进制文件大小。因此,我们投入了大量资金来生成“创意列表”。我们对该列表执行、清理并重复执行此过程。此周期结束后一个季度后,生成的工具已变得相当精确,其报告功能已完美适应具体用例。该工具随后进行了广泛应用,现在已成为 Fuchsia 体型节食措施的关键部分。

第三个示例是使用 FIDL 语言描述 Zircon API。这一开发最初是从非常复杂的 FIDL 文件开始,有些甚至无法编译。一个新的后端 (kazoo) 诞生了,并对各种目标的支持依次添加了。时至今日,FIDL 文件仍然依赖于黑客攻击、实验性功能等。但是,我们对这项工作的长期方向充满信心,并且一直注意避免因设计债务而将 FIDL 涂成一角。

需要从纯粹的研究到尽早解决当前问题,而不考虑对未来的计划的影响,这需要保持一个连续性。我们应该意识到自己在这个连续性上的发展阶段,并积极努力地调整未来能适应未来变化或顺应未来发展的步伐。了解什么是快捷方式相对于快捷方式的优劣,找到它们之间的平衡是工程师要从事的工作之一。熟能生巧。


  1. 影响拓展时间范围的因素:

    • Fuchsia FIDL 团队规模,即,火力更大;
    • 解决短期问题(例如 2018 年 FTP 积压、fidlc 个阻碍其他团队的 bug);
    • 明确预期工作方式(例如团队同步指南或项目更新),进一步加快执行速度;
    • 设计先例(例如 RFC)锚定设计原则,并简化新想法的研究和审核。
  2. 这条原则是借用了 Jack Dorsey 的《Square's Four Corners》(从 2012 年起成为公司价值观)的一句话,“We start small”(我们初见小幅)这个醒目的标题。原则本身已扩展到与我们的工作相关。