Comparison of code review techniques
I think many developers are familiar with the concept of code review or code review in Russian (this term is also translated as code review, code inspection or code review - further, the “code review” option will be used for consistency). Recently, I was faced with the need to "sort through" and classify knowledge on this topic. The result is this article. I hope it will be useful, as well as help to introduce code reviews into its production process to those who only think about it.
Code review is one of the most effective methods for finding and eliminating program defects. Reviews are conducted by humans, which allows finding a wide class of errors, including those that are difficult to detect or are not detected at all by automatic means. Of course, the review of the code does not cancel the use of code analyzers or other methods of error detection, for example, unit-testing. Unfortunately, there is no method that alone would ensure the detection of all program defects (in studies, the effectiveness of code review is usually estimated at 30-50% of detected errors in the application).
Finding errors is not the only task of reviewing code. In addition, the review of the code has several positive properties:
You have to pay for all this with the time that could be spent on coding. Nevertheless, on projects designed for at least some prospect, the time spent in the future will return a hundredfold due to the creation of an initially high-quality product, instead of a convulsive “dopilka” later.
The following types of code reviews can be distinguished:
')
Consider each option separately.
A formal code inspection is, as the name suggests, a formalized code review procedure. According to McConnell, it looks like this.
The inspection coordinator designates the date of the inspection meeting and inspectors, who must independently examine the inspected code fragment before the meeting. At the appointed time, the coordinator of the inspection, the secretary, the author of the code and the inspectors gather. Some of the inspectors or the supervisor begin to read the code line by line (for convenience, it is advisable to print it in advance along with the line numbers). The inspectors point out the problems they found, the author of the code answers the questions of the inspectors - if everyone agrees that there is a mistake, the secretary writes it down. The coordinator of the inspection monitors the process as a whole, for example, so that discussions of one error are not delayed. Upon termination of inspection the report with its results is formed.
A more detailed example of a formal inspection can be found here .
Informal inspection, unlike formal inspection, does not have clear rules. For example, this may happen as follows: the author of the code, before publishing it, calls the first developer to his computer, where he shows and tells what he wrote. The examiner tries to grasp into what is written, asks questions and expresses his thoughts. Of course, with this method, the efficiency will not be very high, but such an inspection takes little time.
Reading a code is an independent study by a developer of someone else's code without the presence of the author. This practice is the simplest and most common of those described here - I think that any developer somehow came to read someone else's code. Not to mention the world of Open Source, where it is often the only available method for reviewing code.
Pair programming is an extreme method of reviewing code — a review that is carried out constantly: two developers behind one computer, behind one set of mouse and keyboard, together solve one problem. Widespread pair programming received after the emergence of the methodology of extreme programming, although actively used before. Often, pair programming is used spontaneously: I think many had to approach another developer behind a computer to help solve a complex task.
I want to add a few words to the above. As you can see some disadvantages stem from the merits. This is not surprising - the pair programming method is not simple enough, as it may seem at first glance, and not all its properties are obvious. Therefore, starting to work in pairs, do not expect instant results. Only after gaining some experience, pair programming will begin to bear fruit, and moreover, it will be possible to minimize some of the negative effects.
Now you can try to decide which method and in which case should be used.
As you can see, there are enough options - you can choose the most suitable method for yourself. In addition, no one forbids combining techniques (for example, one part of the team works in pairs, the other part alone, but the code written by them is necessarily inspected). You can start with simpler methods and gradually move to complex ones - the main thing is to start, and I think, positive effects will not keep you waiting.
Code review is one of the most effective methods for finding and eliminating program defects. Reviews are conducted by humans, which allows finding a wide class of errors, including those that are difficult to detect or are not detected at all by automatic means. Of course, the review of the code does not cancel the use of code analyzers or other methods of error detection, for example, unit-testing. Unfortunately, there is no method that alone would ensure the detection of all program defects (in studies, the effectiveness of code review is usually estimated at 30-50% of detected errors in the application).
Finding errors is not the only task of reviewing code. In addition, the review of the code has several positive properties:
- The application architecture is improved due to the fact that at least 2 people thought out every part of the system.
- The programmer is initially motivated to write better code, knowing that it will be viewed.
- Spread the knowledge of the project among the team.
- There is an exchange of programmer experience.
- A uniform coding style is developed in the team.
You have to pay for all this with the time that could be spent on coding. Nevertheless, on projects designed for at least some prospect, the time spent in the future will return a hundredfold due to the creation of an initially high-quality product, instead of a convulsive “dopilka” later.
The following types of code reviews can be distinguished:
')
- Formal code inspection.
- Informal code inspection (also called code analysis).
- Reading code.
- Pair programming.
Consider each option separately.
Formal code inspection
A formal code inspection is, as the name suggests, a formalized code review procedure. According to McConnell, it looks like this.
The inspection coordinator designates the date of the inspection meeting and inspectors, who must independently examine the inspected code fragment before the meeting. At the appointed time, the coordinator of the inspection, the secretary, the author of the code and the inspectors gather. Some of the inspectors or the supervisor begin to read the code line by line (for convenience, it is advisable to print it in advance along with the line numbers). The inspectors point out the problems they found, the author of the code answers the questions of the inspectors - if everyone agrees that there is a mistake, the secretary writes it down. The coordinator of the inspection monitors the process as a whole, for example, so that discussions of one error are not delayed. Upon termination of inspection the report with its results is formed.
A more detailed example of a formal inspection can be found here .
Advantages:
- Very high efficiency.
- Thanks to the compiled list of errors, it is easy to check their elimination.
- Inspection reports can be used further, for example, to analyze common problems.
Disadvantages:
- Complex formal procedure that requires time.
- Distract at least 3 people (coordinator, author of the code and the inspector) from their main work.
- Great psychological pressure on the author of the code.
Informal code inspection
Informal inspection, unlike formal inspection, does not have clear rules. For example, this may happen as follows: the author of the code, before publishing it, calls the first developer to his computer, where he shows and tells what he wrote. The examiner tries to grasp into what is written, asks questions and expresses his thoughts. Of course, with this method, the efficiency will not be very high, but such an inspection takes little time.
Advantages:
- Small time consumption.
- A simple process that does not require formal procedures.
Disadvantages:
- Low efficiency due to superficial acquaintance of the verifier with the code.
- To check, you have to distract someone from the main work, which can be very annoying.
- Criticism of the code can be badly perceived by the author, and both reasonably (for example, due to insignificant quibbling of the verifier) and unreasonably (for example, it is difficult for the author to admit his mistakes).
Code reading
Reading a code is an independent study by a developer of someone else's code without the presence of the author. This practice is the simplest and most common of those described here - I think that any developer somehow came to read someone else's code. Not to mention the world of Open Source, where it is often the only available method for reviewing code.
Advantages:
- Simplicity.
- High availability - no time and space synchronization required.
Disadvantages:
- Slow feedback - you may need additional comments on the code that cannot be obtained quickly, and sometimes it is even faster to correct the defect yourself than to inform the author.
Pair programming
Pair programming is an extreme method of reviewing code — a review that is carried out constantly: two developers behind one computer, behind one set of mouse and keyboard, together solve one problem. Widespread pair programming received after the emergence of the methodology of extreme programming, although actively used before. Often, pair programming is used spontaneously: I think many had to approach another developer behind a computer to help solve a complex task.
Advantages:
- High efficiency, especially in terms of sharing experience and spreading knowledge about the project.
- High concentration at work - working in pairs, developers are much less distracted by extraneous things.
- The natural limitation of the number of tasks simultaneously developed by the team - focusing on a smaller number of tasks ensures their better and faster implementation, which allows you to continuously deliver new versions of the product.
- There are no psychological issues inherent in inspections - both authors of the code, and both are his inspectors at the same time, suggestions for improvement are perceived as proposals, not criticisms.
- Enhancing team spirit - the success achieved in a pair unites people more than individual achievements.
- Great for learning newbies.
Disadvantages:
- The fall in overall performance, two programmers are busy with the same task, instead of developing two tasks - this statement is quite controversial, according to several studies, programmers working in pairs have only 15% less performance than two programmers working separately.
- Work schedule synchronization is required - it is difficult to work in pairs when partners go to lunch or come to work at different times.
- Hanging fatigue due to the constant high concentration at work - for programmers working in pairs, it may even make sense to make the working day less than the standard 8 hours.
- Not all people are compatible, and some are not even able to work with someone together. In fact, there are quite a few such people and most of the problems of interaction in a couple can be overcome by following a number of rules ( for example ), as well as with the accumulation of experience in working with a couple.
- Inefficient to perform routine tasks - in this case, the developer who does not own the keyboard will simply be bored.
- It is difficult to synchronize the pace of developers, the level of experience and knowledge of which varies greatly - to work effectively from a more experienced developer requires patience and some mentoring skills.
I want to add a few words to the above. As you can see some disadvantages stem from the merits. This is not surprising - the pair programming method is not simple enough, as it may seem at first glance, and not all its properties are obvious. Therefore, starting to work in pairs, do not expect instant results. Only after gaining some experience, pair programming will begin to bear fruit, and moreover, it will be possible to minimize some of the negative effects.
What to choose?
Now you can try to decide which method and in which case should be used.
- If you decide to do reviews of the code, but do not want to bother much on this, then for the team located in one place, informal inspections will be the best choice.
- For a distributed command, virtually the only available method of review is reading the code . Despite the fact that there are systems for remote pair programming, purely for psychological reasons, they are not as comfortable as programming with one computer. In addition, reading the code can be practiced in unallocated teams, but when there is a choice to guess about the appointment of a piece of code or ask the author about it, I would choose the latter.
- Formal inspections are excellent for reviewing complex or critical sections of code - in this case, the time costs are more than worth the result. Some practice the constant use of formal inspections, but it’s hard for me to imagine how formal inspections can conduct a review of all the code available.
- Pair programming is not in vain one of the principles of extreme programming. Its high efficiency and additional bonuses inherent only in this type of review of the code really allow to recommend it as the main way of development in a team (with the exception of simple or routine tasks). Optimism is added by the fact that most of the shortcomings can be successfully tackled. The biggest problem may be an attempt to persuade management to use such a wasteful, in their opinion, method - here you can be helped by books and articles of practitioners of extreme programming.
As you can see, there are enough options - you can choose the most suitable method for yourself. In addition, no one forbids combining techniques (for example, one part of the team works in pairs, the other part alone, but the code written by them is necessarily inspected). You can start with simpler methods and gradually move to complex ones - the main thing is to start, and I think, positive effects will not keep you waiting.
Literature
- Perfect code (Code complete). Steve McConnell. Chapter 21. Co-construction.
- Extreme programming: setting the process. From the first steps to the victorious end (Extreme Programming Applied: playing to win). Ken Auer, Roy Miller (Ken Auer, Roy Miller). Chapter 14. We stop working alone.
Source: https://habr.com/ru/post/151450/
All Articles