为什么要造轮子

作者 Lee Byron | 由 Nextoffer 翻译

前几天在 React-Europe 大会上，我分享了一个我花了三年多时间的项目 - GraphQL.

会议结束后，不少参会者问我：

Facebook 是怎么做到一直保持产出这些“反思当前最佳实践”的新技术的？

既然这是 React 大会，那么就让我们从 React 开始讲起吧。

Photo: Rasmus Andersson

两年前

两年前我们开源 React 的时候，这一直是被 JavaScript 社区取笑的对象；甚至 Facebook 内部（包括我自己）都不认为这是一个好想法。Jordan Walke 的执着和理想主义最终还是对大家产生了影响。最早我们以为他疯了，不过他的确是个疯子，但他也确实发现了一些什么。现在，我们看到 React 已经改变了我们在各种平台上「造」东西的方式。Adam Ernst 借鉴了 Jordan 的一些想法，然后「造」了 ComponentKit for iOS. 当然，我们自己的 iOS 组刚接触她的时候也是充满了猜疑；但再一次，ComponentKit 很大程度地改变了我们「造」iOS 程序的方式。

React 和 ComponentKit 都是 Facebook 内部个人自主发起的项目。事实上当时这些项目的方向和工程师团队原有的开发方式都是相反的。React 直接挑战我们当时非常看好的一些 JS 框架。其实刚开始开发 ComponentKit 的时候我们内部就已经「造」并且在使用了的一些 iOS UI 框架。

其他的工具并没有问题，也不差（话说回来他们其实很赞）但他们也不是完美的。

他们各自都有着利弊权衡，都有自己的优势和劣势。只有在一个自由开发环境的情况下，工程师才能去「造」一些他们认为更高效帮助他们完成工作的工具。

工程师的冒险文化

在 Facebook，我们不仅仅让，更是鼓励，工程师做这些好玩的“实验”。其实这些项目还是存在一定风险的，而且也不是很吸引人，也常常失败（需要改）。然后你会发现像 React, ComponentKit, HHVM, GraphQL, Immutable.js, Flow, Pop, 和 AsyncDisplayKit 这样的“实验”。这些都是值得去冒的险。对于像 Facebook 这样拥有强大的工程团队的公司来说，其中一个优势是可以充分地让工程师们去尝试这些实验，而不是盯着 scrum 或者为了公司的短期业绩来工作。

上面提到的每一个项目都遇到过非常强烈的反对。有些人（有时候甚至是我）会想让一些项目早些承认失败。然而他们并没有停止。Facebook 不仅有很好的工程师管理哲学，而且有非常棒的管理层 - 他们知道相信工程师们的重要性。就算项目遇到了同事的反对，就算也未知项目的价值所在，就算还有更重要的事情可以去做，Facebook 的管理层信任他们的工程师去冒一些值得冒的险，同时专注在他们相信能够产生影响的领域。

我的小组 - Product Infrastructure，和大多数的 Facebook 小组一样都有相同的哲学：工程师对世界的影响不止于公司的产品。上面提到的开源项目都有着很强的社区，每个开源都对整个互联网/软件行业有着深刻的影响。开源不仅仅是一个公益理想化的东西，她还是我们如何学习和展示我们的工作启发的影响的重要组成部分。

健康的开源环境在招聘环节也是非常有利的。一些我面试过的求职者对我说，他们对 Facebook 的关注是因为看到了 React, AsyncDisplayKit, Pop, 这些项目；并且想参与到这些项目中去。这些项目吸引了非常聪明的人才进来，从而自然地产生一个良性循环。

Success is not found in isolation

随着项目变得越来越有意思，她的潜力被更多的人看到，团队组建 - 然后一个雪球效应自然地推进了一整个项目。在 Facebook，工程师做着与自己职份外的项目并不罕见；或者从一个小组调到其他小组都非常常见；而这样的文化让这个雪球可以滚起来。这也意味着每个项目后面有许多无名功臣。

在这里我想点名一些（远远少于全部成员）早期为 GraphQL 做出贡献的人：Nick Schrock, Daniel Schafer, 和我自己。

• Beau Hartshorne 是 GraphQL 不可缺少的催化剂。他准确定位并指明了问题所在，找到了对的人，而且激发了我们去找解决问题的方案。Sometimes it’s hard to see the forest through the trees, and Beau’s a rare person who is always looking at the forest.

• Jonathan Dann 和 David Renie 是两位推动第一版 GraphQL 的 iOS 工程师。是他们做了非常大量的工作把 GraphQL 整合进 News Feed. 他们也协助建立了一些我们一直沿用到今天的非常重要的基础设施。

• Rasmus Andersson 用全新视角想象到一种不一样的方式在移动应用中传输数据；而这种方式成为了我们 Android SDK 的基础。他的一些想法还激发了 Relay - 用 GraphQL「造」web 端应用的工具。

• 另外两位 GraphQL 组早期成员，Nathaniel Roman and Charles Ma, 帮助开发了 GraphQL 客户端工具。

• Scott Wolchok 一手组织和改善了 GraphQL 的 iOS 和其他跨平台的客户端工具的数据模型。他的严谨的思路启发了我们去研究最新 cross-cutting 的进展。

到今天，已经有一个成熟的小组专门支持和投入到 GraphQL, 服务器，客户端工具，和 Facebook 的类型系统。

我们的使命

正是因为我们对持续产出长期价值的专注，让 Facebook 能够一直「造」出一些“反思当前最佳实践”的技术，且在业内引起不小的影响。我们敢去试错；我们相信工程师能去做正确的事。当一些“实验”看起来有点儿意思的时候，充满想法和聪明的人会自发地聚到一起来实现这个“实验”。

在 Facebook, 我们的职责不仅仅是「造」Facebook，还是让世界变得更加的开放和连接。而我们这个 Product Infrastructure 小组通过开源这些工具来帮助我们完成这个使命。

原文链接 on Medium

*本文已获得作者翻译和传播许可

*转载请注明原文链接以及译文链接