These code defects, that could have been easily identified and fixed earlier during the Software Development Life Cycle (SDLC) by effective code review processes, remain unnoticed till the software is delivered.

End result – More rework, Effort & Schedule Slippages and bad remark for the programmer.

The four simple steps a programmer should take to avoid such situations are

1. Prepare (or Obtain) a Code Review Check-list

-  Check out a sample here

2. Perform Self-Review

- Focus on requirements during review

- Use tools to identify defects

- Complete the checklist

3. Perform Peer-Review

- Arrange a code review/walk through meeting with a reviewer who understands the business & technology

-  Reviewer should focus on determining if the code is actually doing what it’s supposed to be doing

- Record feedback from the reviewer  & complete the checklist

- Rework. Incorporate the review comments

4. Publish Best Practices & Lessons Learnt

- Never repeat a mistake

- Help the fellow programmers in delivering a better code

Step 1: Define Standards

A project management methodology that addresses the principles, practices and procedures for performing project management should be clearly defined.

These methodologies should be defined for various type of software projects and should clearly de mark the requirements for
a) Development, Maintenance or Production support projects b) Small scale, Medium scale and Large scale projects (based on cost budget)

Step 2: Review Projects

Every project undertaken the organization should be reviewed periodically and ascertained that they follow the standards defined in step1.

Step 3: Record Findings

This is a very vital step. All review process should record the non-conformances to the standards and constructive feedback to improve the situation should be provided to the project management team.

Step 4: Report Results

A clear report detailing the observations and the pending action items should prepared and circulated to every stakeholder of the project. Any best practices followed by one project team should be highlighted. Also feedback obtained regarding the standards and procedures defined in step 1 should also be reported.

The above 4 steps are critical for any organization that aims to improve the probability of project success.

Java Language

public interface MyInterface {
public void myFunction(Object param1);
}
public class MyClass1 implements MyInterface {
public String variable1 = “Hello”;
public String variable2 = “World”;
public void myFunction(Object param1) {
System.out.println(“Java says: ” + variable1 + ” ” +
variable2);
}
}
public class MyClass2 implements MyInterface {
public String variable1 = “Hello”;
public String variable2 = “World”;
public void myFunction(Object param1) {
System.out.println(“Java says: ” + variable1 + ” ” +
variable2);
}
}
Note that in this example, the body of the myFunction() method is identical in MyClass1 and MyClass2. In addition, each class has two String variables that are initialized outside of the constructor.

Now compare a mixin that accomplishes something similar in JavaFX technology:

Java FX

mixin class MyMixin {
var variable1 = “Hello”;
var variable2 = “World”;
function myFunction():Void {
println(“JavaFX says: {variable1} {variable2}”);
}
}
class MyClass1 extends MyMixin { }
class MyClass2 extends MyMixin { }
Benefit :If you have functions or variables that are duplicated across multiple classes, you can maintain them in a single file in JavaFX, as opposed to maintaining them in each class that implements the interface in Java technology.

Check this out

“After pressing a button on the box for a few seconds, all your Twitter followers get to see your heart rate along with a quick evaluation (bradycardia/normal/tachycardia)”

Read more about it here

Any guesses on the team that will take the cup home this time? and how about ”The GOLDEN SHOE”?