Got hired for a new software engineering job? Chances are, you’ll end up maintaining a legacy system at least until the new application is up and running.
If you’re lucky, that shiny new application is not outdated and troublesome even before its official launch date.
Like it or not, eventually you’ll end up maintaining some sort of old system. Some of us have been doing this day in day out for the past decade.
On the bright side, this quickly teaches you how (not) to do things. One quickly realizes that the first systems to fail in production are those without an active test system whatsoever, something that drastically decreases developer/maintainer confidence.
As one might expect, bad code makes maintenance a headache… and at times, even makes it impossible. However, this is not always the main difficulty. In fact, if the code follows most of the SOLID principles, it may still be amazingly tough to work with (in particular, with a sufficiently complicated system).
What really matters is consistent code.
Why Consistent Code?
Once you get the hang of that weird-looking code, you can devise a way of replacing it en masse, either through plain search & replace, or with a little bit more logic by a small script. All that remains is a decent review of the changes. Bonus points if tests will cover the changes automatically and if you’re using a strongly-typed, compiled language.
On the other hand, a codebase following most best practices but utilizing tonnes of different design patterns would be a nightmare to work with in such a scenario. Typically, one would have to go by piece by piece, hoping that the darker and more obscure parts of the application, (even the best systems out there have these), do not lash out viciously at every change.
What about Best Practices?
Follow them! But make sure to keep everything consistent:
- avoid having two (or more) competing systems working in parallel
- migrate everything immediately when you decide to use some new shiny concept/component
- standardize coding style and agree on acceptable quality limit – applies particularly to teams
- keep your code well documented, or at least make it self-documentable