You are receiving this email because you signed up for my newsletter. If it was a mistake or you want to be removed then you can unsubscribe at any time. No hard feelings
Two words I have never heard within good context. For most engineers, those two words will instantly turn any project into a maintenance nightmare. After all, who wants to be working on code that is old, hard to maintain, and probably has no test framework built around it. Not to mention deployments for such projects are typically risky and require multiple "hands-on" steps.
Have you ever stopped to think about what makes something "legacy code"? If I were to place a bet, my guess is the majority of developers would synonymize it with "old code". You know the type. Cobol, Fortran, or similar languages no longer supported.
Sure, I think that can be true, but I don't think that it has to be true. There is plenty of Cobol software running in the wild these days. Why? It works. its quirks are known, and most importantly, it solves a business need. Remember, our job is to solve a problem; not to use the latest and greatest language.
Think back to the legacy code you have worked on. Did it feel like it was written haphazardly? Was it hard to follow what was going on? What was the structure of the code like?
I propose one big contributing factor to legacy code is inconsistency in style, structure, and architecture.
Stay with me a moment. Are spaces actually better than tabs? Does it matter if curly braces are always on a new line? Who cares if you have a blank line between logical blocks of code? is a line length of 80 characters the best?
The answer to all of those is a resounding YES - and NO! It doesn't matter! What does matter is you have a style and stick with it. Get your entire team on board.
If you always put curly braces on a new line but your co-workers don't; then that makes legacy code.
If you like to use async/await, but the rest of the codebase uses promise.then/catch; then that makes legacy code.
If half the team is indenting with 4 spaces and the other half with tabs; then that makes legacy code.
Don't believe me? Go look at some code you feel is legacy. Not "old code" mind you - old code is fine. Instead, find code you hate to maintain, code that is hard to follow, or code that just "feels" wrong. Look at the style. Is it different somehow?
If the overall style is the same, maybe the paradigms being used are different. Is it using for-loops while everything else is using forEach? Maybe it uses flags for stats instead of enums like the rest of the architecture. Those details are important.
Look, I'm not saying one style is better; I'm saying get your entire team on board and use a style. It doesn't matter what. Some tools can format code for you. Linters can check paradigms.
After working over 15 years on various teams across multiple programming frameworks and languages, I can tell you the biggest factor to making code feel legacy is inconsistency.