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.
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.
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.
- 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
Interested in working on a small team pursuing a number of great new practices like this?We’re hiring!