git 协同开发代码审查_现代开发人员，第4部分：代码审查和质量保证

git 协同开发代码审查

作为软件开发人员，您的工作不仅是编写代码。 它旨在为复杂的问题提供高质量的解决方案。

您编写的代码是否高质量，可以使软件完成应有的工作？ 当软件遇到错误时，是否可以正常处理？ 该软件是否安全且性能足够？

有两个过程可用来衡量和提高软件项目的质量：代码审查和质量保证。 让我们检查它们中的每一个，看看如何在工作流中实现它们以提供更好的结果。

代码评论

前一段时间，我写了一篇有关高质量代码的文章。 我想在本文中回顾几件事：

自我密码审查

首先要知道的是，自我代码审查是绝对强制性的。

第二个问题是有些代码库的质量太低，而且有很多不一致之处，所有人都放弃了。 这意味着仅在绝对必要时才对它们进行修补和进一步开发。

对于这种类型的代码库，我从第一篇文章中创建了代码质量清单的“精简版”。 在动态编写代码时，我也使用此lite版本。

当我编写代码时，通常会遗漏很多待办事项，以便以后进行重构。 这样，代码可以达到可接受的质量水平，而我不必分散自己对业务逻辑的注意力。 自从我开始使用此列表以来，代码中的待办事项已大大减少。

这是清单：

• 新代码是否遵循您正在编辑的文件的准则和样式？ –即使约定陈旧，丑陋且不是最佳约定，但如果您没有时间解决所有问题，则与引入第二种约定相比，与当前约定保持一致很可能是一种更好的方法。
• 入口点是否受到应有的限制？ –模块/类的入口点应根据需要进行多次检查。 如果保证所有私有功能和业务逻辑功能都使用干净的参数，则这将删除大量样板代码，并使关键功能变得更小，更易于阅读和调试。
• 变量和函数名称是否具有描述性？ –即使它们很长，这也是比使用较小的，隐秘的名称更好的解决方案。 对于“烂掉”的代码库，这有助于将来阅读代码。 对于新开发的代码，长名称最终将帮助您选择一个不错的选择，因为您可以将名称本身重新制作为较短的名称，但含义相同。
• 错误检查是否足够严格并已记录？ –必须记录每个错误。 另外，您希望进行尽可能多的检查-只要它们不重叠即可。 两次检查同一件事没有任何意义。 尝试通过一次检查处理多个案件。
• 如果发生错误，我是否可以单行理解整个问题？ –发生错误时，日志应具有描述性，以至于您不需要其他调试信息即可了解问题所在。

团队代码评论

更常见的代码审查方法是由团队中的某人执行。 流程本身取决于公司，并且可能会有所不同，但是重要的是必须提供反馈。

关于审稿人，他们必须提供建设性反馈。 审阅者应该知道代码应该做什么。 走廊代码检查（当您从随机同事那里获得关于一段代码的反馈时）是一个例外，但这很少使用。

当涉及到您时，受审者总是要善意。 您和审阅者都可能希望提供最高质量的代码。 不要亲自批评您的代码-您不是您的代码，也不是您的工作。

不要忘记，代码的目的是解决问题。 如果您不同意审稿人，请与他们联系并进行简短讨论。 我建议您跳过电子邮件，除非这是公司政策，否则在解决这类误解时，口头交流会更好。

代码审查软件

有一些工具可以自动进行代码审查。 尽管它们可以捕获一些错误并遵循诸如“函数名称不能长于XY符号”之类的规则，但是它们并没有那么有用……。

对我来说，它们是扩展的代码和样式短毛绒。 即使其中一些可以指出圈复杂性问题，也无法捕获业务错误。 可以随意使用它们，但是它们不能代替自我代码审查或团队代码审查。

不要跳过代码评论

尽管时间问题和尽快发布的压力可能会诱使您跳过代码审查，但这始终不是一个好主意。

软件是团队的共同努力，作为一个团队，您有责任提供最高质量的软件。 代码审查是提高工作质量和验证所发布功能是否成功的最简单方法之一。

请记住，即使是10分钟的自我代码检查也可能最终捕获到将被带入生产环境的关键业务错误。 不要妥协质量。 做代码审查。

质量保证

质量保证（QA）经历了许多趋势。 业界正朝着自动化测试迈进，但有趣的是，仍然有很多职位可供手动测试人员使用。

让我们分解一些最受欢迎的质量检查方法，看看每种方法如何提高软件的质量。

开发人员完成的质量保证

这是开发人员（通常是团队中的某人）作为最终用户测试功能是否正确的时候。 这是最古老的方法之一，部分原因是管理人员不想雇用手动质量检查人员。 最终结果通常很差。

大多数情况下，开发人员已经有了足够的想法，不会将测试的细节与开发任务同等地对待。 从理论上讲，这不应该发生，因为它不专业，但是实际上这就是发生的情况。

如今，开发人员进行测试的唯一合法方法是在开发人员内部进行测试，并且通常由团队负责人进行测试，然后再进行功能以进行真正的质量检查。

手动质量检查

在最早的质量检查形式中，一个或多个人可以手动测试该软件。 具有图形用户界面的软件主要经过手动测试。 尽管它的市场份额变小了，但到目前为止，关于它会完全消失的预测是错误的。

