Code review!
A common practice in software projects is
peer code review. The general view is that code review helps identifying
potential bugs and enforcing a project’s coding standards. While I do
not disagree with this, I believe code review can mean much more for a
project and its team. Consider code review embraces four regions where
your, the reviewer’s, ability to learn and teach crosses technical and
domain knowledge.
Teaching + Programming: Code reviews gives you an excellent opportunity to share your programming knowledge with your peers. The goal here is not to show off the latest tricks you learned but to improve the skills of an another developer. You can actively contribute to a person’s growth as a programmer by providing valuable feedback. Coaching novices in a particular technology or introducing people into the specific practices of your project are just two ways of achieving this.
Teaching + Domain: Most software projects built in teams are characterized by a non-trivial domain. A non-trivial domain requires a significant amount of modeling to represents its behavior and attributes in code. Since the modeled behavior and attributes are inseparable of the code it seems more than reasonable for the domain aspect to be included in a code review. The reviewer can play a significant role in overall domain modeling by thinking along.
Learning + Programming: Reviewing code exposes developers to different ways of solving problems. Observing and understanding code written by other programmers is an effective way to ameliorate your coding style and techniques, get to know new libraries and learn patterns. Moreover, it provides inspiration for solving problems yet to come and ideas for improving existing code.
Learning + Domain: The information captured in the code makes it a primary resource for learning about domain concepts and the overall functionality. Code is de facto the most detailed documentation of a software system. Reading it with comprehension extends the understanding of a system beyond the parts one was involved implementing.
Most developers will move between the code review regions as they become better programmers and learn more about certain domains. While some will have the opportunity to learn more often; others will frequently fulfill the teaching role. If a developer is new to the technology used in a project, but an expert in the domain, he might have two roles. In some cases the reviewer will find himself in the four regions at once. The advantage of recognizing these regions is that doing a code review is always valuable regardless of the reviewer’s seniority level.
Expanding your regular code review to the fours regions described above can contribute to your project and team by:
Teaching + Programming: Code reviews gives you an excellent opportunity to share your programming knowledge with your peers. The goal here is not to show off the latest tricks you learned but to improve the skills of an another developer. You can actively contribute to a person’s growth as a programmer by providing valuable feedback. Coaching novices in a particular technology or introducing people into the specific practices of your project are just two ways of achieving this.
Teaching + Domain: Most software projects built in teams are characterized by a non-trivial domain. A non-trivial domain requires a significant amount of modeling to represents its behavior and attributes in code. Since the modeled behavior and attributes are inseparable of the code it seems more than reasonable for the domain aspect to be included in a code review. The reviewer can play a significant role in overall domain modeling by thinking along.
Learning + Programming: Reviewing code exposes developers to different ways of solving problems. Observing and understanding code written by other programmers is an effective way to ameliorate your coding style and techniques, get to know new libraries and learn patterns. Moreover, it provides inspiration for solving problems yet to come and ideas for improving existing code.
Learning + Domain: The information captured in the code makes it a primary resource for learning about domain concepts and the overall functionality. Code is de facto the most detailed documentation of a software system. Reading it with comprehension extends the understanding of a system beyond the parts one was involved implementing.
Most developers will move between the code review regions as they become better programmers and learn more about certain domains. While some will have the opportunity to learn more often; others will frequently fulfill the teaching role. If a developer is new to the technology used in a project, but an expert in the domain, he might have two roles. In some cases the reviewer will find himself in the four regions at once. The advantage of recognizing these regions is that doing a code review is always valuable regardless of the reviewer’s seniority level.
Expanding your regular code review to the fours regions described above can contribute to your project and team by:
- making the code the property of all developers in the team – As developers we like to feel at home in a codebase. Reviewing code switches the code ownership from the author to the team and turns it to a common good. It makes the whole team responsible for the code quality and enables any team member to introduce changes. This is also related to shared code (or collective code ownership) in Extreme Programming.
- gradually improving developers’ programming skills – Peer review will raise the average skill level of a team. Furthermore, it introduces a subtle pressure which motivates developers to write their best code.
- spreading domain knowledge – Understanding the functionality captured in the code helps spreading the knowledge about the whole system between all team members. It makes the team more confident as a whole, enables any developer to work on any part of the system which as result makes story “cherry-picking” less likely to happen.
- fostering collective intelligence – The quality a team can achieve together is greater than the sum of what developers could achieve when working alone. Every developer brings different skills to the table and ideally a team achieves programming synergy by picking everyone’s best qualities.
No comments:
Post a Comment