How often, as a programmer, you delivered new features in the beginning of the project so fast that clients could not believe it, but later, when the project got bigger, the number of lines of code grew and the number of features became larger, you started delivering features very slow? Often that was because the bad architecture of the application but mostly it was because the ugly code you were writing!
What did you do next? Well I suppose that you tried to refactor the code but you might have not succeeded because you were scared that you would introduce bugs. But keeping the code as it is wouldnt be a solution because as you know code rots as time passes, the code becomes uglier and uglier with every new feature or small change if you do not clean it. The solution would be to have unit tests, right?
If there would be tests and you would not be scared to do the refactoring of the code. But then you would need to convince your clients to spend money on refactoring working code. Most of them will not understand that refactoring will mean less money and less time spent on the long run.
I think that the best solution to this situation would be that whenever you work on a new feature or change an existing one because requirements change you should always leave the code cleaner that it was before. When see a piece of ugly written code apply one of the appropriate refactoring pattern without being scared that you might break the behaviour of the application because you are backed up by your unit tests.
Following this rule "leaving code cleaner that it was before you started working on it" and having unit tests will help you have a constant delivering time of new features, no delays because of the complexity of existing code, no bugs introduced by small changes and it will make you happier while working because you know you are delivering high quality software.
No comments:
Post a Comment