Re: What is code review? (Java code review)
"www" <www@nospam.com> wrote in message
news:f1va9a$ch3$1@news.nems.noaa.gov...
According to what I heard, "code review" is somebody reads the thousands
lines of code written by other person and try to find if there are some
errors (logic errors, I guess, since the code at least can be compiled
and run).
I feel this is crazy!!! Since the reviewer has to "read" the original
code author's mind and make sure the code does what the author wants and
no hidden surprises! How this could be possible?! This would be
extremely time consuming and nobody knows better about the code than the
author.
If the review has to read minds, and this is impossible given the
level of documentation and choice of identifiers in your code, then your
code is probably poorly written.
Consider the following code snippet:
public int a(int b) {
return b;
}
Does this do what the author intended? Are there any hidden surprises?
It's impossible to tell, because the author did not write any
documentation, and chose meaningless identifier names. Contrast with this
code:
public int hashInt(int intToHash) {
/*
* Implementation is just to return the same
* int. This is a perfect hash.
*/
return intToHash;
}
Now, thanks the the name of the identifiers, and the comments, we can
guess what the author was trying to do, and check that it does in fact do
what the author intended.
Code reviews correctly would flag the first example as needing to be
rewritten.
My boss says this is very common practice in software engineer
development.
Is this true? Or my understanding from my boss is wrong?
It's common. I don't know about "very" common, but it's common enough
that I'd expect someone referring to themselves as a "middle level
programmer" (whether Java or some other language) to know what the term
"code review" refers to if I brought it up.
As an aside, to help re-assess your self-evaluation, I'd also expect
someone referring to themselves as a middle level programmer to be
familiar with the following terms. If you're not familiar with them, you
may wish to do some more reading.
* Design patterns
* Extreme Programming
* Test Driven Development
* Unit Testing
* Black Box Testing
* Model View Controller
* Singleton
* Source Version Control
* Pair Programming
* KISS
* UML
* Class Diagram
* Sequence Diagram
Note that for the terms that refer to methodologies, I don't expect a
middle level programmer to actually *practice* all of the above
methodologies, but rather that they should be familiar with what the terms
refer to.
- Oliver