Code reviewer == Code editor?
Sunday, March 05, 2006
dictionary.com defines "editor" as follows:
editor
n 1: a person responsible for the editorial aspects of publication; the person who determines the final content of a text (especially of a newspaper or magazine) [syn: editor in chief] 2: (computer science) a program designed to perform such editorial functions as rearrangement or modification or deletion of data [syn: editor program]
Editing seems to be all about quality, but not in the computer science sense. So how can we introduce editors into our Software Engineering practices?
Fancy Software Engineering books tell us that code reviews are part of the Quality Assurance process used to improve the quality of code, along the lines of controling the
variability of code.
I doubt anyone would argue against performing code reviews. They are a good thing, however, they are time consuming and sometimes redundant.
Code reviews can also become a liability if there is no clear goal to accomplish, or the whole process is faulty, i.e., it is performed in an ad-hoc manner, or for example, if your code reviews are only checking for style and variable-name consistency--in this case, you should save the time and effort it takes to perform them, and just invest in training your development group with the proper syntax and coding standards of your choice.
Code reviews should, in my view, be more of a dry run of the code to make sure everything gels. In other words,
a code reviewer should be the equivalent of an editor in the publishing business.
An editor will try to fix everything on any piece of written work before hitting the printing press (they try, at least). The code reviewer's job, then, should be to find faults in logic, syntax, performance, and try to make a piece of code as elegant and efficient as possible (yes, code should be elegant) before formally transitioning the component to the Quality Assurance group, and after unit testing has been completed by the developer.
In other words, a code reviewer/editor should start eyeing the code files when the code tree fully compiles and has passed the minimum developer's test suits.
Reason would dictate that by adding one more layer to development life cycle, you are adding more time to your timelines therefore exploding your budgets, however, this is fact not the case when you look at the development cycle as whole, i.e., Software Engineering/Development is not just programming.
Fixing problems when QA finds them is actually more expensive than fixing them when the developer is still playing around with lines of code, i.e., a full cycle of development/formal testing can get quite expensive in the long run.
Formalized code review cycles, however, are sometimes unrealistic. For example: there may not be anyone on the team that can do a good job at it; or the budget is extremely tight and there is really no money left to review all the code; or, lets face it, reviewing 100,000 files per project is not feasable: assume it takes 3 hours to review each file. That is 300,000 hours, or 7,500 forty-hour weeks to review the code tree--this is quite an expensive proposition. Though, it is one of those things: damned if you do it, damned if you don't.
I would say you that should try to implement some type of code review at some point in your engineering process, and perhaps be selective and choose the files that contain complex algorithms.
To bring finances into the matter: if you think of code review as as waste of time, then you do not know about the time value of money. It is obvious that finding a bug and fixing it right now, is cheaper than finding one and fixing it tomorrow. (The time value of money stipulates that a dollar earned today is worth more than one earned tomorrow because of inflation and such.)
Introducing a "code editor" into the mix brings another interesting point: what if developers start relying too much on the editor to correct mistakes?
I guess if it comes to this, then a better software engineering process needs to be put in place since developers should not rely on extra resources to write quality code.
Comments: