T. L. has a co-worker, Taran, who was obviously the best there was, is, and ever will be. Taran had a penchant for using the word obviously. In almost every sentence. Of every paragraph. Of everything he ever wrote and said. Even in his comments. Most folks tried to ignore it, but after hearing it umpteen-thousand times, it began to wear a bit thin.

To his credit, Taran was a fairly bright person. This made their boss think that the other team members were obviously less than adequate, what with them needing obvious things explained to them all the time. To rectify this, he started replacing the lay-folk with people that Taran felt were obviously more qualified. After about a year, most of the team had been rotated out for people who were obviously better suited to their assigned tasks.

Around that time, management noticed a severe uptick in the number of problem reports. T. L. was assigned the unenviable task of figuring out where things went awry. He did a casual spelunk down into the code, but didn't see anything glaring back at him. He spelunked through the myriad configuration files but again, came up empty. Oh, there were the usual gotchas, but nothing that seemed endemic.

Then he noticed something odd; the check-in comments seemed to follow a distinct pattern:

   10-01-12 Joe   add functionality xyz
   10-02-12 Taran refactor functionality xyz into x, y and z
   10-03-12 Taran refactor functionality x into x1, x2 and x3
   10-04-12 Taran refactor functionality y into y1, y2 and y3
   10-05-12 Taran refactor functionality z into z1, z2 and z3

...and so forth. Upon more closely examining all of the refactoring, T. L. discovered that Taran had done each of the folowing - everywhere:

  // Original code
  int result = someExpensiveFunc(...);
  if (result > 0) {
     somePermanentVar = result;
  }

  // Refactored code
  // Taran: static calls are free
  // OP: but instantiating objects repeatedly is not
  if (FuncFactory.getInstance()
                 .getHandler(SomeExpensiveFunc.class)
                 .someExpensiveFunc(...)) {
     somePermanentVar = FuncFactory.getInstance()
                                   .getHandler(SomeExpensiveFunc.class)
                                   .someExpensiveFunc(...);
  }

  // Original code
  Map<String,Integer> map = new HashMap<String,Integer>();
  for (int i=0; i<1000000; i++) {
      // use map to do stuff
      map.clear(); // OP: empties map
  }

  // Refactored code
  // Taran: Obviously, the gc will take care of this; allocate as close to use as possible
  // OP: yes it will; all 1,000,000 times
  for (int i=0; i<1000000; i++) {
      Map<String,Integer> map = new HashMap<String,Integer>();
      // use map to do stuff
  }

  // Original code
  public class Base {
     public void theFunc(...) { ... }
  }

  public class Sub1 extends Base {
    // ...
  }

  public class Sub2 extends Base {
    // ...
  }

  Base base = ...; // some instance of either Sub1 or Sub2
  base.theFunc(...);
   
  // Refactored code
  // Taran: Obviously, virtual calls take time: flatten classes
  public class Sub1 {
    public void theFunc(...) {
      // code
    }
  }

  public class Sub2 {
    public void theFunc(...) {
      // code (duplicated)
    }
  }

  // OP: used as:
  Sub1 sub1;
  Sub2 sub2;
  // ...
  if (...) {
     sub1 = new Sub1();
  } else {
     sub2 = new Sub2();
  }
  // ...
  if (sub1 != null) {
     sub1.theFunc(...);
  } else {
     sub2.theFunc(...);
  }

T. L. found countless cases of duplicated function calls, infant mortality gc problems, and duplicated code that had gotten subtly out of sync, and obviously had a conversation with their boss.

Taran's boss called Taran in to discuss it. Taran obviously couldn't rationally justify the mess he'd made.

Taran is now spending his days seeking employment.

Obviously!

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!