Jyri Tuulos 著

Jyri是一名AdRoll的高级工程师。他喜欢编写开发工具和开发构建工具。

在过去的几年中，AdRoll已经从的一个不起眼的产品功能单一的创业公司发展成为拥有一套多样化产品的全球营销平台（https://www.adroll.com/product）。随着公司的发展，我们做了大量的工作，以为用户界面开发搭建坚实的基础。在这篇文章中，我们讨论在多个开发团队间所共享的人在前端项目中的影响。

A screenshot of an AdRoll dashboard with analytics, i18n, CSS and UI components visualized as layers

AdRoll的每个Web应用程序都依赖于多层前端架构

我们目前的前端基础架构由一个UI组件，一个UX模式库和各种各样JavaScript包用于国际化（如i18n）、分析和A/B测试。我们的所有这些项目都是“内部开源”的。这意味着我们鼓励我们的工程师把为这些项目贡献作为一种跨越团队边界分享知识的方式。最终，我们相信最大限度地使用广泛的思路使软件更为健壮。

如果我们的一个垂直产品团队想要提出改变基础架构，他们需要收集可能受其影响的其他团队的反馈。在最简单的情况下，这可能意味着通过属性定制UI组件中的样式。在更复杂的情况下，这可能意味着构建一个全新的共享库（如API客户端）来将我们的复杂度从其他工程团队中抽象出来。

虽然这种模式允许每个团队建立他们需要的确切解决方案，但是让有单一目的的人去思考如何让一切都兼容起来也是重要的。没有适当的所有权和监督权，共享的架构往往会变成一个复杂的补丁，这种补丁更像是阻碍而不是一个有用的工具。

前端核心团队

自2015年以来，我们建立的每个新产品和内部工具都已经实施了微服务架构。这种松散耦合的架构让我们能更快地迭代新功能，但它也已然破坏了我们的UI开发。最初，一群高级工程师能够为我们目前的前端搭建基础架构，但却不清楚谁应该担任排优先级和问题分类首要的接口人。

在2016年，我们通过创建一个叫做“前端核心”的团队正式确定了维护前端基础架构的方法。现在，这个团队与前端工程师、UI设计师和产品领导者密切合作，以确保我们的网络应用程序始终兼容所有团队。最重要的是，前端核心团队负责监督和维护我们所有的协作前端项目。

本文的其余部分通过五个部分介绍了我们的前端核心团队所提出的UI开发指南。各部分介绍了我们解决问题的一般方法，并提供了一个列表，介绍在其他团队中使用类似方法的实践指南。

消除迭代瓶颈
跨团队边界沟通
寻找通用问题和解决方案
减少成功阻碍
不断实验

消除迭代瓶颈

随着基础架构项目变得越来越复杂，团队越来越依赖它们，在不破坏现有功能的情况做出变更非常困难。考虑到这一点，我们不断精简前端基础架构的开发流程。我们的最终目标是使我们共享的项目易于使用，以便让更多的人采用并不断改进。

自2016年初以来，已经有47位内部贡献者改变了我们的前端基础设施，导致超过500个pull请求。每个变化都经过代码审查和一套自动化测试，以防意外副作用的出现。我们的前端核心团队密切关注开放的pull请求，并确保他们尽快得到审查。

为了评估这个过程的改善情况，我们还收集了pull请求的生命周期的统计数据。以下图表显示了代码审查呈现典型的双峰分布：大多数更改花了大约一周来审核，但可能只是细微快速的改变（如产品补丁），在打开pull请求后一个小时内便部署完成了。

A bar chart of pull request lifetime

为了获得你的GitHub项目的图表，我们建议您查看这个开源项目

下面是你可以在你的UI开发过程中避免常见的瓶颈的方法：

做出简单的变化，复杂的变化也要尽量快。 通常可以通过UI更改来减轻生产问题，以确保可以尽可能快地审查和发布补丁。我们鼓励在对大幅变更进行实际编程前进行讨论。
考虑在单个仓库中使用类似的JavaScript包依赖。 与完全独立的项目相比，单个代码库允许包、共用构建工具和测试脚本相对来说具有较少的开销。请参阅Babel在一个流行例子中的实践和一个前置工具包Lerna。
GitHub项目中使用pull请求模板和CODEOWNERS files。 PR模板应包括一个常见的UI开发方面的清单，如可重用性，可翻译性和风格一致性。并使用代码审查作为在UI团队之间共享知识的一种方式。
分段部署功能分支。 进行现场演示意味着审阅者并不总是需要在本地运行代码。故事书是一个构建React组件演示的极好的工具。
不要过度优化。 想知道您应该花多少时间来改善常见任务？ XKCD有答案。

跨团队边界沟通

