新人™：改善开发者入职体验

由 Mux 主办的 DEV 全球展示挑战赛：展示你的项目！

试着设身处地地想一想，如果你刚刚加入一个开发团队，你会是什么感受？你仔细翻阅了一页又一页的招聘信息，寻找一份既具有挑战性、又有成就感，而且远程办公条件合适的理想工作。你对简历和求职信的每一个细节都精雕细琢。你花了无数个小时复习算法和数据结构练习题，决心做好充分准备，应对技术面试中可能遇到的任何挑战。你一路过关斩将，通过了一轮又一轮的电话面试、技术面试、文化面试和高管面试。最终，看似奇迹般地，他们给了你这份工作，你毫不犹豫地接受了，生怕他们反悔。恭喜！你正式成为“新人™”。

大约7秒钟后，欣快感消退，一些残酷的现实开始涌上心头：

• 你可能不太了解你即将参与的产品或项目实际是做什么的，而且几乎肯定不太了解它是如何运作的。
• 你不了解事情发生的历史背景，所以你可能会问很多问题。作为“新人”，这可能会很困难。
• 你对团队在代码审查、版本控制管理、发布管理等各种流程方面的选择并不熟悉。你需要尽快掌握所有这些内容，因为它们对你的工作效率至关重要。
• 你并不了解团队随着时间推移而养成的一些不成文的习惯，这些习惯可能没有记录在案，但人们似乎“心照不宣”。你很可能会直接遇到这些问题，这可不是什么好事。

简而言之，你会感觉自己完全不知道该做什么。事实证明，当“新人™”是最糟糕的。

成为新人™

我们都经历过那种感觉。对很多人来说，可能还不止一次。反正从来都不是什么愉快的事。回想起我大学毕业后的第一份工作，那是很多年前在一家小型创业公司，我记得当时也有过同样的感受。不过，我当时最强烈的感受是，我只想做点什么。哪怕只是一点点也好！当然，这样我才能获得一些成就感，但更重要的是，我想向我的同事们证明，我不是个废物！

当我刚入职时，这种不确定感并非我独有。事实上，多年来我合作过和招聘过的许多开发人员都告诉我，他们刚开始工作时也经历过类似的负面情绪，而且他们也觉得克服这些情绪的最好方法就是尽快完成一些有意义的工作。

改善新员工入职体验

作为一名管理者，我的职责之一是确保每位新员工都能尽可能地获得成功。寻找、招聘和留住优秀人才成本极高，因此，确保所有新员工都能走上正确的职业道路至关重要。让新员工快速融入团队，能大大提高他们选择留下而不是继续寻找新工作的概率。当然，这需要团队的共同努力，如果没有一个完善的计划来调动其他团队成员的积极性，这项工作就很难取得理想的效果。

但就目前而言，如果我们说首先要解决的问题之一是帮助新员工克服这些负面情绪，而最好的方法似乎是帮助他们快速完成一些有意义的事情，那么我们如何才能将其正式纳入入职流程呢？

首次承诺时间

多年来，我的团队在新员工入职方面取得了显著成效，部分原因在于他们专注于一个名为“首次提交时间”的指标。顾名思义，它指的是从新员工入职到首次向版本控制系统提交代码所需的时间。目标时间可能会因应用程序的性质、编程语言、框架、工具以及其他诸多因素而有所不同。一般来说，如果新员工能够在入职第一天结束前完成首次提交，我就认为入职成功了。

该指标具有一些使其特别有效的特性：

它很全面

首次提交时间涵盖了开发者体验的诸多方面。为了提交代码，开发者必须拥有配置完整的开发环境、已分配安全凭证、已检出源代码，通常还需要在问题跟踪系统中分配任务，并且至少对组织内的一些软件开发生命周期（SDLC）策略有基本的了解。围绕所有这些环节的流程都必须进行优化，至少部分优化必须以符合这一指标。

它是定量的

首次提交时间是一个可衡量的指标，这意味着您可以相对轻松地了解团队目前的进展情况，确定一个合理的目标，以及团队可以采取哪些步骤来实现该目标。这意味着随着新工具的采用和流程的不断改进，您可以衡量这些因素对该指标产生了积极或消极的影响，并采取必要的措施来解决任何问题。例如，如果开发人员提交了一个引入新依赖项的更改，但没有记录如何设置该依赖项（或者更好的是，没有实现设置自动化），那么您很可能会看到该指标出现倒退。

优化首次提交时间

