Michael Feathers defines four main reasons to change your code in the book Working Effectively with Legacy Code. I found those few paragraphs interesting, and I would like to share them with you from my perspective.
Four main reasons to change are
- Adding a feature
- Fixing a bug
- Improving design
- Optimising
Adding Feature and Bug Fixing
The most typical reason to change software is an adding of the feature. Your software is acting one way, and the boss or client needs it to do something else.
At first, adding a feature may look like an easy task for both sides. Friction between the developer and the task assigner began when the assigner thinks it is a bug, but the developer sees it as a completely new feature.
At the moment when I am writing this article, I am also working on a form-based information system, and a new task recently appeared in the mailbox. The client wants me to fix the focus behavior of textboxes. He thinks that every time he clicks or tabs into a textbox that contains a text, the whole text should be already selected or as he said; “it should be blue”.
As the developer, you know that this is not typical behavior of textbox and you will have to make changes. Depending on the framework you are working with, the task can take a few minutes or a few hours, and you may come out without a solution.
It might seem that difference between adding a feature and bug fixing is just the dilemma about the contrast of the point of view. A task stays the same, and you still have to complete it one or another.
But some companies are tracking developers' time, for example, for invoice calculations or quality initiatives. Such difference decides if the company will bill the customer for a new feature or not. Bug fixing can be part of the contract with the customer. In this situation, the determination of difference is crucial.
Design Improvement and Optimisation
First of all, don’t get me wrong. By saying the word design, I mean a code design, no design of user interface.
Design improvement is a different kind of software change. It is driven by the goodwill of the developer, not by the boss's task. When we want to alter the software’s design to make it more maintainable, we want software behavior to keep untouched. By changing a design, we may introduce a bug. Fear of introducing a bug leads to intact code segments which stay the same since the beginning and will rot.
As developers, we grow, and knowledge of our craft rises. Time goes by, the design of new code is better, and one day task will appear for adding a new feature into old code parts. We can clearly say that such situations will once in a while come out. Such a position always motivates me to improve the design, but I am too afraid of dropping behaviors, and I will not do any. Again.
Refactoring
Developers' fear of changing code drives the creation of whole the discipline named refactoring. Refactoring is also the main topic of the earlier mentioned book.
The idea behind refactoring is that we can make the software more maintainable without changing behavior if we write tests. Tests will serve as watchdogs. If any test fails while you improve a design, it indicates that you unwillingly drop a behavior.
Code should be covered by the collection of tests that will keep watch on application behaviors. We should refactor in small steps, and continuously run a set of tests that will keep us informed.
The critical thing about refactoring from a change point of view is that there aren’t supposed to be any functional changes when you refactor.
Optimization
The optimization is like refactoring, but with a different goal. We want the functionality to stay the same, but the goal is to increase performance. Optimizing can lead to dropping a behavior and the introduction of bugs too. We must apply the very same rules as in the refactoring process.
Summary
The fight between “it’s a feature” and “it’s a bug” is endless. Correct identification of the problem could lead to the rise of the company’s income or vice versa.
Refactoring and Optimizing are essential disciplines of code improvement and reasons for changing code. It has to be done slowly, wisely, and with the collection of tests that are going to watch your back.
One way of improving code design is to take advantage of design patterns. I wrote a few pieces, and you might find an interested in reading them as well.
