关于初创公司的研发体系构建，这可能是最成功的案例了

大家好！我是Lauren Sperber，Etsy公司的高级软件工程师。大家对Etsy可能不太熟悉——我们是一家在线市场企业，帮助人们购买及出售独特的手工艺品与古董等等。我们帮助全球150万活跃专家建立起这样一套平台，使得他们能够管理自己的创意业务并借此获取收益。

我要为大家讲述Etsy公司的工程技术文化，以及工程师之间如何凭借着共同的价值观以富有成效的方式实现愉快协作。我将对Etsy的日常工作加以概述，同时分享让这一切成为现实的Etsy工程技术方针。
我是如何工作的



Etsy公司的编程工作主要分为两大类。产品工程直接影响到买家与专家在Etsy.com以及移动应用中所能使用的功能，而基础设施工程则负责建立值得产品工程师信赖的底层架构。我主要负责产品工程方面的任务，所以我也将结合自身介绍这方面工作方式。

Etsy公司的每位程序员都拥有一套“虚拟机”，也就是与个人相对应的Etsy.com特定版本。这套虚拟机包含与实际业务平台完全相同的代码基础，但其中使用的为测试数据而非来自买家与专家的真实数据。我在自己的虚拟机上编写代码并确保其完全符合设计预期。一旦完成了当前所开发功能中的一小部分，例如通过API端点实现数据供应，或者一套负责调用该端点并将数据发送至视图的控制器，我就会进行一次阶段性提交。

多次阶段性提交的成果相结合，就创建出了一项新功能或者解决了一项既有bug。这时我会在GitHub上发布一条pull request并通过邮件将其发送给团队中的其他程序员。同事们通过评论提出建议或者疑问，而我则根据这些反馈观点发布修改，直到其达到令人满意的效果。

接下来，我会运行自动化测试以确保自己的修改不会给站点的其它组成部分造成影响。代码测试并不属于Etsy内部的硬性规定，但我们出于文化动机而始终坚持进行测试工作。这些测试并不全面，但却足以确保Etsy的主体功能在经过变更后仍能正常起效。这些测试还能验证我是否造成了语法错误——精明的同事们总能第一时间挑出我的这些小毛病。



再说点背景信息：Etsy具备的实际功能数量要远超过人们——包括内部员工——在特定时段内能够查看到的数量。我们拥有一套配置系统，旨在帮助我们轻松控制一切希望保留的功能组合，其中包括相当一部分仍处于开发过程中的成果。

我们的新代码通过标记进行隐藏，这样任何买家或者专家都不会受到变更影响。这套配置方案帮助我们在代码编写并测试完毕后能够立即进行部署——我们将这种工作方式称为“持续部署”。由于我们拥有约200名程序员负责持续部署工作，因此整套网站每天会进行超过40次更新！

为了保证程序员们能够在任意时间段内进行部署工作，我们使用IRC——一款团队聊天程序。我们在其中创建了一个名为“Push”的频道，并以此为基础建立起集团部署队列。部署团队中的第一位成员负责驱动这些push操作。如果你正好是这位员工，则需要点击对应按钮将代码部署至我们的分段环境当中，其被称为“Princess”。Princess拥有与Etsy.com网站相同的代码与数据，但由一台独立的服务器负责托管，这意味着我们能够在无需影响到Etsy用户的前提下对新代码进行测试。

一旦确认了Princess中的变更且其顺利通过自动化测试，push管理员就会按下另一个按钮将其部署至生产站点当中。我们在这里检测自己的代码并查看错误日志及可视化图形，直到确认相关代码不会造成任何预期之外的问题。这时push管理员会声明此轮push结束，下一组立刻补上进行新的部署工作。

当我们的团队开发出一款面向专家的新功能，可从两种主要选项中任择其一了解其实际效果。一种是挑选部分专家构成“原型设计组”，由他们测试我们的新功能并根据实际效果给出反馈意见。这种方式有助于建立同大型卖家的交流与合作关系，而如果经过修改的功能仍无法满足其需求，对应卖家可以随时退出此原型设计组。

