The common approach is to not invest in trying to understand the legacy code and to dismiss it's qualities. Management normally is happy to accept that and then allows ignoring it until replaced. Most of the time, that is an invalid, costly, sometimes fatal approach. Only after understanding the legacy code, one can tell whether it is any good or not. Write tests to cover it and to maintain it's proven functionality while cutting away parts that need to be replaced. The argument 'it is so bad, I can never understand it' is silly, it says more about the new programmer than about the old one.
Distinguishes intermediate engineers (people who are totally capable of designing systems, but aren't capable of delivering things inside of huge messes, so they instead avoid it and go off over in a corner and say "I've got a replacement for that messy thing, I just can't replace the ugly thing so now we have to support my new smart beautiful module, plus the old code that I couldn't understand") from senior engineers who know that the grand rewrite will never happen and, if it does, it'll happen by mostly fully understanding where things are coupled and by shipping tiny changes inside the existing code until it's been strangled and can be removed
The common approach is to not invest in trying to understand the legacy code and to dismiss it's qualities. Management normally is happy to accept that and then allows ignoring it until replaced. Most of the time, that is an invalid, costly, sometimes fatal approach. Only after understanding the legacy code, one can tell whether it is any good or not. Write tests to cover it and to maintain it's proven functionality while cutting away parts that need to be replaced. The argument 'it is so bad, I can never understand it' is silly, it says more about the new programmer than about the old one.
Another brilliantly enlightened comment.
Distinguishes intermediate engineers (people who are totally capable of designing systems, but aren't capable of delivering things inside of huge messes, so they instead avoid it and go off over in a corner and say "I've got a replacement for that messy thing, I just can't replace the ugly thing so now we have to support my new smart beautiful module, plus the old code that I couldn't understand") from senior engineers who know that the grand rewrite will never happen and, if it does, it'll happen by mostly fully understanding where things are coupled and by shipping tiny changes inside the existing code until it's been strangled and can be removed
yes