尽管人工完成的质量保证并不完美，但是人工学习与自动化测试不同。 经验丰富的质量保证专家已经对系统进行了几个月的测试，通常会发现开发人员和设计人员未曾考虑过的问题和案例。 有关系统及其使用方法的知识值得其投入。

由于质量检查是手动完成的，因此一些最有用的用户体验和可用性反馈可以来自经验丰富的质量保证工程师。 当收到这些反馈时，请使用它，并且不要在质量改进工程师有改进产品的想法时解雇质量检查工程师。

自动化测试

自动化测试很棒！ 编写一次，然后无论出于何种原因，根据需要运行它们多次。

是否想在提交之前检查您的代码？ 当然！ 是否想在生产中运行常规测试以确保系统正常运行？ 没问题！ 每次在master中合并后如何自动运行它们？ 我们开工吧！

自动化测试的用例可能很多。 上面的示例只是其中的一小部分。 但是为什么不是每个人都进行自动化测试？

不幸的是，与自动测试一样，它们的价格也很高。 由于自动测试是使用代码完成的，因此您必须对测试本身进行质量保证和测试。 此外，软件的任何更改都将要求测试进行更改。

简而言之，自动化测试需要大量资源才能发挥作用。 这就是为什么很多公司都没有他们的原因。

对我而言，如果正确完成，自动化测试值得投资。 我编写自动化测试的清单如下：

• 对关键业务功能进行自动化测试。
• 即使代码很丑，也要使它们尽可能简单。
• 对测试进行严格的测试，以确保它们在所有用例中均有效，并且不会返回误报。
• 当某个功能即将进行质量检查时，开始实施测试，以最大程度地减少由于重大代码或功能更改而放弃的测试数量。

自动化测试可以为大型项目节省数百小时的调试时间。 如果正确完成，它们是一个很大的优势。 唯一真正的缺点是它们需要不断分配资源。 归根结底，自动化测试为项目增加了很多价值，因此您应该提倡他们作为开发人员。

功能和非功能测试

到目前为止，我们已经根据测试的执行者或执行者对测试进行了分类，现在我们将重点针对被测试的内容探索一些类型的测试。

主要有两类：功能测试和非功能测试。

从前者开始，功能测试就是那些测试系统功能的测试。 示例包括：

• 单元测试 –通常由程序员执行，并测试软件产品的最小组件，例如功能和类。
• 集成测试–检查不同的模块和子系统是否可以很好地协同工作并正确通信。 对于分布式应用程序尤其有效。
• 验收测试 –由客户或产品所有者执行，并测试系统的整个功能。 成功通过验收测试通常意味着系统已接近生产发布。

尽管很想跳过单元测试和集成测试，但从长远来看，大多数情况下，跳过它们会降低您的速度。 不要试图偷工减料-做正确的事情，这样，在项目发布后，您将获得非常轻便的维护，而不会出现使您烦恼的错误，并将生产率降低到下一两个季度。

另一方面，非功能测试是检查系统应如何执行某些任务的测试：

• 性能测试 –检查系统在正常负载下的运行速度。
• 压力测试 –检查有多个并发用户时系统的行为。
• 恢复测试 –揭示系统是否可以从崩溃中恢复。 通常，进程开始运行时不会出现很多问题，但是存储（文件系统和数据库）将进入恢复模式。 有时，使系统正常运行的唯一方法是使用备份。
• 安全测试 –如果您负担得起安全审核，请进行一次。 如果不能，那么对于给定技术（例如Web），存在很多具有最常见漏洞的列表。 确保没有这些安全漏洞，并且系统的性能要优于所有软件的95％。

在大多数组织中，功能测试往往优先于非功能测试。 这是非常不幸的，因为每种类型的测试都是为了捕获特定的错误，并且项目通常迟早会遇到各种错误。

即使分配给质量检查的资源不足，也应在系统投入生产之前执行所有主要类型的测试。

不要忘记功能测试

功能不能有错误，不能快速运行，并且对用户友好，但仍然不是很好的功能。 更重要的是诸如以下问题：它是否执行了应该执行的任务？ 对系统有用吗？ 它会增加价值吗？

通常，如果功能与目标用户进行了几次反馈循环，则功能所带来的价值将不如所能提供的那么多。 通过代码审查或出色的QA工程师无法解决此问题。 这是公司文化层面上存在的东西。

软件质量是一个旅程，而不是目标

只要软件发生变化，保持质量不变就是一场持续的战斗。 它并不总是那么简单，也不总是那么容易，但这是使项目保持活力并减少技术债务的必要条件。

进行自我代码审查是交付更高质量软件的最便宜，最有效的方法之一。 同样，使用自动棉绒和样式检查器将帮助您专注于业务逻辑。

但是，甚至除此之外，让您的同事参与将有助于您提供更好的体系结构代码，并且进行手动和自动的质量保证将减少导致生产的错误数量。

作为软件开发人员，请始终提醒自己，保持高质量的代码与添加新功能一样重要。

翻译自: https://www.javacodegeeks.com/2019/10/the-modern-developer-code-review-and-quality-assurance.html

git 协同开发代码审查