内部开源项目严重依赖通信来告知新功能和突破性变化。基础设施团队是分享变更的来龙去脉并作为贡献者之间的中继的最重要的角色之一。

在AdRoll，前端核心团队每两周与来自我们所有产品团队的工程师和设计人员举行会议。在会议中，团队们分享了他们正在开展的任何重大的前端变革的更新，即便这些更新不直接影响到我们的基础架构。这样一个经常性的会议被证明对于识别团队之间出人意料的联系非常有用。

当一个团队提到他们正在开发新功能时，另一个团队可能会指出他们已经有了解决方案。在其他情况下，我们确定了所有人都感受到但是没有人解决的基础设施的痛点。这些讨论通常会导致我们的前端核心工作内容增加或更新我们的工作流程。

围绕前端基础架构的话题可能具有挑战性，因为UI开发涉及到许多不同的专业。设计师，工程师和产品经理通常根据他们的背景用不同的单词描述相同的东西（例如“下拉”与“下拉菜单”与“选择输入”）。单个开发人员也可能难以获得他们所有可用资源的高级概述（例如全局颜色变量和CSS类）。

为了建立一个共同的概念语言并提升创新性，我们构建了一个UX模式库，并将其作为公司内部和外部的资源发布。为了补充模式库，我们还有一个内部网站列出了我们所有的UI组件，并允许开发人员在多个版本中比较其功能（请参见下面的视频）。这些网站允许公司中的每个人都可以全面地了解我们的前端基础架构，并在引用特定的UI元素时使用明确的URL。

我们用于演示UI组件的内部网站，是用AWS JavaScript S3 浏览器构建的。

以下是一些可以改善沟通和基础设施的方法：

为前端基础设施设立专门的讨论渠道。Slack频道或电子邮件列表能很好地满足这个目的。如有需要，设置一个紧急问题的独立支持渠道。
尽可能可视化地沟通。截图，屏幕抓图和现场演示比一千个聊天消息都有意义。
发布共享软件包时使用语义化的版本控制。合适的版本控制有助于建立工程团队之间的信任。对于更新面向用户的功能，考虑到突破性的的变化，新功能和错误修复是一种有益的架构。
帮助团队度过突破性变革在内部开源项目中，你可以直接与每个用户沟通。尽力做到支持改组的团队，使得突破性的变化不那么痛苦。
对反馈和建议持开放心态基础设施是你的产品，工程师是你的用户。鼓励新工程师质疑技术选型并表达新想法。

寻找通用问题和解决方案

即使有开放和积极的沟通渠道，痛点并不总是以明确的方式浮出水面。当你的一个同事面临一个问题时，他们可能不知道这是其他人的常见问题。前端基础架构的良好维护者能够从UI开发喋喋不休的论述从归纳出清晰的解决问题陈述，并为最常见的解决方案开展工作。

以下是基础设施的一些典型消息及其含义：

我希望我有…

由于我们没有X, 我们不能…

我已经尝试去建立…

我们目前有对X的支持吗?

这种类型的消息暗示出基础架构不支持某些用户场景。接触到个人或团队了解情境，看看他们是否可以成为贡献者。

我遇到了这个问题，当…

你是如何运行的…

我不太明白X

你知道我的问题出在哪儿吗?

当人们提到错误或要求帮助时，它可能是一个真正的错误或者一个迹象表明项目的文件不够好。帮助该人解决问题，并了解如何更新项目中的说明文档。

它耗费的时间太久所以…

X太简单了所以我得…

我不能使用这个配置所以我…

这是一个技巧但是…

软件工程师为解决问题而感到自豪。当人们提到hacky解决方案并相应地改善基础设施时，请注意。官方解决方案随着时间的推移比应用程序特定的hacky更容易维护。

噢，我又忘了运行测试用例

Joe, 你能部署这个吗?

我在等Ted来…

你认为这是可以被合并的吗?

关于内部开源项目的程序性讨论可能表明开发过程不尽可能简化。可以考虑使用自动化测试和培训更多的人员担当维护者。

随着时间的推移，维护者应尽可能自动化他们项目的日常工作，以便他们能够专注于长期改进。无法自动执行的任务应有详细的记录，因此易于重复。例如，在查看我们共享的UI组件的更改时，我们总是关注全局命名空间中的更改 - CSS类，全局SASS变量和Redux的变化。

文档和指导也可以自动化：不是将人们引用到静态文档（如wiki页面），而是设计一个开发工作流程，为用户提供足够多的指令，以便他们自己解决问题。 React的错误代码系统是自文档软件的一个很好的例子：这个库本身是警告开发人员他们是否做错了事情，并指出对他们有用的文档页面。

保持基础设施稳定的最有效方法之一是抽象出大多数贡献者不需要的代码库部分的修改。这意味着将你的开发工作流视为一系列黑盒子。就像你通常不修改代码编辑器或Web浏览器的源代码一样，基础架构项目中的贡献者不需要修改构建过程或测试工具。

对于我们来说，一个这样的改进是使我们共享的UI组件的发布过程自动化。以前发布新版本的组件需要多个手动步骤，只有少数高级工程师具有运行它们的权限。结果也随着每个发布者的本地环境而略有不同。一旦我们将整个过程移动到Jenkins环境，我们可以通过从列表中选择一个名称并输入一个版本号来发布一个组件。这允许更多的贡献者自己发布更改，并减少我们的前端核心团队的工作量。

A screenshot from Slack showing notifications from Jenkins and GitHub

发布我们共享UI组件的Jenkins工作的Slack通知

以下是我们建立自文档项目的一些技巧：

使用类型检查来强化你代码中的假设。我们共享的UI组件大量使用React PropTypes。我们也在尝试TypeScript。
广泛地测试和清理你的代码。确保测试和清理自动针对每个提议的更改进行运行。像ESLint和scss-lint这样的Linters也可以帮助你提高应用程序的运行时性能。
命令行工具中的日志提示和后续步骤。例如，启动开发服务器时，请确保本地URL显示在控制台输出中。
从构建系统发送通知。应该通知贡献者，如果他们打破了构建或部署。维权人员应该是抄送通知的，这样他们可以发现经常性的问题。
写出可操作的错误消息不要指望每个人都熟悉最新的前端工具。内部服务中的错误页面应该给用户调试问题的方法。

减少成功阻碍

UI开发的成功并不仅仅意味着最终用户可以使用新的功能，这意味着新功能必须无缝融合产品中的其他一切。UI开发中的糟糕做法直接导致用户体验不佳。这给前端工程师带来了很大的压力，并迫使他们在公司中相比其他面向后端的同事，始终需要更早地考虑基础架构的问题。

当工程师在现有基础设施之上建立一些东西时，他们应该觉得他们站在巨人的肩膀上 —— 就像他们能够达成他们不知道能达到的一样。前端基础架构能让每个工程师都能建立美观，用户友好的功能，这样他们可以轻松测试，监控和部署。

为了保持有用，基础设施必须与公司一起发展。根据我们的经验，确保项目随着时间的推移而存在的最好的方式是专注于开发者的参与。这就是为什么我们认为开放源代码流程与软件基础架构是如此的好：当人们知道他们在构建项目时，他们更有可能关心它(也称为宜家效应)。

An excerpt of IKEA's assembly instructions

宜家通过其著名的装配说明帮助人们取得成功

以下是如何让开发人员从事合作项目：

做透明化的决策。您的同行工程师应该知道为什么要建立一些方法，以及为什么选择某种技术而不是另一种技术。
帮助人们了解基础架构及其使用方法。鼓励人们阅读设计文档和源代码。开放使用指标和网站分析。
确保维护者遵循与其他人相同的指导。没有人应该越过的代码审查或测试指南。当必须做出例外情况时，要了解其背后的原因。
在个人层面上突出成就为做出第一个前端贡献的工程师中庆祝。让人们通过演示和屏幕录像在会议中展示自己的工作。
让其他人领导和承担责任。为了扩展开发流程，拥有你可以信任的贡献者是必需的。将专门的UI组件的所有权委派给构建它们的团队。

不断实验

几乎所有我们学到的关于前端基础设施的知识都经过了控制实验。我们不断尝试新的有前途的技术并改进我们的开发过程。每当我们确定同一问题的不同方法时，我们会尝试最有希望的方法，然后再查看结果。

记住，即使是最好的基础设施也是一些伴随着一些开销。每一段共享的代码最终都会崩溃或变得过时。实验心态的一个重要部分是在标准化不是正确的方法时质疑你所做出的选择。

改编自XKCD #1319 "自动化"

我们正在进行的一些前端基础设施实验是：

使用Webpack替换Browserify和Gulp作为标准的前端构建过程
将Reduxactions集成到我们共享的React组件中
扩展我们的[公共风格指南]（http://ux.adroll.com/）
使用自定义JavaScript库统一使用分析，异常跟踪和A / B测试
使用Enzyme标准化整合测试（7月13日在ReactJS SF Meetup上发布的）
建立一个Yeoman生成器来引导web应用
使用Storybook在我们共享的UI组件库中进行即时演示

谢谢阅读！我们希望这篇文章对于那些希望改进UI开发流程的人是有帮助的。如果您想了解有关特定主题的更多信息或分享您在维护前端基础设施方面的经验，请随时在下面发布评论。

PS: 我们在招聘远程和本地开发者!