Code Review on Android Projects

Code Review is a tedious process sometimes, but I believe that we need to spend more time on that. Maybe it is an opportunity for you to learn or share some knowlegde.
I listed some points that I consider necessary to check in a Code Review process on Android Projects.

Transcript

1. Code Review on Android Projects DG Conference Week Created by Gabriel B. Moro - moro@devgrid.co.uk
2. Summary • Performance • Aesthetics • Dirt Code • Accessibility • Dangerous Code
3. Performance
4. Memory-leaks
5. Deep Layouts
6. Deep Layouts
7. Deep Layouts
8. Aesthetics • Names of files, variables, methods, classes… • File locations… • Java blood
9. Dirt Codes • Unused imports • Unused resources like drawables, strings, colors, and so on • Commented code
10. Accessibility
11. Dangerous Code
12. Architecture Violation
13. Similar Components
14. Danger Code Zones The danger code is the code that the reviewer looks at the first moment and says: “This code doesn’t make any sense” or “Nothing uses this code”
15. Automated Code Review - Advantages • You can use in public repositories that you have; • You can have your repository rated according to your code quality Disadvantages • Need to share your code with Codebeat; • It is not effective to check XML files.
16. Automated Code Review - Codebeat
17. Automated Code Review - Codebeat
18. Supported Languages - Codebeat
19. Conclusion A good tip is to have your checklist to make your code reviews better.
20. Useful Links • Code Review on Android Projects