Time spent using peer reviews?

Question

How much time do you spend with peer reviews?

Are you looking at everything?

I am trying to find more code reviews where I am currently working, and trying to understand what is happening in the wider world.

Answer 1

I believe that you should review at a high level at an early stage of development, focusing on design and architecture, and consider at a lower level at the end of development, focusing on efficiency and technique.

see also

When is the best time to view the code?

The process of viewing the code?

Answer 2

In my previous place, we had a piece of time devoted to code looking through all the new code. This was an official affair, and we, as a rule, several reviewers looked at each part. We followed some metric - something like 250 lines checked per hour and broke things into pieces that took two hours or so. It can be a long, drawn out business for certain pieces of code. I had one application in which there were about 18 thousand LOC, and therefore you can imagine a clock dedicated to this.

In retrospect, I am not convinced that the review weeks have always been well spent. We did not conduct unit tests at that time, and we spent a lot of time working with UML diagrams in Rational Rose. I'm not sure if it is worth it either.

In my store, we have a less formal process of checking the code, but I do a lot of tests on my own experience and probably have 3x lines of test code that I do for production code. This is part of the equation, at least for me, this is the best bang for the buck. It seems to me that having a bunch of tests confirms that everything works as advertised. But this is a philosophy that some people do not buy.

We are in code that writes each other fairly regularly, but we do not have official code reviews. I think this is a cultural thing, and I honestly believe that the code we write in my store is a cleaner and more correct code than the material that we wrote in my previous place, despite the lack of a formal review process. This may be the caliber of the developer that we have. We just do something different here and seem to work well.

With that said, however, if you're going to do code reviews. Budget time for them. Do not make them an afterthought or try to squeeze them into some kind of schedule. Devs can take a pretty shallow look at the code if they are pressed for a while and overloaded, trying to achieve "real work". When we did not have a budget for this, we got a small benefit from them.

Only my thoughts.

Answer 3

Although it would be nice if the code looked through everything, it’s hard for you to get people to do it in a timely manner (especially those that were published for official code reviews). Start with unofficial reviews (for viewing leverage, viewing checks, incorrect coding, ...) Then add more formal reviews of important blocks of code.

Answer 4

1.) Code reviews should be planned and scheduled.

2.) Code Review / Preview is what we do. that is, the author of the code first explains the functionality of the code that he wants to revise. Algorithm level. This gives a good idea and background information for the reviewer, and he gets various views on the code during the actual review of the code, namely: perspective prospects, optimization (runtime / memory), portability, readability

3.) At one meeting, only 2 hours of code should be reviewed. We found this by trial and error, that 2 hours is a kind of limiting case (not less, but not big), while maintaining the quality of reviews / comments.

4.) Send the code to reviewers 2-3 days in advance, based on the complexity / LOC of the code after the preview.

5.) Reviewers view it offline and come to a meeting with their comments.

6.) At a meeting, the author listens to each comment of the review, accepts / rejects it with the corresponding reason.

This process has supported me so far.

-AD