在 Prismatic，我们重点关注了两个关键领域，这有助于缩短首次提交时间。

文档

文档编写绝非光鲜亮丽，说实话，没人真正喜欢编写或维护文档。但每个人都喜欢有文档在身边。如果您是“新人™”，还在摸索前进，文档就显得尤为重要。在 Prismatic，我们竭尽所能地记录了尽可能多的内容。文档的性质大致可以分为两类：

我们会将一些比较稳定的内容添加到 Notion 的 wiki 中。这些内容包括：

• 我们偏好的 Git 工作流程，特别是关于提交消息、分支名称、变基/合并等方面。
• 我们更喜欢如何使用我们的问题跟踪系统 Clubhouse
• 针对开发环境或 Prismatic 应用程序相关问题的各种故障排除技巧

那些更易变化的内容通常会用 Markdown 文件记录，并与应用程序源代码一起提交到版本控制系统中，因为这些情况下文档往往依赖于源代码。例如：

• 开发环境配置指南。这是团队新成员最需要了解的文档，因此我们将其作为代码仓库的主要 README 文件。这是他们浏览代码仓库时首先看到的内容。
• Makefile 目标描述。Makefile 本身已经具备一定的自文档性，但我们的一些目标比较“定制化”，因此提供一些关于这些目标的额外文档，说明它们的用途以及使用原因，会非常有帮助。
• 运行单元测试和端到端测试的说明
• 推荐工具、编辑器插件等。

将这些文件与源代码一起提交的好处之一是，文档会自动成为代码审查流程的一部分。如果对源代码进行了重大更改，但文档中没有正确反映这些更改，我们会将其视为错误。

自动化

诸如搭建新的开发环境、更新依赖项以及管理应用程序基础架构变更之类的工作，通常都可以归结为一系列步骤。而计算机恰恰非常擅长执行这些步骤。所以，让计算机来完成这些工作吧！关键在于如何描述它们应该遵循的步骤。这就是自动化工具的用武之地。

Prismatic 团队目前规模还比较小，因此我们深知，随着团队规模的不断扩大以及应用程序本身功能和复杂性的持续增长，早期投资自动化将带来巨大的回报。此外，这还能显著减轻新员工加入团队的压力，因为他们只需几个小时就能在一个配置完整的环境中快速上手。

以下是我们在 Prismatic 使用的一些更具影响力的自动化示例：

• Terraform。Terraform 是一个功能极其强大的系统，我们用它来管理所有开发、持续集成、演示和生产系统的基础设施。应用更改通常只需运行一个make目标即可。
• Docker 提供了一种绝佳的方式，可以以编程方式描述各个资源的底层架构。我们无需让每个开发人员安装和管理大量本地的 Postgres、Redis 等实例，而是使用 Dockerfile 来描述这些资源。更新到最新版本非常简单，git pull只需运行一个make目标即可重新创建镜像并重新部署。
• yarn installGit钩子。每次拉取别人的更改后，都要记得运行`git add`或` git install`，真是麻烦poetry install。如果忘记立即执行，很可能会遇到奇怪的运行时错误，非常令人沮丧。所以，还是让电脑来做吧！我们使用Husky在执行`git pull`后自动下载并安装新的库依赖项git pull，从而从一开始就避免了这类问题。
• Makefile。没错，如今“任务运行器”工具数不胜数，但Make最近似乎又重新流行起来。为什么呢？或许是因为它使用起来非常简单，几乎在所有软件中都是默认安装的，而且它大多时候都能“开箱即用”。当然，目标可能会变得很复杂，语法也可能很奇怪。但即便如此，你最好还是编写一个单独的脚本，然后从Makefile中调用它。在Prismatic，数十个最常用的开发任务都通过几个不同的Makefile公开，因此我们的开发人员始终拥有非常一致的用户界面。这比试图记住哪些脚本在哪里、它们接受哪些参数等等要简单得多。

凭借全面、最新的文档以及针对大多数常见开发任务的自动化流程，我们已将首次提交时间缩短至几小时，目前为止，所有新员工都能在第一天轻松完成。我们将继续密切关注，随着系统和流程复杂性的不断提升（这种情况似乎总是会发生），我们将尽力确保新员工的第一天体验尽可能轻松无忧。

总结

您有没有发现什么特别有效的方法来改善开发者入职体验？您作为“新人™”时有什么趣事吗？我们很乐意听您分享——请通过Twitter、LinkedIn或我们的网站联系我们！