Writing a flexible code

For sure it’s a very desired subject, for both development teams and management as well. Flexible code allows us to keep the code base beautiful, clean, testable, gives us the ability to accommodate new features without struggling to existing components, and new features won’t probably impact in previous ones.

In despite of the fact flexible code is so wanted for almost everybody, I’ve seen so many times entire teams fighting to add a single new feature, fighting to management to get few extra hours to be able to re-factor some code and so on.

I thought it would be very nice to bring this topic to an open discussion, about how to achieve a flexible code in our applications, sharing my ideas to help some other people to understand a bit more about this mechanics and learn more from others as well, so let get into this.

The first thing to talk about flexible code is Test Driven Development ( TDD ), because it’s a shift and how to build programs using this technique. It is possible to write every single code using the cowboy mode, I mean, we usually have a flow inside our heads, we know how to link things together and we go straight that way without thinking about how things should behave or not. That approach “works”, of course, if it didn’t nobody would have never ever delivered a single software solution, but in the majority of those “success” cases people delivery a poor quality software. The first big problem is that without tests we can’t be sure neither if the code is working as it’s supposed to be, nor if it will keep working after the first change on it. TDD is a true mind shift about how to write software, aiming first the simplicity, because at a coarse level we have to create a test first to our classes, subsystems and complete deliverable (story, use-case, etc). So, if we are building something weird our tests will tell us about that, and we’ll also be able to run our tests suite against the old and new code, which will show us how it is going, and if any error pops up we’ll be noticed and able to fix it shortly.

The second aspect of a flexible code is to apply constant refactorings to the code base. Why ? because things usually never gets well done at first, maybe because our knowledge is limited at that time, and also, because a good decision today can be an impacting factor tomorrow, people change, business change and so on. So, it’s always good to leave the place better than we found when we arrived. Of course, we don’t need to refactor an entire code base at once, refactorings should be used as we go, specially in small steps. A good example is picking up a big method which is preventing us to add a new behavior and create a test case against it ( if there isn’t one ), apply some refactorings to extract methods, variables and so one.

After all, code must be written targeting human beings and secondly machines, because the computer can understand everything we write, unless we commit some typo and then the compiler will catch us. On the other hand, humans need something clean and not misleading to understand to keep working on.

The third aspect I will talk in this post is the usage of design patterns to guide our design towards a flexible code. As you may know, design patterns are proven solutions to remove code duplication and provide us a more clear tool to communicate our intentions inside the code we write. What is most clear, trying to explain a 1.000 lines class or say you have a flexible algorithm because you are using a strategy pattern for example ?

There are many other things to discuss about flexible code, but I preferred to limit our universe into these few points, and I’ll be bringing more information on the next posts where I’ll explain these topics in more depth, I hope you enjoy reading it as much as I’m enjoying writing it.

 

2 Comments

  1. Carolina Mourao:

    Tks Marcio, if only we had the time to bring this into reality. Product Managers just want to release new functionality and rarely will allow developers to go back and refactor things. The deliverable of refactoring work is usually not seem by the eyes of the business sponsors.

  2. Marcio Marinho:

    The greatest thing about refactoring is that it does not need to be done in a single strike! Well, unless everything is screwed to death. But in general we should use the rule : Leave the place you’re touching better than when you arrived. Doing so will make the code more readable and more maintainable.

Leave a comment