I think the best we can do as software engineers working on legacy code bases is stop making assumptions about authors of the code and do not think that we are smarter and could do better.
Legacy code is not just a text. It's a big amount decisions made for a reason. What we lack is a history of those changes. So if we see something we call "anti-pattern" or "code-smell" we need to think twice is it really the case or we are missing something.
Inexperienced programmers tend to simplify things and swear at bad code. They think that they could design this code better and assume million of things about the code and its authors. I think it's unprofessional.
We need to avoid making assumptions if we have no real evidence. Be cold-minded. Refactor and improve step by step. And don't rush to rewrite huge code bases from scratch: are we sure we won't end up with the same code mess and we are smarter than authors of legacy code?
I think the best we can do as software engineers working on legacy code bases is stop making assumptions about authors of the code and do not think that we are smarter and could do better.
Legacy code is not just a text. It's a big amount decisions made for a reason. What we lack is a history of those changes. So if we see something we call "anti-pattern" or "code-smell" we need to think twice is it really the case or we are missing something.
Inexperienced programmers tend to simplify things and swear at bad code. They think that they could design this code better and assume million of things about the code and its authors. I think it's unprofessional.
We need to avoid making assumptions if we have no real evidence. Be cold-minded. Refactor and improve step by step. And don't rush to rewrite huge code bases from scratch: are we sure we won't end up with the same code mess and we are smarter than authors of legacy code?