Code Review on Android Projects - Part III - Final Part

Continuing the previous post ...

Eliminate "Java blood''

Kotlin and Java are good friends. Sometimes in the Android world, we create a Kotlin code with Java blood. I mean that we can explore Kotlin scope functions in our code, for example functions as apply, also, let, run and with. There are a lot of other resources that Kotlin provides to reduce the boilerplate code when we are working with collections as well.

Similar components

Sometimes we have in our project more than one component that has the same responsibility. We need to check how we can customize this component to remove the duplicated codes. 

For example, we have in our project a custom TextView component that shows a link with a text using SpannableString. We need to implement a new feature to show a green link with a text, something like the component does but using a green color. What do you prefer to do?

In my mint, I don't need to create the same component. I would customize the existing component to receive a color to the link. Imagine if in our project we have:

• Component X does Y
• Component Z does Y
• Component A does Y

Imagine if the Y behavior change, you need to change it in all components, the maintenance is hard.

Danger code zones

If you have a sensitive code, I like the expression danger zone, that describes better this situation. 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.

In some cases, when you are looking for the method calls, a method is not called. But in runtime, if there is an annotation, for example, the method can be called by reflection.

Conclusion

My last tip is to have a checklist to improve the quality of your code reviews. You also can track better all of the points that you consider important to check in a code review process.

If you have tips, please let them as a comment here. Thanks : )