Back to Basics

New projects are all about excitement and energy. Excitement for a new team, a fresh set of challenges, and new opportunities.

Recently I jumped in for the tail end of a new project, so I was pretty stoked to see what great things my smart colleagues had put together, learn from them and contribute back to the code base. 

Well somewhere in the midst of that, I was reminded of another quality of new projects. Technical debt. Some of that debt comes with the territory, and some of it we put there ourselves. Or do we? Can we find a way not to leave that debt for others to pay?

One challenge had me bogged down in the weeds trying to sort things out and find a solution. In time, I clawed my way back to the sunlight and made the computer do the thing. But it wasn't until I walked away from the screen that the quiet voice of reason reached my inner ear. Speaking to me in the voice of a DBC instructor, it calmly asked if there's another way to achieve what I need.

In the excitement of a new project and a fresh challenge, I had lost sight of some of the simpler principles of the code. In this case, object-oriented code.

Picking out the right data from a set can be a frustrating task. And Drupal, having been built on a foundation of object-oriented PHP, has a funny way of handing us variables like this:

$search_result->_entity_properties['field_science_categories:entity object']->field_science_categories_color['und'][0]['value']

By funny, I mean maddening, I hate your face. Not a bug, that's a feature of Drupal. It's a lot of careful inspection to narrow down the variable set and find what you're looking for. (In this case, the output of a relationship field inside a view.)

Chances are if I see that big long variable once, I'm going to see it again in PHP. And that's compounding my unhappiness.

if (isset($search_result->_entity_properties['field_science_categories:entity object']->field_science_categories_color['und'][0]['value'])) {
    $search_result->_entity_properties['field_science_categories:entity object']->field_science_categories_color['und'][0]['value'] ...

Now it's not my task to rebuild Drupal into a rigid-class structure. I wish someone did, because I like woking in Rails a lot more, for this reason. And on this day, nor was it my task to build an entire class to handle this variable. So maybe I leave this technical debt in the code?

Fortunately I have the weekend to ponder it, and in that time I'm reminded of a personal project that could benefit from a little of this re-thinking. Something built in Angular

Sorting through the data of an API call, I feel a little dirty trying to get the bits I want in the response, or in the template. You know what's easier? Make it a class, son!

var Sport = function(data) {
  this.data = data;
  this.sportId = data.program.sportsId;
  this.startTime = new Date(data.startTime);
  this.endTime = new Date(data.endTime);
  this.title = data.program.eventTitle;
  this.genres = data.program.genres;
  this.station = data.station.callSign;
  this.stationNum = data.station.channel;
   
  this.duration = function() {
    return this.endTime - this.startTime;
  };
};

Now that just makes my eyes happy. And my conscience. It's reusable, it's more efficient. It makes more sense, it's easier to remember.

Jumping from PHP to Javascript might make some people crazy. I learn a great deal from it. Studying Spanish and then Portuguese helped me understand better my native tongue and the art of expression. I expect I will learn just as much about programming by juggling a couple of languages in my head at the same time.

Oh and remember that classes are your friend.