We do software from small embedded up to server and backend. The "lower" parts (embedded uC) do the most code reviews. It lessens farther up. But they have the highest device numbers and the most problems correcting an error afterwards.
You don't want to waste a lot of time looking over individual lines
>of code -- assume the programmer is competent (else why did you
>hire him/her?). Rather, check for things that tend to slip
>between the cracks, identify and then *challenge* assumptions that
>may have been made, etc.
But enough errors are hidden in these individual lines. There are very few if any programmers who don't do any errors at that level. Especially in cases, when code is seldom used or the error is by luck handled by some other part of the program. So simple tests won't find it.
I learned to do CodeReviews just after coding before much tests have been done. So there will probably be errors in the code.
It is important that code reviews (and design reviews, in general)
>not be seen as "evaluations", "criticisms", etc. Personalities
>can make or break this entire process. The best environments
>that I've worked in had lots of really talented people (with
>*different* sets of talents) who could appreciate *your* skillset
>(as you appreciated theirs) and feel confident *challenging*
>something you've done knowing that (in case they are "wrong")
>they won't "look stupid" for doing so, etc. A sense of humor
>goes a long way to making this process work effectively.
Yes. Some problems will come to the mind of the presenter just by explaining it the the others. Some by questions from "outsiders" which never came up before.
And there's another benefit from codereview, at least if programmers from the same domain are involved. More people know the code and may work with it if needed in the future.
RK