您需要独立的技术评论！

您是否有一支精明而热情的程序员团队？ 当然！ 您已经从一百名候选人中精心挑选了他们！ 他们对产品充满热情吗？ 绝对！ 他们使用最先进的技术，从不睡觉，几乎只吃喝咖啡！ 他们相信您的业务成功吗？ 毫无疑问； 他们生活并呼吸着所有这些功能，发布，持续交付，用户体验等。您确定他们在正确开发产品吗？ 好吧，是的，你很确定。 他们为什么不呢？ …

这听起来很熟悉吗？ 我不知道有多少次我听到过创业创始人讲的这些故事。 他们中的大多数人都爱上了他们的团队……直到那天要雇用新的团队。 发生此类惨败可能有许多原因，但其中之一是缺乏定期，系统和独立的技术审查 。 缺乏对开发团队的动力不足之处就是缺乏对交付成果的关注。 另一方面，定期对结果与您的质量期望进行核对是保证启动成功的关键因素之一。 下面我总结了我组织此类技术评论的经验。

当您要求团队以外的人查看您的源代码和其他技术资源，并给您关于它们的客观意见时，即为独立审核。 每个现代软件团队还应该使用内部代码审查，这完全是另外一回事。 当一个程序员向团队中的其他同伴展示他的代码并征求他们的意见时，就会进行内部审查。 这通常是日常活动，与独立评论无关。

由对您的团队一无所知的程序员进行独立审查。 他上了船，从您的存储库中检出代码，花了几个小时（或几天）来查看它并试图了解它的作用。 然后，他告诉您哪里出了问题以及在哪里。 他解释了他将如何做得更好，在哪里进行更改以及他会做什么。 然后，您付给他，他就离开了。 您可能再也见不到他了，但是他的结论和建议可以帮助您检查代码的实际情况并评估团队的实际状况。

我们在teamed.io上对我们每个项目进行独立审核，这是我们使用的原则列表：

使独立评论系统化 。 这是第一条也是最重要的规则-定期组织此类技术审查。 此外，将时间表安排告知您的团队，并让他们为审核做好准备。 根据我的经验，每月一次是一个好习惯。 根据您的源代码大小，完整的审查应花费2到8个小时 。 不要花费超过8个小时； 在独立审阅期间，不必太深入地研究代码。

支付发现的错误 。 我们总是为错误付费，而不是为发现错误所花费的时间。 我们要求审阅者查看代码并报告我们认为需要的尽可能多的错误。 对于每个错误，我们将花费15分钟的时间。 换句话说，我们假设一个好的审稿人可以在一小时内找到并报告大约四个问题。 例如，审阅者每小时收费150美元。 我们雇用他，请他找到并报告他可以发现的20个最有争议的问题。 我们估计他应该在这项工作上花费五个小时。 因此，当我们在他报告的跟踪系统中有20个错误时，他将获得750美元。 如果他发现的钱更少，那么他得到的钱就会成比例地减少。 此付款时间表可帮助您将审核者的注意力集中在审核过程的主要目标上-查找并报告问题。 没有其他目标。 您唯一感兴趣的是知道当前技术解决方案存在的问题。 这就是您要支付的。

聘请最好的人并付高薪 。 我的经验告诉我，独立审稿人的职位非常重要。 他不仅是程序员，而且是一位架构师 ，能够从很高的抽象水平看解决方案，同时又非常注重细节。 他应该非常擅长设计类似的系统； 他应该知道如何正确，足够详细地报告错误； 他应该了解您的业务领域； 等等。除此之外，他应该有上进心为您提供帮助。 您不是在雇用他从事全职工作，而是只是几个小时的演出。 我的建议是设法招募到最好的人 ，并按他们的要求付给他们，通常每小时超过100美元。 不谈判，只付钱。 这对您来说只是几百美元，但是他们的贡献将是巨大的。

要求和期望批评 。 向审稿人问：“您喜欢我们的代码吗？”是一个非常常见的错误。 不要指望他告诉您您的代码有多出色。 这不是您要付给他的钱！ 您已经有一个完整的程序员团队来鼓舞您。 他们可以告诉您很多有关他们正在创建的代码以及它的功能。 您不想再听到审阅者的声音。 相反，您想知道什么地方出了问题，需要解决。 因此，您的问题听起来像是：“您认为我们应该首先解决哪些问题？” 一些审阅者会尝试以积极的评论取悦您，但会忽略这种奉承，而将其带回主要目标-错误。 上面说明的付款时间表应该会有所帮助。

定期更改审稿人 。 尽量不要在同一项目中多次使用同一审阅者（我的意思是相同的代码库）。 我相信这里的原因很明显，但让我再次重申：您不需要审稿人对您友好，并告诉您您的代码有多棒。 您希望他客观，专注于问题，而不是乐观的一面。 如果您一次又一次地雇用同一个人，那么从心理上讲，您会让他参与源代码。 他见过一次； 现在他必须再次看到它。 他已经告诉过您一些问题，现在必须再次重复。 他这样做不舒服。 取而代之的是，他将开始感觉自己像是团队的一员，并对源代码及其错误负责。 他和其他团队成员一样，将开始隐藏问题，而不是揭示问题。 因此，每进行一次独立的技术审查，都需要一个新人。

