坏主意不再坏了

我从事软件工作已经大约 15 年了，在那段时间里，我犯了很多错误，并从很多其他人的错误中吸取了教训。这段经验是我在讨论技术和非技术问题的可能解决方案时可以借鉴的深井。这就是我如何知道哪些解决方案在理论上听起来不错但在实践中遇到问题，或者哪些边缘想法实际上非常适合我们在这里试图解决的问题。这些知识和经验是使我成为高效领导者的重要组成部分。不过，最近，我的直觉告诉我很多糟糕的想法，结果却变得非常有效。在我们团队本周的回顾中，这对我打击很大，这对我来说是一个真正的学习时刻。这让我意识到，我一直依赖的大部分直觉可能不再像我想象的那么有价值，而且我需要更频繁地质疑这种经历。所以我想写下一些我们现在正在做的实际上效果很好的“坏主意”，然后尝试弄清楚这对像我这样的人意味着什么。没有人审查其他人的 PR 在我的整个职业生涯中，代码审查的工作方式几乎相同：一个人编写代码并打开 PR，然后团队中的其他人在合并之前对其进行审查。第二双眼睛捕捉错误，在团队中传播知识，并防止任何人悄悄地让代码库朝着自己的方向发展。在没有审查的情况下合并你自己的公关是一种“在紧急情况下打破玻璃”的情况。大约一个月前，我们彻底改变了这一点。由于 PR 开放速度加快，我们一直在代码审查方面遇到困难，因此我们决定尝试一些疯狂的事情 - 只是不这样做。现在，处理票证的工程师与 Claude 合作，然后 Claude 打开 PR，然后处理票证的人员审查 Claude 的工作。一旦 CI 是绿色的并且 Greptile 审查是干净的，如果处理票证的人员对解决方案是可靠的充满信心，他们就会合并 PR。就是这样。无需等待队友抽出时间将上下文切换到您的更改中，也无需在 Slack 中向人们发出请求来查看。而且效果很好！当我真正思考它为什么有效时，这是因为代码审查所防止的事情仍然受到保护。每一个变化仍然有第二双眼睛——只是作者是克劳德，审阅者是拥有票的人。这个人比团队中的其他任何人都更了解这个问题，因为他们是一直致力于解决这个问题的人。与必须从头开始翻阅所有上下文的队友相比，他们是该更改的更好审查者。而且，Claude 和 Greptile 更擅长发现代码审查中经常发现的各种问题，例如小错误或不一致。在这个阶段发现诸如架构缺陷或意外的产品影响之类的大问题是非常罕见的（至少在我工作过的团队中）。我之前曾写过审查门如何成为缺乏信任的标志，所以也许我不应该对删除审查门感到如此惊讶。但我的直觉仍然告诉我“你不能在没有其他人查看的情况下就合并东西”，而我的直觉是错误的。至少到目前为止确实如此——我们只进行了一个月的改变，但到目前为止感觉非常好。将团队分成不同的工作流这是我们回顾中出现的一个问题。最近，我们有几个人出去度假，同时我们还有一些并行且相当独立的工作流正在进行。所以我们把它分开，基本上每个人都拥有一个工作流并运行它。从历史上看，我真的不喜欢这样做。当团队中的每个人都在从事不同的事情时，就会出现知识孤岛。只有一个人知道他们建造的东西是如何运作的，如果他们离开、生病或去度假，团队就会陷入困境。更糟糕的是，我认为这削弱了真正成为一个团队的感觉。你们不再一起工作来解决同一个问题，你们只是一群同时解决不同问题的人，碰巧分享了一次站立会议。基本上我领导的每个团队都反对这种设置。但在回顾中，我们讨论了它，但我们只是没有看到我担心的任何后果——至少在知识孤岛方面没有看到。原因是，跟上别人的工作速度变得如此容易。如果我需要深入了解同事一直在做的事情，我可以对 Claude 说：“嘿，让我了解一下他们一直在做的事情——它是如何工作的，它在哪里，以及还需要做什么？”几分钟后，我就得到了开始贡献所需的东西。我不需要其他人来加入我，也不需要花一天时间阅读代码来弄清楚发生了什么。 t