15年经验工程师反思：曾被视为坏主意的做法如今效果显著

我在软件行业干了大概15年，这些年里我犯过很多错，也从别人的错误中学到了不少。这些经验就像一口深井，讨论技术和非技术问题的可能解法时，我总能从中打水。正因如此，我知道哪些方案听起来理论漂亮、实践起来却会撞墙，也知道哪个看似边缘的想法其实恰好适合我们要解决的问题。这些知识和经验，是我作为领导者能发挥作用的重要原因。

不过最近，很多我直觉上认为是坏主意的事情，结果却运行得非常好。这周我们团队的回顾会上，这一点对我冲击很大，也成了我真正的一次学习时刻。它让我意识到，我一直依赖的很大一部分直觉，可能已经不像我以为的那么有价值了，我需要更频繁地质疑自己的经验。

所以我想写下几个我们正在做、并且效果确实很好的“坏主意”，然后试着搞清楚，这对像我这样的人意味着什么。

几乎整个职业生涯里，代码评审的运作方式都是一样的：一个人写代码、开PR，然后团队里另一个人在合并前评审。第二双眼睛能抓bug、在团队里传播知识，也能防止某个人悄悄把代码库带偏到自己的方向上。未经评审就合并自己的PR，属于“紧急情况才砸玻璃”的那类事情。

大约一个月前，我们彻底改变了这个做法。由于开PR的节奏加快，我们一直在代码评审上挣扎，于是决定尝试一件疯狂的事——干脆不做评审了。现在，负责某个工单的工程师和Claude协作，由Claude开PR，然后由做这个工单的人来评审Claude的工作。一旦CI通过、Greptile评审干净，如果做这个工单的人觉得方案靠谱，就合并PR。就这样。不用等队友找到时间切换到你的改动上，也不用在Slack里@人求看一眼。

而且效果很好！当我认真想想为什么有效时，原因是代码评审原本要防的东西仍然被防住了。每个改动仍然有第二双眼睛——只不过作者是Claude，评审者是负责该工单的人。这个人比团队里任何人都更理解问题，因为一直是他们在做这件事。对于这个改动来说，他们比一个必须从头加载所有上下文的队友是更好的评审者。而且，Claude和Greptile在发现代码评审中常见的那类问题——比如小bug或不一致——上就是更强。像架构缺陷或意外的产品影响这种大问题，在这个阶段被发现的概率本来就很低（至少在我待过的团队里是这样）。

我以前写过，评审关卡可能是缺乏信任的信号，所以也许我不该对去掉一个关卡居然奏效感到那么惊讶。但我的直觉仍然说“没人看一眼就不能合并”，而我的直觉错了。至少到目前为止是这样——这个改动才做了一个月，但感觉确实很好。

这个是我们在回顾会上提到的。最近有几个人休假，同时我们又有几条并行且相对独立的工作流。于是我们做了拆分，基本上每个人负责一条工作流并推进下去。

从历史上看，我真的很不喜欢这样做。当团队里每个人都在做不同的事情时，就会出现知识孤岛。只有一个人知道自己做的东西怎么运作，如果他们离开、生病或休假，团队就卡住了。更糟的是，我觉得这会侵蚀真正作为一个团队的感觉。你们不再是一起解决同一个问题，而是一群人同时解决不同的问题，只是碰巧共享同一个站会。基本上在我带过的每个团队，我都反对过这种安排。

但在回顾会上我们聊了这件事，我们并没有看到我担心的那些后果——至少在知识孤岛方面没有。原因是，现在要跟上别人的工作变得太容易了。如果我需要跳进同事一直在做的某件事，我可以对Claude说：“嘿，帮我跟上他们一直在做的这个东西——它怎么运作、现在到哪一步了、还有什么需要做？”几分钟后我就有了开始贡献所需的东西。我不需要别人来带我上手，也不需要花一天读代码搞清楚发生了什么。

真正改变的是上下文切换的成本大幅下降了，因为我们操作在比以前更高的层级上。我并不真的需要切换到具体代码及其运作方式上（至少开始阶段不需要那么多）。我真正需要切换进去的是问题本身。只要我对我们要解决的问题有概念性理解，并且大致知道我们想要的解决方案是什么形状，我就能跳进去并发挥作用。

这种工作方式会不会有我们还没看到的长期后果？也许吧！我 honestly 不确定。但“也许有个我们还没看到的问题”和我一年前会给出的论证——“我很确定这是个坏主意，我们会后悔的”——是非常不同的。

这个与其说关于我的团队如何运作，不如说关于我给我管理的人的建议。很长一段时间里，我对工程师技术和职业发展的标准建议是经典的“T型”那套。首先你建立起扎实的通用工程基础

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）