Today’s Read: Four Ways To A Practical Code Review

July 20th, 2010 by Kevin | No Comments | Filed in development

As per the definition of Wikipedia,

Code review is systematic examination (often as peer review) of computer source code intended to find and fix mistakes overlooked in the initial development phase, improving both the overall quality of software and the developers’ skills.

In this article, Jason Cohen mentions that there exists a formalized system of code review developed by Micheal Fagan at IBM in the mid-1970s. However he points out that the software development process has come a long way since then and we can have process and metrics and measurement and improvement and happy developers all at the same time. The way to achieve this is by using a lightweight code review.

There are four types of lightweight code review techniques:

1) Over-the-shoulder: One developer looks over the author’s shoulder as the latter walks through the code.
This is the code review technique that we use in our organization and that I am familiar with. Once the implementation has reached a level of completion, we initiate such an over-the-shoulder code review process. One of the experienced peers working on the project acts as the reviewer and sits alongside the developer. The developer walksthrough the code implementation explaining why and how the implementation has been done. The reviewer can interrupt the review process to ask any queries and point out discrepancies in the implementation. Small changes can be fixed by the developer during the review process. Larger changes can be taken offline. Once the code review is complete, the developer can check in the changes to the SCM system.

2) Email pass-around: The author (or SCM system) emails code to reviewers.
This is the second-most common form of lightweight code review, and the technique preferred by most open-source projects. Here, whole files or changes are packaged up by the author and sent to reviewers via email. Reviewers examine the files, ask questions and discuss with the author and other developers, and suggest changes.

3) Pair Programming: Two authors develop code together at the same workstation.
Pair-programming is two developers writing code at a single workstation with only one developer typing at a time and continuous free-form discussion and review.

4) Tool-assisted: Authors and reviewers use specialized tools designed for peer code review.
This refers to any process where specialized tools are used in all aspects of the review: collecting files, transmitting and displaying files, commentary, and defects among all participants, collecting metrics, and giving product managers and administrators some control over the workflow.

The complete article by Jason Cohen can be found at: Four ways to a Practical Code Review.

 

Related Posts:

Tags:

Don’t Be A Hotshot Programmer, Be A Boring Programmer

July 8th, 2010 by Kevin | 6 Comments | Filed in development

Should a programmer be boring? Before that, what does it mean for a programmer to be boring? Following are the points that make it worthwile to be a boring programmer rather than a hotshot programmer.

1) Boring Programmers Write Simple Code.
Hotshot programmers find it cool to write complex code that achieves reduction in CPU usage and/or memory usage. Boring programmers prefer writing code that will be simple to understand by other programmers who read it. They do not mind that it may take a couple of more CPU cycles if the code that they write is easily readable and maintainable. Because boring programmers know that in most situations, the memory and CPU speed available does not matter over writing clean, maintainable code.

Hotshot programmers may write:

unsigned uCycleCheckBox(unsigned uCur)
{
   return ((uCur<=1)?(uCur?0:1):(uCur==4)?2:(uCur+1));
}

Boring programmers will write the same as:

unsigned uCycleCheckBox(unsigned uCur)
{
   unsigned uRet;

   if(uCur <= 1)
   {
      if(uCur != 0)
         uRet = 0;
      else
         uRet = 1;
   }
   else
   {
      if(uCur == 4)
         uRet = 2;
      else
         uRet = uCur+1;
   }
   return(uRet);
}

2) Boring Programmers Write Documentation.
Hotshot programmers may see documentation as a waste of time. After all, it takes too much time to write it. And then it has to be updated with changes in the sytem. However, boring programmers write documentation and update it with the major code changes that affect the documentation even if it means that they can't start working on other cool requirements till they have completed it. They write documentation so that they or any other programmers who start working on their code can read such documentation and understand about the code instead of having to bother other programmers about it.

3) Boring Programmers Read Documentation.
Hotshot programmers feel they have no need to read documentation as they feel comfortable reading the source code. Boring programmers read the documentation of the system that they are working on. They know that if the documentation has been created then it is meant as a standard view of the system and that will bring them up to date with how the system has been implemented. To find a solution to a problem that they are working on the first time, instead of randomly searching into the code, boring programmers look into documentation and try to find out a method that will provide the standard solution to the problem.

4) Boring Programmers Test Code.
Hotshot programmers like to pass the responsibility of testing to the testers because they want to start working on new, cool features the moment the existing functionality seems "finished". Boring programmers prefer to test the code that they write. They prefer to find bugs in their code rather than postponing it to the testers. So they make an effort to test their code as much as possible even if it means that it is boring. For this, boring programmers step through their code and debug every path in the code even if it seems boring.

So are you a boring programmer or a hotshot? Do you strive for clean and maintainable code? Do you believe in writing good documentation for the system you work on? And do you thoroughly test your code or do you think it is the task that testers are paid for?

 

Related Posts:

Tags:

How To Avoid Bugs By Not Writing Code (At-least Not Too Much)

July 5th, 2010 by Kevin | 2 Comments | Filed in development

Avoid Source Code

Seriously, if there were no programmers writing code, there would be no bugs. However, hypothesis aside, the number of bugs that you introduce in the software is directly proportional to the amount of code you write. So if you want to avoid bugs, don’t write code. Or rather just write as much code as is really necessary. Following are some of the points that programmers can keep in mind during software development that will help keep the code addition/changes to a minimal and help in maintaining system stability.

1) Keep it simple
“Hmm. This requirement seems interesting. I will use my godlike programming skills and techniques to create code that is fast and consumes minimal memory. Sure it will make the code a bit complex but what the hell as long as it is good.”
Many programmers tend to enjoy writing complex code as a way of showing off their skills. However each line of code that you add could turn out as a potential bug until you have ensured that it is not. So keep the implementation as simple as possible. The easier it is to understand the code, the lesser will be the number of bugs that are introduced. Even if there are bugs they can be easily found by reading and debugging through the simplified code. In short, when writing code, don’t be a lawyer, be a programmer.

2) Avoid unnecessary refactoring
“Hey, who the heck wrote this code? Some of that code seems unnecessary? We don’t need unnecessary stuff like that. Removing this should clean up the code. Ain’t I cool?”
While reading code written by others, programmers are tempted to try and fix what may seem “different” than their style of programming. This type of refactoring can be dangerous because trying to change working code is again a possibility to introduce new bugs. Surely code should be refactored as new changes keep getting added. However this should be a separate effort that should be sorely focussed on refactoring and it should be avoided during the normal development phase.

3) Fix bugs don’t introduce more
“Oh, the bug count is up by five today. No matter, I already know how to fix a couple of them. I’ll just add these patches and we’re done.”
Fixing bugs is always a battle between resolving the earlier ones vs introducing new ones. Many a times the patience of the programmer is tested while fixing bugs because of this balance that has to be maintained. Extra Care has to be taken while fixing bugs so as not to introduce new ones perhaps even more critical than the old ones. Try to fix the bugs with as minimal changes as possible. If major changes are required, analyze if the fix is important enough for the release or it could be postponed to the next release.

 

Related Posts:

Tags:

« Older Entries