Did you know that Android Studio has static code analysis built in? You can run this tool using theinspect code dialog. When launched you can specify what you want to analyze; your whole project, individual modules, or just a directory.

Fire it up and go fix a snack and prepare a warm beverage, it will take a few minutes to run. The results will start to be populated and categorized within an“检查结果”window. You could potentially see a lot of groups, let’s focus on; Android, Kotlin, Java, XML. Each of these groups has organized rule sets and displays the list of files that violate them.

For example, if we had layouts that used left/right instead of start/end. They would appear in the section Android -> Lint -> Internationalization -> Using left/right instead of start/end attributes.

As you dig into each file you will see that sometimes Android Studio is able to resolve the issue and offers a fix option in addition to suppression.

That’s really powerful! You may be tempted to get started fixing a whole bunch of things! Wait a moment though, it’s not as easy as you think.

不是那么快！

我们需要在这是如何完成的，以便最大限度地减少风险并维持开发人员理智。我们不想引入错误，或者因为有意变化而不得不推出一个修补程序。同样，我们希望保持我们的更改大小，因此在审查我们提交的任何更改后，我们的同行仍将成为我们的朋友。

Changes of Appropriate Size

Keeping your changes per pull request appropriately sized will go a very long way in minimizing risk and keeping our peers sane. A good start is keeping them as small as possible. This allows the reviewer to scrutinize the changes in greater detail and hopefully catch any issue if present. This is especially important if the changes are high risk and/or the modification is hand done.

有时允许更大的变化。例如;删除未使用的导入。我们真的不希望这遍布许多更改请求。如果这触摸了大量文件并且大于正常的情况，则可以是可以的，因为它的风险很低。我们只是删除未使用的导入，并且可能依赖于Android Studio修改文件。188博金宝电子体育频道

Group Like Changes Together

有助于最大限度地减少风险的一个非常伟大和简单的技术是将更改的变化组在一起。它使审阅者更容易发现任何问题，因为所有的变化都应该相似。

If the changes are small and you don’t want to make separate change requests then you can organize your changes across commits.

Test It Out

We need to test out our changes and make sure we haven’t broken anything in the application. Performing some due diligence here will go a long way in helping to minimize the risks. Keeping our changes appropriately sized and grouped together will help us identify a problem faster if something goes wrong.

Effectively Communicate Changes

Summarizing and explaining your changes in the pull request will help the reviewer understand what they are reviewing and why. If you are particularly concerned, it’s always good to say so.“这种变化was refactored by hand, would you mind looking it over thoroughly?”

Merge Changes After A Release

We should consider when we submit our changes for inclusion. To help minimize risk we shouldn’t do this before a release. Ideally, we should aim to have our changes merged soon after our production build has been pushed. That will give us the most amount of time to test our changes before the next release.

Be Patient

我们询问我们同事的巨大青睐，审查这段代码。他们无疑会有疑问。耐心，倾听您的同事的担忧，并回答他们可能拥有的任何问题。您可能必须恢复一些良好的更改或与队友进一步迭代。这是过程的所有部分，都是预期的。尽力而为，并始终试图依靠最小化风险。

理解风险

Understanding the risks and minimizing them will help reduce the chances of introducing bugs. Our changes and their impact on the code base needs to be understood for us to effectively assess that risk. Once we know that, we can apply the techniques above to help minimize those risks.

You will break things, be prepared to fix them and own up to any issues found.

To Summarize:

• 变化应该是适当的大小
• Group like changes together
• Test It Out
• 有效地与您的团队沟通
• 发布后合并您的更改
• Be patient
• Understand the risk and minimize for it

为什么我喜欢它

It’s a choose your own adventure style story where you can decide your path whatever that may be for a day. Want something easy and straightforward? Pick a low risk issue that is easily understood. Want a challenge? Dig for esoteric issues that require architecture changes. Maybe, you discover a utility class that lacks test coverage. Adding in unit tests for that utility could also be the adventure!

最终结果将不仅仅是棉绒警告的简单减少。您的旅程将把您所有人带到代码基础，以至于您永远不会期待的地方。您可能会发现自己以前从未查看过的子系统或文件。您还将在代码审核期间了解问题的类型并应用这些知识。

We become and help others to become better programmers by finding and fixing issues.

Some Issues To Check Out

现在，我们通过为您继续旅程提供一些起始地点，我们涵盖了最大限度地减少风险的策略。以下是可以自动纠正的一些常见问题的小清单。快乐狩猎！

1)班级会员可以有私人能见度 -This inspection catches when we can make our instance variables or functions private. They can be found in theInspection Report

Kotlin -> Style Issues -> Class member can have private visibility

2)可能是'const'- 此检查捕获了可宣称为Const的顶级Val。他们可以在Inspection Report

Kotlin -> Style Issues -> Might be ‘const’

3)Remove redundant qualifier name— This inspection catches redundant qualifier name usage. For example referencing something using a fully qualified name may not be necessary due to a static import. They can be found in theInspection Report

Kotlin -> Redundant Constructs -> Remove redundant qualifier name

我希望你喜欢这篇文章，请随时与我联系Twitter.

Interested in working on a small team pursuing a number of great new practices like this?We’re hiring!

最初出版//www.bizviewz.com2020年5月18日。