3
\$\begingroup\$

How do you contrast Code Review, as a StackExchange site, with a real-life code review?

If there are differences, are these differences acceptable?

How does Code Review bridge the gap between a newcomer's mental model of what a code review is and expectations of the Code Review site?

Are these efforts sufficient?

\$\endgroup\$
  • 1
    \$\begingroup\$ How does SE Stack Overflow differ from real life debugging? Are these differences acceptable? \$\endgroup\$ – nhgrif Apr 20 '15 at 19:06
  • 4
    \$\begingroup\$ I think this question is formulated in a way that makes it unreasonably hard to answer. Please try to name specifically what you'd like to discuss. I can't even see what you're trying to get at, what bugs you, so to say. \$\endgroup\$ – Vogel612 Apr 20 '15 at 19:13
  • \$\begingroup\$ related: What is a Code Review? \$\endgroup\$ – Simon Forsberg Jul 22 '15 at 14:25
13
\$\begingroup\$

A few things that come to my mind and which could differ from a "real-life" code review:

  • Your review remains: here, code review isn't an oral process, it's a written one, and it is made to remain. We try to write interesting answers, but also to structure them, to include some nice mathematical syntax when needed, some images from time to time... The review will stay and may help other people, while many real-life code reviews will only help one person.

  • Your original code remains: we strive to keep the original code so that the answers are not invalidated for as long as possible. In real-world code reviews, the original code isn't guaranteed to remain either (source control software exists, but there may still be reasons for your original code to be deleted at some point, be it intentional or not).

  • Reviewers are reviewed: you don't have one, but several people reviewing your code. And the answers from some people will be built upon to create new answers. Hopefully, it helps to give the best possible advice.

  • We are volunteer: you are not guaranteed to get a review, and the reviews are not guaranteed to be reviewed either. You can only ask for help, you can't demand it.

\$\endgroup\$
14
\$\begingroup\$

That all depends.... what does a real-life code review look like?

I have been through many of them, and they are all different.

Trying to relate this site to a dynamic, fluid, poorly standardized process, is not a realistic endeavour, and the results of such an analysis would do little to impact the 'gap' of a newcomer's expectations. To be fair, no newcomer will know what a real-life code review is, and experienced people will know to expect something different each time.

As a consequence, since it is hard to assess what efforts would be required, it is similarly hard to decide whether the efforts are sufficient.

If your concern is about the name 'Code Review', well, it is clear that what happens here is nothing like what happens in a 'real' code review (for a start, in a real code review you have real people in a real room, with a real salary, and a real deadline, etc.).

In essence, Mu.

\$\endgroup\$
  • \$\begingroup\$ I like the reference, but I do believe it's a worthwhile endeavor. IMHO the name "code review" may sometimes be responsible for new users making assumptions that require some adjusting or "re-learning" to mesh well with the framework of this site. \$\endgroup\$ – moarboilerplate Jul 22 '15 at 14:55
5
\$\begingroup\$

The difference between Code Review and real life reviews is that the latter are a regular activity involving the same participants, and so over time a shared expertise can be developed and written down.

After some problem has come up a few times in review, it gets added to the local coding standard or pre-review checklist, and people learn to spot the problem themselves and fix it before it gets as far as review, so that after a while, the basic problems no longer come up, and you can use the time to analyze the code more deeply. (If this isn't happening in your real-life reviews, then something's wrong.)

Whereas at Code Review, most questions are from someone who's new to the review process, and so they mostly have the same basic problems (lack of documentation, lack of tests, poor functional decomposition or class hierarchy, poorly chosen names, poor handling of error conditions, failure to make full use of the standard library, and so on).

\$\endgroup\$
  • \$\begingroup\$ this is one of the important difference, here only we can learn and we can't be so sure about the use of the knowledge in future. \$\endgroup\$ – Vignesh Apr 22 '15 at 14:11
4
\$\begingroup\$

Approaching this from another perspective, this also depends on the code review format of choice in real-life (cough):

  • Side-by-side in front of the computer, i.e. an extra pair of eyes
    • Refactor on-the-spot
    • One-on-one
  • Whiteboard
    • Erasable (assumption: erasable board)
    • Synchronous group review (likely, hence the bigger canvas)
    • Free-form drawing (either to de-stress, or version 42 of the Entity Relationship diagram)
  • Specialized code review tools such as ReviewBoard or Crucible
    • Arguably more structured (based on what I know: support for iterative reviews, classifying feedback, in-line comments, approve or reject changes)
    • Customizable views
    • Optional SCM integration
    • Asynchronous group review

Whether these differences are acceptable is up to both the reviewer and reviewee. Sometimes you just need an extra pair of eyes within the next 5 minutes, or sometimes you want to leverage on iterative code reviews to compare the evolution of the proposed changes.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .