This is a quick post about code review best practises notes which I took while watching this amazing talk 11 Best Practices of Peer Code Review-Full by Jason Cohen.
Here is a quick summary about some of those code review important points.
The ego effect: knowing that someone is going to review the code, makes any developer to think carefully about code principles of the team. Think twice before commit code as done. Which makes a huge difference on code quality for the project.
Talk about code: Do not spec or have long meetings. Just speak about code it makes it easier to understand the use case and solutions. Spec and meetings should only present the main overall issue to be solved. How to solve it, should be done by code or pseudo-code.
Learning: By doing reviews, developers learn a lot. Reviewers are members of the same team, for different tasks. Jason recommends to do only about 200 lines of code review per hour, in order to be an efficient reviewer.
Author preparation code: While developing a solution, make code readable and self explanatory, add comments if necessary, but is better to write self explanatory names, even they are long. As recommended by uncle Bob, Robert C. Martin in his, must read, book Clean code. In any way thinking about names and how to explain the code, makes the developer to think more carefully about what he/she is doing.
Tests: Create and run unit tests coverage only for correctness of the code, it means see if the code works. Then focus on code review for all the "...ilities", readability, maintainability, etc... Running tests is not enough to ensure good quality code.
The flow: Development process needs to make place for inter code review practises between team members. Team members needs to understand why and how of the code review. If not, the quality of code reviews can do so low that it is now worth of its time.
As I see, from a Kanban point of view, the board should have task of new functionalities as well as code review tasks. The developers pull tasks as their own path. Allowing them to choose when they feel good for doing code review efficiently.
A big part here is to modularise tasks to avoid conflicts. Code modularisation becomes a very important issue here, in order to make the working flow smooth and easy.
What do you think? Are you already doing code reviews?
Posted by Marc Andreu.
No comments:
Post a Comment