Building software is a complex task. Some software is built by a single person, but often times there are teams behind software. These teams can range from two people up to hundreds of people. Working with many people in the same code-base brings quite a few challenges. Tools like git help out with working in parallel by enabling us to version our code (i.e. see changes over time) or to easily spot changes suggested by team members. But the more people are working on the same code-base, the more changes are being suggested — and these changes need to be reviewed by someone.
构建软件是一项复杂的任务。 某些软件是由一个人创建的，但通常情况下，背后都有团队。 这些团队的人数从两个人到数百人不等。 在同一个代码库中与许多人一起工作会带来很多挑战。 git之类的工具通过使我们能够对代码进行版本控制(即查看随时间变化的内容)或轻松发现团队成员建议的更改，来帮助并行工作。 但是在同一代码库上工作的人越多，建议的更改就越多-这些更改需要由某人进行审查。
To ensure a consistent code quality, code review is a core part of a software engineer’s day. There are multiple aspects when reviewing code — more visual ones like conforming to a commonly defined code style (formatting, indentation, braces, …) but also logical aspects like the correctness of the code, usage of architecture patterns, performance, and more. To reduce the workload that reviewing code puts on the team, we can automate parts of the code review process. In the following we will take a look at adding automation to our code reviews with a focus on code style and static code analysis. The examples will be based on Kotlin (in an Android app) — but they are applicable to other projects as well, for example Swift, Dart or others.
为了确保一致的代码质量，代码审查是软件工程师时代的核心部分。 审阅代码时，有多个方面–更直观的方面(如遵循共同定义的代码样式)(格式，缩进，花括号等)，还有逻辑方面(如代码的正确性，体系结构模式的使用，性能等)。 为了减少审查代码给团队带来的工作量，我们可以使部分代码审查过程自动化。 在下文中，我们将着眼于在代码审查中增加自动化，重点是代码样式和静态代码分析。 这些示例将基于Kotlin (在Android应用程序中)-但它们也适用于其他项目，例如Swift，Dart或其他项目。
Working in a team means that decisions are made as a team. These decisions can be related to workflows, software architecture or just about the commonly used code style. Some of these decisions can be incorporated into the daily workflow — for example into the IDE via .editorconfig for formatting, or a commonly shared code style file that can be imported into the IDE. Many other decisions can’t be included and instead must be documented somewhere to keep track of them. This allows existing team members as well as new joiners to understand what decisions have been made by the team, and to adjust to them.
团队合作意味着团队决策。 这些决定可能与工作流程，软件架构有关，也可能与常用的代码样式有关。 这些决策中的一些可以合并到日常工作流程中，例如，通过.editorconfig格式化以集成到IDE中，或者可以导入到IDE中的通用共享代码样式文件。 许多其他决策无法包括在内，而必须记录在某处以跟踪它们。 这样一来，现有团队成员和新加入者就可以了解团队做出了哪些决定并进行调整。
Taking decisions and writing them down is only one part though — these decisions need to be followed. This requires the team to be aligned and work into the same direction. Everyone on the team needs to be aware of them and willing to follow them. It’s easy to forget about certain things as well, and code review is usually the place where people are reminded of these things.
不过，做出决定并将其写下来只是一部分-需要遵循这些决定。 这就要求团队团结一致，朝着同一个方向努力。 团队中的每个人都必须意识到他们并愿意跟随他们。 同样容易忘记某些事情，并且代码回顾通常是提醒人们这些事情的地方。
With a growing team and a growing number of pull requests (or merge requests), time spent in code review also grows. There have been many pull requests with most of the comments regarding code style or certain things that have been decided and written down before — just because someone was not aware of them or forgot about it. This costs a lot of time: Reading the code, focusing on the code style, spotting issues, writing comments which then are addressed. Often times issues are duplicated, resulting in duplicated comments and review work.
随着团队的不断壮大和拉取请求(或合并请求)数量的增加，花在代码审查上的时间也增加了。 有很多请求请求，其中大多数是关于代码样式的注释，或者是某些之前已经决定并写下的某些事情的注释–只是因为有人不了解或忘记了它们。 这会花费大量时间：阅读代码，关注代码样式，发现问题，编写注释，然后加以解决。 通常情况下，问题是重复的，导致重复的评论和审查工作。
Lets take a look at how this can be automated.
让我们看一下如何将其自动化。
The tools we will be using are:
我们将使用的工具是：
DangerJS
DangerJS
Danger Plugin: Lint Report
危险插件：Lint报告
DangerJS is the backbone of the setup, it will be triggered for each pull request and run a couple of checks on the changes.
DangerJS是设置的基础，它将为每个请求请求触发，并对更改进行两次检查。
Danger runs during your CI process, and gives teams the chance to automate common code review chores.
危险在您的CI流程中运行，使团队有机会自动执行常见的代码审查琐事。
By writing a JavaScript file we can write a simple script that accesses the pull request (and its meta-data) and executes checks.
通过编写JavaScript文件，我们可以编写一个简单的脚本来访问拉取请求(及其元数据)并执行检查。
An example — checking if a pull request modifies a changelog file (CHANGELOG.YML):
一个示例—检查拉取请求是否修改了CHANGELOG.YML日志文件( CHANGELOG.YML )：
If the author didn’t add the changes to the changelog (or technically: if there was no modification of the changelog file in the pull request), a review comment will be posted.
如果作者未将更改添加到变更日志中(或者从技术上说：如果在请求请求中未对变更日志文件进行修改)，将发表评论。
This alone is a quite powerful tool that can reduce the amount of time required for code review. It can be extended to fit certain workflows — for example making sure that the software version is increased before a release or to post warnings if business critical parts of the code-base are being touched.
仅此一项是一个非常强大的工具，可以减少代码检查所需的时间。 可以扩展它以适合某些工作流程-例如，确保在发行前增加软件版本，或者在碰到代码库的关键业务部分时发出警告。
DangerJS has full access to the checked out commit — both the source directories as well as the build output. This allows us to execute a couple of steps before triggering DangerJS in our pipeline, and to utilize the results.
DangerJS具有对检出的提交的完全访问权限-源目录以及构建输出。 这使我们能够在触发管道中的DangerJS之前执行几个步骤，并利用结果。
Our goal is to automate parts of the code review process — especially the ones that are focused more on code style issues. So we will embed a linter and static code analysis into the pipeline.
我们的目标是使部分代码检查过程自动化，尤其是那些更加专注于代码样式问题的部分。 因此，我们将一个lint和静态代码分析嵌入到管道中。
Looking at a Kotlin code-base, the linter of our choice will be ktlint. For static code analysis we will be using detekt.
看一下Kotlin代码库，我们选择的lint是ktlint 。 对于静态代码分析，我们将使用detekt 。
ktlint will make sure that the formatting of our code stays consistent — we follow the same indentation rules, variable naming, braces and much more. This will ensure that different parts of the code-base can be read in the same way and thus it’s easier to switch between them.
ktlint将确保我们的代码格式保持一致-我们遵循相同的缩进规则，变量命名，花括号等等。 这将确保可以以相同的方式读取代码库的不同部分，从而更容易在它们之间进行切换。
detekt will keep the code complexity low. It contains rules about concurrency usages, performance optimizations and general code structure.
detekt将使代码复杂度降低。 它包含有关并发用法，性能优化和常规代码结构的规则。
To add both ktlint and detekt to our pipeline, and to enable DangerJS to use their reports, we need to enable XML reports. The DangerJS plugin is able to read checkstyle-formatted reports — meaning it is not limited to ktlint and detekt, but it can also read SwiftLint or other linters’ reports.
为了将ktlint和detekt都添加到我们的管道中，并使DangerJS使用它们的报告，我们需要启用XML报告。 DangerJS插件能够读取checkstyle格式的报告，这意味着它不仅限于ktlint和detekt，而且还可以读取SwiftLint或其他linters的报告。
This example will be using GitHub actions to execute the CI pipeline — since DangerJS will be working closely with the pull requests, GitHub actions bring the benefit of supplying a GitHub actor and token out of the box.
该示例将使用GitHub操作执行CI管道-由于DangerJS将与拉取请求紧密合作，因此GitHub操作带来了开箱即用提供GitHub actor和令牌的好处。
The workflow for DangerJS on GitHub Actions looks like this:
GitHub Actions上DangerJS的工作流程如下：
This will install Danger and trigger it on pull requests. DangerJS will look for the configuration file (Dangerfile) and execute it. This could be used with the changelog modification script posted above.
这将安装Danger并在请求请求时触发它。 DangerJS将查找配置文件(Dangerfile)并执行它。 可以与上面发布的changelog修改脚本一起使用。
The next step is to add the lint report plugin. Since it’s a different package, we’ll need to install it in the workflow as well.
下一步是添加皮棉报告插件。 由于它是一个不同的软件包，因此我们也需要将其安装在工作流程中。
Now we can adjust our DangerJS configuration (Dangerfile) and include our ktlint reports:
现在，我们可以调整DangerJS配置(Dangerfile)并包含我们的ktlint报告：
The last thing for us to do is to add ktlint to our GitHub Action. Since the lint reports are not committed, and thus not added to the repository, the file search for **/reports/ktlint/*.xml would not find any reports — and subsequently not be triggered.
我们要做的最后一件事是将ktlint添加到我们的GitHub Action中。 由于没有提交皮棉报告，因此也没有将它们添加到存储库中，因此对**/reports/ktlint/*.xml的文件搜索将找不到任何报告，因此不会被触发。
The updated workflow file with a step to execute ktlint before Danger:
更新的工作流程文件，其中包含在危险发生之前执行ktlint的步骤：
Opening a pull request will now trigger ktlint and then DangerJS — which will use the plugin we installed to scan for ktlint reports, parse them, and post issues that were created in this pull request as review comments.
现在，打开一个请求请求将先触发ktlint，然后触发DangerJS-它将使用我们安装的插件扫描ktlint报告，解析它们，并将在此请求请求中创建的问题发布为评论。
The full Android setup, with ktlint, detekt and Android Lint would have a GitHub workflow triggering each of them:
完整的Android设置(带有ktlint ， detekt和Android Lint)将具有一个GitHub工作流来触发它们：
With the following Dangerfile:
使用以下危险文件：
The result is that the team members no longer have to keep an eye out for mundane things like code style during the code reviews. This will save a lot of time long-term and ensure that the team’s own best practices are being followed.
结果是团队成员不再需要在代码审查期间留意诸如代码样式之类的世俗事物。 这将节省大量的长期时间，并确保遵循团队自己的最佳实践。
To continuously improve this setup the rule-sets of each of these steps can be adjusted to perfectly fit the team’s desires. The next step would be to write custom rules (for each of these) to automate not just the code style decisions made by the team, but also rules about for example concurrency (in Kotlin this could be rules about Coroutine scope or context usages) or other more complex topics.
为了不断改进此设置，可以调整每个步骤的规则集以完全符合团队的需求。 下一步将是编写自定义规则(针对每个规则)，以不仅使团队做出的代码风格决策自动化，而且使有关并发性的规则(在Kotlin中可以是有关协程范围或上下文用法的规则)自动化或其他更复杂的主题。
https://twitter.com/damian2048
https://twitter.com/damian2048
翻译自: https://proandroiddev.com/automating-code-reviews-f586f2281a2e