Code Review: A problem to solve
If you work for a software team, you may face a crucial problem at the end step of coding: How can we be sure this code is clean enough to go for the next steps? This is a situation, that we have not decided to push and merge our code to the ‘develop’ branch of the system yet. We need something before testing and the definition of done evaluations. Some people like to mention “Clean Code” and the first problem will come to us after this thought is the demand to ask someone to check the code to evaluate to what extent the implemented code is clean! If you are thinking about an internal obstacle for an agile team named the “Code Review” step in SDLC (it looks a bit mysterious), you are right! I want to talk about this silo and try to minimize or remove its consequences on developing efforts.
Consider a team with several developers who can serve each other in reviewing codes. At first glance, it sounds good to divide reviewing among them to keep the speed of the team in producing codes in local branches and put generated codes in the main branch of development with the lowest amount of delay. But (Always there is a ‘but’!) how about the different levels of knowledge, experience, and attention? We are working with people who are diverse, their knowledge is variant, and even their mood is different on a regular day of the week! How can we guarantee this approach will produce sustainable codes?
How about a gateway? The Scrum Guide emphasizes that there is just one PO for the Scrum team not a committee of them. A shiny effect comes to our minds from this idea: making just one person accountable for reviewing codes! Fortunately this flash will end immediately with this question: Who is accountable for being this technical gateway? Team Leaders? Senior Developers? Who is the right person that we can trust on this? And why we should try to find these heroes?! Do they exist outside of movies or TV shows? Nobody wants to pick this responsibility in reality! Trust me! We absolutely need something to help them to make it systematic or heuristic. I believe it is a team-level deal called “Team Agreement” and at the heart of it, the code review principles should be embedded!
Let’s this time leave agile stuff and focus on code review principles (definitely they come from the agile ways of working but this time I am focused on Tech stuff). For instance, let's have a quick look at the SOLID principles. The SOLID Principles are five principles of Object-Oriented class design. They are a set of rules and best practices to follow while designing a classes structure. Where do they come from? As I mentioned above from several agile pioneers like Uncle Bob!
Let’s look at each principle one by one. Following the SOLID acronym, they are:
- The Single Responsibility: A class should do one thing and therefore it should have only a single reason to change.
- The Open-Closed: Classes should be open for extension and closed to modification.
- The Liskov Substitution: Sub-classes should be substitutable for their base classes.
- Interface Segregation: Many client-specific interfaces are better than one general-purpose interface. Clients should not be forced to implement a function they do not need.
- The dependency Inversion: Our classes should depend upon interfaces or abstract classes instead of concrete classes and functions.
Do you want to know about them more? So, read this article:
You are not following object-oriented anymore? It’s OK. Find the ones, that work like principles for your code style (it is easy, we are living in the ChatGPT age!) and put it in your Team Agreement with developers. You just need to find a way to have more cohesion and less coupling in your codes. Now, things seem better. Everyone can review the code and there is no single source of the failure (I mean superheroes!) anymore! Let’s drop the Review column from our Kanban board though! What about the checking logic? I believe it doesn’t matter. Let’s take care of them with Unit tests.
Good Luck! Agility is finding the job to be done!
See the Persian version:
