通过将设计师带入代码审查过程来更好地协作

开发人员和设计师之间的顺畅协作是每个人都向往的事情，但这是出了名的困难。 但是对于当今先进的网络，如果不跨学科协作，很难（如果不是不可能的话）构建一个真正伟大的产品。 由于构建产品所需的技术范围很广，只有当所有学科——开发人员和设计师、内容创建者和用户体验策略师——从项目的早期阶段深入参与时，产品才能真正取得成功。 当这种情况发生时，构建产品所需的所有方面自然而然地结合成一个统一的整体，从而成为一个伟大的产品。

正因为如此，没有人再真正推广瀑布流程了。 然而，尽早让其他人参与进来，尤其是其他学科的人，会让人感到害怕。 在最坏的情况下，它会导致“委员会设计”。

此外，设计师和内容策略师通常都具有在其中唯一的创意天才仍然是理想的领域的背景。 让其他人证明您的工作可能会威胁到您的创造力。

那么，您如何尽早让人们参与进来，这样您既可以避免瀑布，又可以确保您不会为委员会的设计做好准备？ 我在学习代码审查时找到了答案。

啊哈！ 片刻

2017 年 7 月，我与两名开发人员一起创立了 Confrere，我们很快聘请了我们的第一位工程师（我自己不是开发人员，我更多的是 UX 或内容设计师）。 我们的合作出人意料地顺利进行，以至于在我们的回顾展上，反复出现的主题是我们都觉得我们“做得对”。

我和我的同事坐下来，试图找出我们“做得对”的到底是什么，这样即使我们的公司发展壮大，我们的团队扩大了，我们也可以努力保持这种感觉。 我们意识到，我们都很欣赏整个团队早期的参与，并且我们在彼此的反馈中都诚实而清晰。 我们的首席技术官 Dag-Inge 补充说：“它之所以有效，是因为我们是作为同行这样做的。 你没有被责备，只是得到一个错误清单”。

“同行”这个词给了我一个哈哈的时刻。 我意识到我们这些从事 UX、设计和内容工作的人在协作方面需要向开发人员学习很多东西。

以代码审查形式进行的同行审查对于软件的构建方式至关重要。 对我来说，代码审查为改善我们自己领域内的协作提供了灵感，同时也是跨领域和跨学科协作的模式。

如果您已经熟悉代码审查，请随意跳过下一部分。

什么是代码审查？

可以通过多种方式进行代码审查。 今天，最典型的代码审查形式是所谓的拉取请求（使用一种称为 git 的技术）。 如下图所示，拉取请求让团队中的其他人知道开发人员已经完成了他们希望与主代码库合并的代码。 它还允许团队审查代码：他们在合并之前对代码提供反馈，以防需要改进。

拉取请求具有明确定义的角色：有作者和审阅者。

例如，假设我们的高级工程师 Ingvild 对 Confrere 的注册流程进行了更改。 在将其合并到主代码库并交付之前，她（作者）创建了一个拉取请求，以请求我们的 CTO Dag-Inge（审阅者）进行审阅。 他不会对她的代码进行任何更改，只会添加他的评论。

取决于 Ingvild 如何根据她在评论中收到的反馈采取行动。 她将使用她认为合适的更改来更新她的拉取请求。

当审阅者批准拉取请求时，Ingvild 可以将她的更改与主代码库合并。

为什么要费心进行代码审查？

如果您从未进行过代码审查，那么上述过程可能听起来很官僚。 如果您有疑问，这里有大量关于代码审查优势的博客文章和学术研究。

代码审查为整个公司定下了基调，即我们所做的一切都应该接受其他人的审查，并且这种审查应该成为您工作流程中受欢迎的部分，而不是被视为威胁。

——布鲁斯·约翰逊，全文的联合创始人

代码审查降低了风险。 让某人证明您的工作，并且知道有人会证明您的工作，有助于消除错误并提高质量。 此外，它确保了一致性并帮助每个团队成员熟悉更多的代码库。

