20 reasons to conduct code reviews
(approx. transl. Translation is a little free, but I tried to keep the meaning of the text as accurate as possible, while at the same time playing on some non-critical points, please do not judge strictly :)
I should also note that I do not agree with the author on all points (at the end he is already starting to dig in) and, of course, reviews of the code are not a silver bullet, but, nevertheless, a very, very useful practice.)
I started this article on 5 reasons to review the code on CIO.com last week and realized that there are actually more reasons than the five that are written about there. So by the end of the day I had more than 20 of them. This is a collection of those tweets with some details described here.
Reason number 1. Quick enough response to spur the developer.
Since the code review is performed after coding and before integration and system tests, developers do not have to wait as much as the response from the Code Quality Department (QA). By providing a concrete, timely response, developers can fine-tune their coding skills to avoid common mistakes.
Reason number 2. Finds more errors than using one test.
This is obvious: testing finds errors. An overview of the code finds other errors. Used together, they find more bugs than could be found before sending the product to customers.
Reason number 3. A million monkeys sometimes get a valid syntax, even if it means nothing. Compilers cannot track this.
Sometimes you make a syntax error consisting of valid code, so the compiler cannot track it. The classic similar error in C is = (assignment) and == (Boolean equality operator); in this case, most compilers may issue a warning, but there are also other examples. A review of the code will quickly reveal such an error, whereas it can be quite difficult to find it through testing.
')
Reason number 4. Find and destroy the mistakes where they live, instead of finding a nest for theirshit excrement.
When you receive error reports from a code review, you already have the exact line number and a description of the problem. When you get reports from system testing or (oh, horror!) From a user, you have - at best - a set of steps to reproduce the error. Then it only depends on you if you can find the error itself in the code, which usually takes quite a long time, especially if the code was written weeks or months earlier. (see reason number 1.)
Reason number 5. Teach noobs.
Code reviews are an effective learning tool. First, novice programmers participating in code reviews gain access to the code of other programmers and, thus, can “feel” the coding standard and documentation style. Further, inexperienced programmers will receive an assessment of their code before they have a chance to infect the system with their low-grade code. (Because we all know that the code that we wrote 10 years ago is probably terrible - only if he was not lucky enough to get a review from older developers. If you’ve been programming for less than a few years, remember that everything you write today, perhaps terrible, but you cannot appreciate it for a few more years; see reason # 6.)
Reason number 6. From the very beginning, the developer's ego is used to force the quality of the code.
The theory here is this: knowing that the code will be publicly and carefully examined by a group of colleagues, the developers will work more carefully to avoid shame when they find all sorts of errors in their code.
Guest comment @kyletolle : Reason number 7. Clarification of the code ensures its understanding. Removed notes like "Well, I always did that ...".
After you have to answer the same question several times during the review, you may be wondering during the encoding. (see reason number 6.)
Reason number 8. Accelerates testing. Hell, yes, all development speeds up!
There are several main reasons for this. First, since the code review detects and corrects defects right in its place (see reason # 4), respectively, less time is spent on correcting it. Secondly, testers find fewer errors, so they spend less time writing questions that the development department then squeals on. Thirdly, testers do not need to restart regression tests so many times, because there will be less release candidates of the product ... Well, in the latter, testers will be less idle, waiting for bug fixes.
Reason number 9. The smaller the number of angry users, the happier your service is. support .
Proof: Fewer bugs in the product (see reason # 2). Because bugs are not so often annoying users, the latter rarely become angry. So when users finally call, they will sing praises to you. (Okay, maybe the part about the songs is not quite true, but I think you caught the general meaning.) Proof on the other hand: if you spend less time fixing bugs, you can spend more time developing new features that you’re asking for your users.
Reason number 10. (Anti-reason) You will have to pay more commission because of more sales ... hey, that's great!
When users sing the praise of stability to your product, it is easier to sell to new users as well as to increase sales to existing ones. Of course, sales commissions will go up, but I have never heard anyone complain about it too loudly.
Reason number 11. There are tools that reduce the annoying factor of “classic” review processes.
(approx. transl. The list of tools was later given in this very short article , I decided to insert it directly into this rule in order to collect all the information in one place).
Here is a list of review tools, without any specific order. I have not tried them all, so they are given without comparison. If you know any other tools, leave comments and I will add to the list.
Codestriker - An open (open source) web solution that seems to be written in Perl.
Code Collaborator - Paid product.
Review Board - Open (open source) web solution seems to be written in python / Django.
Rietveld - Open (open source) solution from Google. Attempt number 2 Guido van Rossum on the review tools. Guess from 3 times what it is written on ...
Crucible - A paid product from Atlassian.
Bottom line: do not try to do it manually, you will spend a lot of time sending patches and tracking defects, while tools can automagically do it for you.
Reason number 12. The risk is zero. Even not-so-really-super-effective reviews beat testing.
If I had spent some time, I could dig out a few published studies to substantiate this reason. But in my personal experience, code reviews are about 4 times more efficient than unit tests. Therefore, even if I conduct a review without much enthusiasm, I am still more effective than testing. (See reasons # 2 and # 4, also remember about cause # 5, which does not have an instantly measurable effect.) Also, there’s likely to be data that says code reviews are a waste of time. Some flying deer are also possible. (approx. transl. Steve McConnell in his book "Perfect Code" really gives quite a lot of research results confirming the effectiveness of code reviews before testing, and also says that using both of these techniques gives a much better result than using any one of them.)
Reason number 13. (Anti-reason) Testers will be bored because they will not be able to find a lot of mistakes ... Oh yes! They will be able to focus on stress / stress testing. I wish I had such a problem ...
Reason number 14. Reviewing is a good practice for reviewing. You are getting better.
The effectiveness of the reviews in your team will improve over time. This means that the long-term risk of error is even less than the short-term one (see reason No. 12 why the risk of error is equal or very close to zero).
Reason number 15. This is a great way to make a really useful checklist for reviews.
Well, this is a bit doubtful, the checklist for the reviews doesn’t really bother the user at all (I probably should have come up with a couple of reasons to explain the artificial aggregates ... Hey, I tweeted it at 3:00 pm before afternoon tea!)
Reason number 16. Hypothetically: less staff turnover due to the fact that developers spend less time correcting annoying errors.
I don’t know how others are, but I stayed at work, which in other respects was not so cool, because of the quality of the team I worked in and the people around me. Great to feel part of a well-oiled machine. It motivates you to come to work every day, knowing that you will produce a high-quality product and your colleagues will be there to cover you.
Reason number 17. The risk of falling out of the schedule is reduced, because the quality of the product increases with each completed project phase.
Your testers will not stand idle (see reason # 8) and testing will not be delayed. Because you will get a quick response to the schedule (see reason # 1), you can easily determine how long the testing will take.
Reason number 18. The response (especially from colleagues) at the source code level means that you stop making the same mistakes over and over again (see reason # 6).
This is based on the fact that every developer will have on hand information about the types of errors that he makes and thus be able to find ways to prevent these errors. And that's where the magic really begins: when you start thinking about preventing a whole class of mistakes.
Reason number 19. Improving the quality of documentation / comments, as well as the code itself.
(See reason # 7) Developers will better comment on the code to avoid answering more questions from auditors. If auditors are looking for inconsistencies between comments and code, this is an additional motivation to keep documentation up-to-date. Ultimately, I suspect that an overly sophisticated code will become a deficit, since will be studied and polled more times than regular code.
Reason number 20. Users will not find so many bugs in their soup.
This reason may seem unnecessary due to cause number 9, but helping users is the point of our work, isn't it? Therefore, let it remain and - as I said above - I will work on a couple more reasons to add to the list.
PS Moved to the "Revision Code" blog.
I should also note that I do not agree with the author on all points (at the end he is already starting to dig in) and, of course, reviews of the code are not a silver bullet, but, nevertheless, a very, very useful practice.)
I started this article on 5 reasons to review the code on CIO.com last week and realized that there are actually more reasons than the five that are written about there. So by the end of the day I had more than 20 of them. This is a collection of those tweets with some details described here.
Reason number 1. Quick enough response to spur the developer.
Since the code review is performed after coding and before integration and system tests, developers do not have to wait as much as the response from the Code Quality Department (QA). By providing a concrete, timely response, developers can fine-tune their coding skills to avoid common mistakes.
Reason number 2. Finds more errors than using one test.
This is obvious: testing finds errors. An overview of the code finds other errors. Used together, they find more bugs than could be found before sending the product to customers.
Reason number 3. A million monkeys sometimes get a valid syntax, even if it means nothing. Compilers cannot track this.
Sometimes you make a syntax error consisting of valid code, so the compiler cannot track it. The classic similar error in C is = (assignment) and == (Boolean equality operator); in this case, most compilers may issue a warning, but there are also other examples. A review of the code will quickly reveal such an error, whereas it can be quite difficult to find it through testing.
')
Reason number 4. Find and destroy the mistakes where they live, instead of finding a nest for their
When you receive error reports from a code review, you already have the exact line number and a description of the problem. When you get reports from system testing or (oh, horror!) From a user, you have - at best - a set of steps to reproduce the error. Then it only depends on you if you can find the error itself in the code, which usually takes quite a long time, especially if the code was written weeks or months earlier. (see reason number 1.)
Reason number 5. Teach noobs.
Code reviews are an effective learning tool. First, novice programmers participating in code reviews gain access to the code of other programmers and, thus, can “feel” the coding standard and documentation style. Further, inexperienced programmers will receive an assessment of their code before they have a chance to infect the system with their low-grade code. (Because we all know that the code that we wrote 10 years ago is probably terrible - only if he was not lucky enough to get a review from older developers. If you’ve been programming for less than a few years, remember that everything you write today, perhaps terrible, but you cannot appreciate it for a few more years; see reason # 6.)
Reason number 6. From the very beginning, the developer's ego is used to force the quality of the code.
The theory here is this: knowing that the code will be publicly and carefully examined by a group of colleagues, the developers will work more carefully to avoid shame when they find all sorts of errors in their code.
Guest comment @kyletolle : Reason number 7. Clarification of the code ensures its understanding. Removed notes like "Well, I always did that ...".
After you have to answer the same question several times during the review, you may be wondering during the encoding. (see reason number 6.)
Reason number 8. Accelerates testing. Hell, yes, all development speeds up!
There are several main reasons for this. First, since the code review detects and corrects defects right in its place (see reason # 4), respectively, less time is spent on correcting it. Secondly, testers find fewer errors, so they spend less time writing questions that the development department then squeals on. Thirdly, testers do not need to restart regression tests so many times, because there will be less release candidates of the product ... Well, in the latter, testers will be less idle, waiting for bug fixes.
Reason number 9. The smaller the number of angry users, the happier your service is. support .
Proof: Fewer bugs in the product (see reason # 2). Because bugs are not so often annoying users, the latter rarely become angry. So when users finally call, they will sing praises to you. (Okay, maybe the part about the songs is not quite true, but I think you caught the general meaning.) Proof on the other hand: if you spend less time fixing bugs, you can spend more time developing new features that you’re asking for your users.
Reason number 10. (Anti-reason) You will have to pay more commission because of more sales ... hey, that's great!
When users sing the praise of stability to your product, it is easier to sell to new users as well as to increase sales to existing ones. Of course, sales commissions will go up, but I have never heard anyone complain about it too loudly.
Reason number 11. There are tools that reduce the annoying factor of “classic” review processes.
(approx. transl. The list of tools was later given in this very short article , I decided to insert it directly into this rule in order to collect all the information in one place).
Here is a list of review tools, without any specific order. I have not tried them all, so they are given without comparison. If you know any other tools, leave comments and I will add to the list.
Codestriker - An open (open source) web solution that seems to be written in Perl.
Code Collaborator - Paid product.
Review Board - Open (open source) web solution seems to be written in python / Django.
Rietveld - Open (open source) solution from Google. Attempt number 2 Guido van Rossum on the review tools. Guess from 3 times what it is written on ...
Crucible - A paid product from Atlassian.
Bottom line: do not try to do it manually, you will spend a lot of time sending patches and tracking defects, while tools can automagically do it for you.
Reason number 12. The risk is zero. Even not-so-really-super-effective reviews beat testing.
If I had spent some time, I could dig out a few published studies to substantiate this reason. But in my personal experience, code reviews are about 4 times more efficient than unit tests. Therefore, even if I conduct a review without much enthusiasm, I am still more effective than testing. (See reasons # 2 and # 4, also remember about cause # 5, which does not have an instantly measurable effect.) Also, there’s likely to be data that says code reviews are a waste of time. Some flying deer are also possible. (approx. transl. Steve McConnell in his book "Perfect Code" really gives quite a lot of research results confirming the effectiveness of code reviews before testing, and also says that using both of these techniques gives a much better result than using any one of them.)
Reason number 13. (Anti-reason) Testers will be bored because they will not be able to find a lot of mistakes ... Oh yes! They will be able to focus on stress / stress testing. I wish I had such a problem ...
Reason number 14. Reviewing is a good practice for reviewing. You are getting better.
The effectiveness of the reviews in your team will improve over time. This means that the long-term risk of error is even less than the short-term one (see reason No. 12 why the risk of error is equal or very close to zero).
Reason number 15. This is a great way to make a really useful checklist for reviews.
Well, this is a bit doubtful, the checklist for the reviews doesn’t really bother the user at all (I probably should have come up with a couple of reasons to explain the artificial aggregates ... Hey, I tweeted it at 3:00 pm before afternoon tea!)
Reason number 16. Hypothetically: less staff turnover due to the fact that developers spend less time correcting annoying errors.
I don’t know how others are, but I stayed at work, which in other respects was not so cool, because of the quality of the team I worked in and the people around me. Great to feel part of a well-oiled machine. It motivates you to come to work every day, knowing that you will produce a high-quality product and your colleagues will be there to cover you.
Reason number 17. The risk of falling out of the schedule is reduced, because the quality of the product increases with each completed project phase.
Your testers will not stand idle (see reason # 8) and testing will not be delayed. Because you will get a quick response to the schedule (see reason # 1), you can easily determine how long the testing will take.
Reason number 18. The response (especially from colleagues) at the source code level means that you stop making the same mistakes over and over again (see reason # 6).
This is based on the fact that every developer will have on hand information about the types of errors that he makes and thus be able to find ways to prevent these errors. And that's where the magic really begins: when you start thinking about preventing a whole class of mistakes.
Reason number 19. Improving the quality of documentation / comments, as well as the code itself.
(See reason # 7) Developers will better comment on the code to avoid answering more questions from auditors. If auditors are looking for inconsistencies between comments and code, this is an additional motivation to keep documentation up-to-date. Ultimately, I suspect that an overly sophisticated code will become a deficit, since will be studied and polled more times than regular code.
Reason number 20. Users will not find so many bugs in their soup.
This reason may seem unnecessary due to cause number 9, but helping users is the point of our work, isn't it? Therefore, let it remain and - as I said above - I will work on a couple more reasons to add to the list.
PS Moved to the "Revision Code" blog.
Source: https://habr.com/ru/post/88075/
All Articles