You Do Need Independent Technical Reviews!

The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:

你有一队聪明而热情的程序员吗?当然有!你从一百个候选人中精心选择了他们!他们对产品充满热情吗?绝对!他们使用尖端技术,从不休息,几乎只喝咖啡而不吃或喝其他东西!他们相信你的业务能成功吗?毫无疑问;他们对所有那些功能、发布、持续交付、用户体验等等热爱得如胶似漆。你确定他们正在正确地开发产品吗?嗯,是的,你非常确定;他们为什么不会呢?…

这听起来很熟悉吗?我无法数清多少次听到创业者讲述这些故事。他们大多数人都对他们的团队充满了爱… 直到那一天,要雇佣一个新团队的时候。这可能有很多原因,但其中之一就是缺乏定期、系统和独立的技术审查。没有什么比对开发团队的交付物缺乏关注更能让他们失去动力了。另一方面,定期核对他们的成果和你对质量的期望是确保你的创业公司在技术上成功的关键因素之一。下面我总结了我组织这种技术审查的经验。

独立审查是指请团队之外的人审查你的源代码和其他技术资源,并给出客观意见。每个现代软件团队还应该进行内部代码审查,这是完全不同的一回事。内部审查是指程序员将自己的代码展示给团队上的其他同事,并征求他们的意见。这通常是日常活动,并与独立审查无关。

独立审查由一名对你的团队一无所知的程序员执行。他加入团队,检查你的代码仓库,花几个小时(或几天)查看代码并试图理解它的作用。然后,他告诉你哪里有问题。他解释如何更好地处理,他会在哪里进行更改,以及他会做什么代替。然后,你支付他的费用,他离开。你可能再也见不到他,但他的结论和建议将帮助你检查你的代码的实际情况,并评估你的团队的真正情况。

我们在Zerocracy的每个项目都进行独立审查,以下是我们使用的原则清单:

使独立审查成为系统化。这是第一条,也是最重要的规则-定期组织这样的技术审查。此外,告知团队审查的时间表,并让他们为审查做好准备。根据我的经验,每月一次是一个不错的做法。根据源代码的大小,一次完整的审查应该花费两到八个小时。不要花费超过八个小时;在独立审查期间过于深入代码是没有意义的。

按照发现的错误进行付费。我们总是为错误付费,而不是为发现错误所花费的时间付费。我们要求审查人员查看代码,并报告我们认为需要的错误数量。对于每个错误,我们支付他们15分钟的时间。换句话说,我们假设一个好的审查人员在一小时内可以找到和报告大约四个问题。例如,审查人员每小时收费150美元。我们雇佣他,并要求他找到并报告他能发现的20个最重要的问题。我们的估计是他应该花费五个小时进行这项工作。因此,当我们的跟踪系统中有20个由他报告的错误时,他将获得750美元的报酬。如果他找到的问题较少,他将获得相应较少的钱。这个支付计划将帮助你将审查人员的注意力集中在审查过程的主要目标上-发现和报告问题。没有其他目标。你唯一关心的是了解你当前技术解决方案存在哪些问题。这就是你付费的目的。

招聘最好的人并给予高薪。我的经验告诉我,独立审查员的职位非常重要。他不仅仅是一名程序员,而更像是一名能够从非常高的抽象层面审视解决方案的架构师,同时还要非常注重细节;他应该非常擅长设计类似的系统;他应该知道如何正确报告错误并提供足够的细节;他应该了解你的业务领域等等。除此之外,他应该有动力帮助你。你雇佣他不是为了全职工作,而只是为了几个小时的工作。我的建议是尽量争取到最好的人,并支付他们要求的报酬,通常超过每小时100美元。不要进行谈判,直接支付。这对你来说只是几百美元的事情,但他们的贡献效果将是巨大的。

寻求并期待批评。问一个审查人员,“你喜欢我们的代码吗?”是非常常见的错误。不要期望他告诉你你的代码有多么好。你已经有一整个团队的程序员为你加油打气;他们可以告诉你关于他们正在创建的代码以及它有多棒的很多事情。你不想再从审查人员那里听到这些。相反,你想知道什么是错误的,需要修正的。所以你的问题应该是这样的,“你认为我们应该先修复哪些问题?”有些审查人员会试图用积极的评论取悦你,但忽略这种奉承,把他们拉回到主要目标-问题上。上面解释的支付计划应该有所帮助。

定期更换审查人员。尽量不要在同一个项目(我指的是同一代码库)上多次使用同一个审查人员。我相信原因很明显,但让我再重申一下:你不需要审查人员对你友好,并告诉你你的代码有多棒。你希望他客观地关注问题,而不是亮点。如果你一次又一次地雇佣同一个人,从心理上讲,你让他对源代码产生了参与感。他已经看过一次;现在他必须再看一次。他已经告诉过你有一些问题,现在他必须再次重复。他不会觉得这样做很舒服。相反,他会开始感觉自己像是团队的一员,会对源代码及

追踪不一致性的解决情况。一旦你从审查人员那里得到报告,确保最重要的问题立即进入团队的待办事项列表。然后,确保它们得到解决并关闭。这并不意味着你应该修复所有问题并听从审查人员的每个建议。绝对不是!你的架构师掌控着一切,而不是审查人员。你的架构师应该决定产品技术实现中什么是正确的,什么是错误的。但是,让他解决审查人员提出的所有关注点是很重要的。很多时候,你会得到他这样的回答:“我们现在不关心这个问题”,“我们将在下一个版本中修复它”,或者“他错了,我们做得更好。”这些回答是完全有效的,但必须给出(审查人员也会犯错)。这些回答将帮助你作为创始人理解团队正在做什么,以及他们对业务的理解情况如何。

如果您可以根据您的经验提供更多建议,请在下方的评论中发布,我会将它们添加到列表中。我还在考虑是否可能忘记了一些重要的事情。

Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-17 at 15:35

sixnines availability badge   GitHub stars