如果做得好，代码审查还可以建立一种协作和开放的文化。 尝试理解和批评他人的工作是一种很好的学习方式，获得对工作的诚实反馈也是如此。

总是让至少两个人查看代码也会减少“我的”代码和“你的”代码的想法。 这是我们的代码。

考虑到这些优势，审查不应该只针对代码。

审查所有学科的原则，而不仅仅是代码

对于评论，总是有一位作者和一位或多位评论者。 这意味着您可以尽早让人们参与进来，而不会陷入委员会的设计中。

首先，我必须提到两个重要因素，它们会影响您的团队进行有益审查的能力。 您不一定必须掌握它们，但至少，您应该追求以下几点：

• 你和你的同事互相尊重，也尊重彼此的纪律。
• 你对自己的角色有足够的自信，以至于你觉得自己既可以给予批评，也可以接受批评（这也与团队的心理安全有关）。

即使我们不审查代码，也可以从现有的代码审查最佳实践中学到很多东西。

在我们的团队中，我们在进行审核时尝试遵守以下原则：

1. 批评作品，而不是作者。
2. 要批判，但要保持和蔼可亲和好奇。
3. 区分 a) 建议 b) 要求 c) 需要讨论或澄清的点。
4. 将讨论从文本转移到面对面。 （视频计数）
5. 好的部分别忘了点赞！ 什么是聪明的、有创意的、扎实的、原创的、有趣的、漂亮的等等？

直到我们讨论了为什么我们的合作工作如此顺利之后，这些原则才真正被写下来。 我们都觉得我们已经被允许并且期望我们提出问题并提出改进建议，而且我们的动机始终是共同创造伟大的东西，而不是批评另一个人。

因为我们很清楚我们给出了什么样的反馈，并且还记得互相称赞对方的出色工作，所以进行评论是一种积极的力量，而不是一种消极的力量。

一个例子

为了让您了解我们的团队如何跨学科和整个流程使用审阅，让我们看看我们团队的不同成员在创建注册流程时如何在作者和审阅者的角色之间切换。

第 1 步：需求收集

作者：艾达（UX）

审稿人： Svein（战略）、Dag-Inge（工程）、Ingvild（工程）。

如果没有结构，白板会议可能会让人筋疲力尽。 为了保持生产力和创造力，我们使用作者/审稿人结构，即使对于像在白板上进行头脑风暴这样看似基本的事情也是如此。 在这种情况下，我们提出了注册流程的要求，我必须成为作者，而团队的其他成员则提供他们的反馈并充当审阅者。 因为他们也知道他们能够审查我在第 2 步中提出的建议（更多调整、建议和改进的机会），所以我们工作迅速，能够在 2 小时内就要求达成一致。

第 2 步：用显微镜制作模型

作者：艾达（UX）

审稿人： Ingvild（工程）、Eivind（设计）、Svein（战略）。

作为一名作者，我用微文案创建了一个注册流程模型。 从用户和工程的角度来看，注册流程是否有意义？ 我们如何从设计和前端的角度改进流程？ 在这个阶段，必须以一种所有学科都可以轻松提供反馈的格式工作（我们选择了 Google Docs，但也可以使用 InvisionApp 之类的工具来完成）。

第 3 步：实施注册流程

作者： Ingvild（工程）

审稿人： Ida (UX) 和 Dag-Inge（工程）。

我们已经就流程、输入字段和微文案达成一致，因此由 Ingvild 实施。 感谢 Surge，我们可以自动创建更改的预览 URL，以便无法阅读代码的人也可以在此阶段提供反馈。

第 4 步：用户测试

作者：艾达（UX）

审稿人：用户。

是的，我们认为用户测试是一种审查形式。 我们将新建的注册流程与实际用户面对面。 这一步给了我们很多洞察力，我们的注册流程中最显着的变化也随之而来。

第 5 步：设计

作者： Eivind（设计）

