代码质量综合指南：最佳实践和工具

当您的软件团队快速增长时，确保代码质量是一个巨大的挑战。但是，即使有固定数量的软件开发人员，维护代码质量也会引起麻烦。

如果没有工具和一致的系统，整个项目可能积累巨大的技术债务，长期造成的问题比短期解决的问题要多。

最好的事情是，你不必成为一个火箭科学家来避免这一点（当然，如果你是火箭科学家的话，这不是问题）。

我们提供了一个很重的指南，帮助您从根本上提高团队生成的代码的质量，无论您是与内部团队还是软件外包公司合作。

这篇文章的某些部分可能看起来很明显，但其价值在于这些部分是如何连接起来并建立起一个有效的代码质量保证系统的。

代码质量到底是什么？

代码质量是一组不同的属性和需求，由您的业务决定和确定优先级。以下是可用于确定它的主要属性：

质量代码不一定满足上述所有属性，但满足的越多，质量就越高。这些需求更像是取决于项目特性的优先级列表。

为什么要关心代码质量？

我知道，当你在压力下不得不在下一个截止日期前完成工作时，很难关注代码质量，但是如果你想长远考虑，你肯定需要生成可读和可维护的代码。以下是代码质量重要的三个主要原因：

为您的团队构建代码质量保证体系

在这一部分中，我将向您展示如何使用版本控制、样式指南和自动化测试来确保我们的代码符合预定义的质量标准。

通过遵循这些方法，您可以轻松地复制我们的系统，并从根本上提高您的团队生成的代码质量。您只需执行以下步骤：

一。版本控制工具，确保代码质量和透明度

版本控制工具是我们系统的基础。

最流行的版本控制工具是Git。它还提供了一个分支样式的指南，称为GitFlow，它支持团队成员之间的无缝协作，并使扩展开发团队变得容易。

它提供了一个易于跟踪的系统，将活动产品与具有未发布特性的不太稳定的开发人员分支分离开来。

当我们团队的开发人员完成一个特性时，他/她会在GitHub上发送一个pull请求。这描述了请求的内容和详细信息。

此系统确保没有未查看的代码将与主分支合并。代码检查很重要，您需要正确的工具来完成它。

以下是我们的流程：

这是一个很好的控制版本和使每个人的工作完全透明的系统。Git有很多GUI扩展，比如支持Gitflow的GitKraken。在这里您可以看到如何轻松地启用它。

但是你如何决定代码是否足够好呢？

在下一部分中，我将向您展示跟踪代码质量的工具和可用于度量代码质量的度量。

1。可读和可理解代码的样式指南

样式指南是最佳实践和约定的集合。使用样式指南可以确保每个开发人员的代码看起来完全相同，从而使代码更易于检查和使用。

幸运的是，您不必创建自己的样式指南。有许多免费的样式指南，主要针对不同的编程语言和范围：

公司：像Airbnb和Google这样的酷公司已经创建并发布了他们自己的风格指南。这是Airbnb的JavaScript风格指南。

项目：公司内不同的项目或产品可能有不同的约定。我们并不推荐基于项目的风格指南，因为它使人们在项目之间切换变得更加困难。

使用linters自动测试代码样式

linter 是款式指南的一部分。它是一个小软件，可以自动检查代码是否符合预定义的代码约定规则。您不必手动检查代码库来检查样式。

几乎每种编程语言都有linter，仅举几个例子：

您也可以在这里查看我们自己的 JavaScript style guide here （尽管需要更新）。

3。通过功能测试提高代码质量

当使用linter的样式指南测试代码的外观时，功能质量测试显示代码是否实际工作。

这个简单的金字塔显示了一个测试过程的结构和你的努力方向。

一般来说，我们可以说您必须运行大量的单元测试，更少的集成测试，甚至更少的端到端测试。

通过单元测试，您可以通过模拟依赖项来检查软件的一个模块。集成测试显示了在端到端测试检查整个客户机-服务器循环时，不同组件如何协同工作。

对于运行单元和集成测试，可以使用以下工具：

对于端到端测试，我们建议使用：

附加阅读：Mobile Labs Inc在部署任何应用程序之前都会列出一个很酷的清单。

如何测量测试

衡量测试有效性的最佳方法是跟踪测试覆盖率。它显示了测试算法所覆盖的代码的百分比。为了更好地理解，有必要分解测试覆盖率：

Istanbul 尔是一个很酷的工具，用于测量JavaScript代码库的测试覆盖率。

用户界面测试

UI测试也可以自动化，但它需要更多的资源，特别是当组件正在更改时，因此应该重写完整的测试环境。

自动用户界面测试有很酷的应用程序：用于Android UI压力测试的Monkey测试、用于跨浏览器测试的Saucelabs和用于更全面的端到端测试（包括用户界面）的dragor。

使用持续集成工具

我们的理念是总是对我们正在构建的软件的状况有反馈。这就是图中的持续集成。我们最喜欢的博主之一，Martin Fowler，明确了持续集成的定义。

“持续集成是一种软件开发实践，在这种实践中，团队成员经常集成他们的工作，通常每个人至少每天集成一次，导致每天进行多个集成。每个集成都由自动化构建（包括测试）进行验证，以尽快检测集成错误。”

马丁·福勒

以下是我们的流程：

1. 持续集成平台将在代码上运行linter。如果失败了，这个过程将在此停止，开发人员必须修复与样式相关的问题。
2. 如果代码按照计划运行，它将运行功能测试并转到下一步。
3. 然后开始计算测试覆盖率。如果它不符合预定义的阈值，它将失败。
4. 如果请求正在与主分支合并，那么也应该部署它。

推荐工具：

后期代码质量

你真的不应该在产品上线后就放弃质量跟踪。诸如Sentry和Newrelic之类的工具可以实时监控错误，这样就不必要求用户 告崩溃和错误，因为系统会自动通知您。你只需要在你的应用程序中添加一小段代码。

工具：

案例研究

“我们认为，尽可能避免技术债务是最好的办法。通过代码审查，确保代码标准得到遵守，避免黑客攻击，您可以及早发现许多问题。

很明显，有时在项目的最后期限和里程碑到来时，你无法避免增加技术债务。那么最好把所有的事情都记录下来。我们保留一份文件，其中列出了所有问题，它们在哪里，为什么要这样做，以及哪些可能的措施可以解决这些问题。这样我们就可以跟踪我们在哪里看到的问题，以及什么时候它在我们的脑海里是新鲜的。

当涉及到提高代码质量时，它会根据具体情况工作。有时候你不得不接受一些永远无法解决的问题，在解决的时候记住它。其他时候，它可以被安排到未来的sprint中，以便在下一次需要查看该功能时进行修复。”

结论

就这样。这就是您如何为您的团队创建一个工作流，确保每个人的代码遵循相同的样式指南，并通过预定义的测试来检查功能质量。

除了在发布前测试代码质量之外，您还需要监视用户开始使用应用程序时发生的情况。

我们知道编写没有bug的代码是不可能的，但是遵循上面提到的过程肯定会提高团队代码的质量。

原文：
https://codingsans.com/blog/code-quality

讨论：请加入知识星球【首席架构师圈】或者微信圈子【首席架构师圈】