与团队保持礼貌和诚实 。 独立审查可能会对您的程序员造成冒犯。 他们可能会认为您不信任他们。 他们可能会觉得您不尊重他们作为技术专家。 他们甚至可能会决定您已经准备好将他们全部解雇，并且目前正在寻找新朋友。 这是独立审查的非常可能且非常具有破坏性的副作用。 你如何避免呢？ 我不能给您普遍的建议，但是我能给的最好的建议是：对他们诚实。 告诉他们，产品质量对您和您的业务至关重要。 向他们解释，企业正在为他们的工作付款，并且为了保持薪水增长，您必须定期，客观，独立和诚实地强调质量控制。 最后，如果您能够按照本文的说明组织评论，那么团队将非常感谢您。 他们将从每次评论中获得许多新的想法和想法，并会要求您定期重复它们。

从第一天开始回顾 。 不要等到项目结束！ 我已经多次看到这个错误。 很多时候，初创公司的创始人认为，在产品完成并准备投放市场之前，他们不应该分散团队的注意力。 他们认为应该让团队朝着项目的里程碑努力，并在以后“当我们每天有100万访客时”照顾质量。 如果您让您的团队不受控制地奔跑，这一天将永远不会到来！ 从您的Git存储库拥有第一个文件的那一刻起，就开始进行独立审核。 在存储库足够大之前，您每月仅可以花费300美元一次，就其质量获得客观，独立的意见。 这会破坏您的预算吗？

禁止讨论，并要求进行正式举报 。 不要让您的审稿人与团队交谈。 如果您这样做，则认为独立审核的整个想法就会瓦解。 如果审阅者能够提出非正式问题并与程序员讨论您的系统设计，那么他们的回答将使他满意，他将继续前进。 但是，您（企业的所有者）将完全保留在审核之前的位置。 评论的重点不是使评论者满意。 恰恰相反。 你想让他困惑！ 如果他感到困惑，那么您的设计是错误的，并且他认为需要报告一个错误。 源代码应该说明一切，对于陌生人（审阅者）来说，它应该足够容易理解其工作原理。 如果不是这种情况，则应该解决一些错误。

将任何问题视为错误 。 不要期望评论会产生任何功能上的错误，例如“我单击此按钮会导致系统崩溃”。 如果有的话，这种情况很少发生。 您的团队非常善于发现这些问题并加以解决。 独立审查与这种错误无关。 独立审核的主要目标是发现体系结构和设计中的错误。 您的产品可能会运行，但是其体系结构可能存在严重的设计缺陷，例如，这些缺陷将使您无法处理Web流量的指数增长。 独立的审阅者将帮助您发现这些缺陷并尽早解决。 为了从审阅者那里得到这种错误，您应该鼓励他报告他不喜欢的任何内容 ，包括技术的无用动机，缺乏文档，文件目的不明确，没有单元测试等。记住，审阅者不是您团队的成员，并且对您正在使用的技术和总体上的软件开发有自己的想法。 您有兴趣将他的愿景与团队的愿景相匹配。 然后，您有兴趣解决所有严重的不匹配问题。

查看所有内容，而不仅仅是源代码 。 让您的审阅者查看您拥有的所有技术资源，而不仅仅是源代码文件（ .java ， .rb ， .php等）。使他可以访问数据库架构，持续集成面板，构建环境，问题跟踪系统，计划和日程安排，工作议程，正常运行时间报告，部署管道，生产日志，客户错误报告，统计信息等。所有可以帮助他了解系统工作方式，更重要的是，了解系统中断位置和中断方式的内容都非常有用。 不要将审阅者仅局限于源代码，这根本不够！ 让他看到全局，您将获得更加详细和专业的报告。

跟踪如何解决不一致的问题 。 从审阅者处获得报告后，请确保最重要的问题立即进入团队的待办事项清单。 然后，确保已解决并关闭它们。 这并不意味着您应该修复所有问题并听取审阅者所说的所有内容。 当然不！ 您的建筑师负责表演，而不是审稿人。 您的架构师应确定产品的技术实施中正确与错误的方面。 但是让他解决审稿人提出的所有问题很重要。 很多时候，您会从他那里得到这样的答案：“我们现在不在乎它”，“直到下一个发行版我们都不会修复它”或“他错了；他会错了。 我们做得更好”。 这些答案是完全有效的，但必须给出答案（审阅者是人，而且他们也会犯错误）。 答案将帮助您（创始人）了解您的团队在做什么以及他们对业务的了解程度。

翻译自: https://www.javacodegeeks.com/2014/12/you-do-need-independent-technical-reviews.html