审稿人： Ingvild（工程）和 Ida（UX）。

当设计在第 5 步突然出现时，它可能看起来很像瀑布过程。 然而，我们的设计师 Eivind 从第 2 步开始就已经作为审阅者参与其中。他在那个阶段提供了一堆有用的反馈，并且还能够开始思考我们如何在现有模块之外改进注册流程的设计在我们的设计系统中。 在这一步，Eivind 还可以帮助解决我们在用户测试中发现的一些问题。

第 6 步：实施

作者： Ingvild（工程）

审稿人： Eivind（设计）、Ida（UX）和 Dag-Inge（工程）。

然后我们回到实施。

为什么审查有效

总之，总是只有一个作者，从而避免了委员会的设计。 通过在早期让一系列学科作为审阅者，我们避免了瀑布过程。

人们可以及早提出他们的担忧，也可以开始考虑他们以后如何做出贡献。 明确定义的角色使流程保持在正轨上。

定期审查演练

从代码演练中汲取灵感，我们还根据以下原则定期进行不同重点的审查演练：

• 演练是一起完成的。
• 一名负责审查和记录。
• 这个想法是发现问题，而不是解决问题。
• 选择一种能够提供尽可能多的上下文的格式，以便稍后根据发现采取行动（例如，用于视觉评论的 InvisionApp，用于文本的 Google Docs，等等）。

我们已经完成了诸如可访问性审核、审核功能请求、审核设计实施以及进行启发式可用性评估等内容的审核演练。

当我们进行季度可访问性审查时，我们的可访问性顾问 Joakim 首先检查界面和文档，并优先考虑他在共享的 Google 表格中发现的问题。 然后，Joakim 向我们介绍了他发现的最重要的问题。

面对面（或至少在视频上）讨论问题有助于创造一个学习环境，而不是一种被监督或微观管理的感觉。

如果您发现自己总是被一些应该发布的东西所束缚，或者修复收件箱顶部的任何东西，评论可以帮助解决这个问题。 如果您定期留出半天时间来回顾您已经完成的工作，您可以在问题变得紧急之前发现问题。 它还可以帮助您重新集中注意力并确保您的优先事项保持正确。 在您确信现有功能符合您的标准之前，您的团队可能不应该开始构建该新功能。

用户测试是一种审查形式

代码审查的一个重要动机是降低风险。 通过每次您引入更改或向产品添加新内容时都这样做，而不仅仅是在您怀疑某些内容可能不符合标准时，您可以减少发布错误或低于标准的功能的机会。 我相信我们应该从同样的角度看待用户测试。

您会看到，如果您想降低交付时出现重大可用性问题的风险，则用户测试必须成为您流程的一部分。 仅仅让你的用户体验设计师审查界面是不够的。 一些研究发现，即使是可用性专家也无法识别出每个实际的可用性问题。 平均而言，专家发现的问题中有三分之一是误报——在实践中它们不是用户的问题。 但更糟糕的是，用户实际上确实有 2 个问题被专家忽略了。

跳过用户测试与跳过代码审查风险一样大。

评论是否意味着创造力的死亡？

从事设计、用户体验和内容工作的人通常具有艺术学校或文学的教育背景，其中唯一的创造者或创造性的艺术天才被誉为理想。 如果您回顾历史，开发人员也是如此。 随着时间的推移，随着 Web 开发变得越来越复杂，这种情况发生了必然的变化。

如果你坚持创造力来自自己内心深处的想法，那么审查的想法可能会让人感到威胁或恐惧。 有人插手你的半成品？ 哎哟。 但是，如果您认为创造力可以来自多种来源，包括对话、协作或任何形式的灵感（无论是来自外部还是来自您内心的某个地方），那么评论只是一种资产和机会。

只要我们正在为网络构建一些东西，就没有办法与其他人合作，无论是在我们自己的领域还是其他人。 一个好主意将在审查中幸存下来。

让我们一起创造伟大的东西。