与卖家在原型设计组中协作开发新功能使得我们加深了与客户间的合作关系，而他们通常也会帮助我们对新功能进行宣传，这将在功能实际发布后起到良好的普及作用。另一种选项则是选取一定比例的用户开放此项功能，并观察由此给查看、喜爱、购买以及其它重要指标造成的影响。这种定量式反馈能够帮助我们更好地对用户的站内行为加以把握。

在确认新功能能够改善买家与卖家用户体验之后，我们将面向全部用户推出该功能，但仍会根据反馈与数据进行持续改进。

现在大家已经初步了解了产品工程师是如何在Etsy构建并发布新功能的，接下来我想聊聊Etsy中的各主要软件构建实践手段。首先提到的这两种深入着眼于部分日常实践，我个人更是每天都会接触到。
代码审查



我几乎会把自己编写的每一行代码通过GitHub pull request共享给同事们。有时候即使是一行功能标记配置变量，我也会在实际部署之前交给同事们审查，从而尽可能避免出现不必要的书写或者逻辑错误。通过创建GitHub变更依据并将其粘贴到团队IRC频道当中，这项工作几乎不会带来任何实施成本。

对于规模更大的变更集，例如创建新的API端点或者新的控制器与视图集合，代码审查工作自然就变得更为重要。



协作为先

任何一种编程问题的正确解决方式都不只一种，特别在Etsy这样拥有生命周期已达十年的高复杂性代码库的生产环境下。通过邀请组内同事对我编写的代码进行审查，我能够确保自己push的代理在整体层面属于解决当前问题的最佳方案，而不仅仅是自己的一厢情愿——或者个人小聪明的产物。

不要自作聪明

代码审查降低有效降低代码内的“自作聪明”成分。在为同事进行代码审查时，我最不能接受的就是停下进度、抓耳挠腮并反复阅读代码以思考其实际作用。这往往意味着此部分代码可以进行简化，或者可以复用现有工具内的代码库加以实现。

增加代码可读性

代码一次编写完成后，往往要由多位程序员反复阅读，旨在排查其中的bug或者立足于当前基础添加其它新功能。代码审查有助于确保各类、方法以及变量在命名层面拥有良好的可识别性。如果审查者无法理解我所使用的变量名称，那么其他人也完全没有办法掌握其含义——甚至连我自己在几个月后可能都搞不清状况。另外，审查者通常还会对提供各类建议与注释，旨在进一步提升与代码作用相关的明确度水平。

提高认知能力

代码审查工作的最大收益也许体现在人们对于代码内容的理解能力上。如果我对由同事编写的尚未push的代码进行认真阅读，就能够积累与之相关的认知印象，并在未来发生问题或者需要添加新功能时，拥有着手解决的能力。

不断阅读同事们编写的代码也能帮助我了解其他程序员的问题处理思路，从而拓展我自己的思维宽度。
持续部署

正如之前所提到，我会在部署代码之前进行代码审查并运行集成测试。目前Etsy站点每天会经历超过40次部署。

如果大家从未通过这种方式处理工作，那么对每天销售额高达数百万美元的站点进行频繁更新听起来几乎有点不可思议。然而如此高效的部署能力反而让我们的网站具备更加稳定的运行表现。

减轻恐惧

我个人每天对Etsy.com网站的更新频率在每天一到五次区间，因此这也成了我日常工作的重要组成部分。因此在部署其它变更频率远低于这一水平的网站时，我能够拥有更充分的准备与自信。

降低风险

如果出现了问题，那么其根源要么来自部署、要么是出现了意料之外的状况，我们可以在准备好之后尽快push一项修复补丁。由于我们部署的变更集相对较小，因此工作人员能够很轻松地发现问题来源，面不必依靠面向网站整体的质量检查手段。



积累经验

由于我们每一位程序员都需要进行频繁的部署工作，因此大家都很清楚如何在出现问题时加以解决。

增进信心

通过push大量小型变更，我们能够确保自己的变更只会对网站中非常有限的部分造成影响，且后续结果易于测试。

以上是本文的第一部分，第二部分将会架构架构审查、无责任事后处理以及工程技术原则等方面的内容，欢迎关注聊聊架构，第一时间阅读相关内容。
点击打开链接