So buy the book, read it, apply the ideas.
Totally true. But give me those unit tests, and I can tell that the code is sh*t.
If I have trouble understanding the source, it could be because it's doing complicated stuff. It could be highly optimized. It could I'm too dumb.
If I have trouble understanding the unit tests demonstrating what the code does, there is either something wrong with the tests or the implementation. Fix it, rinse repeat.
I wasn't saying that unit tests or code coverage are a panacea or that TDD guarantees great code. But it's a tool. It's better than writing documentation, but it serves more or less the same purpose. Sometimes it's useful, sometimes not. And its complete absence is usually a bad smell.
I think Michael Feather's book demonstrates how code improves by simply making it testable https://www.oreilly.com/library/view/working-effectively-wit...
From memory, the argument is that once you have automated regression/characterisation tests with sufficient coverage around the part of it you need to change, you're in a good position to attempt to make a change since you will be alerted if you are unintentionally introducing regressions. Without automated tests you can't efficiently and confidently make changes without significant risk of regressions. Feathers' book discusses testing and refactoring techniques to take OOP-ish application code that has no automated tests and get enough tests in place to let you change what needs to be changed in a controlled way.
A consequence of Feathers' definition of legacy code is that fresh code you wrote yesterday in a trendy programming language still gets classified as legacy code if you didn't also write the supporting test suite to help others maintain it in future! It's not a perfect definition, some might find it provocative, but it's both pragmatic and actionable.
A different take on legacy code could be something like Peter Naur's paper 'Programming as Theory Building' [n]. I don't believe Naur specifically discussed legacy code, but the rough idea is that each program has a corresponding theory (relating to the problem domain, organisational constraints, the implemented solution and its structure, alternative solutions that were considered and rejected, etc). Some of this theory can be written down in artefacts such as design docs, requirements or comments in the code, but for a software project to be alive, the theory needs to live inside the heads of enough of the team who are building and maintaining the software. If that is lost (e.g. the team departs and a fresh team is hired to replace them) then no one in the new team may understand the "theory" so the software project is effectively dead until the new team learns the problem and solution space and develops their own new theory.
I'd regard such a "dead" software project where none of the current maintainers understand the theory behind the existing code as being legacy code -- but this is a joint property of the people working on the codebase and the artefacts (source code, design docs etc), it isn't a property of the code base in isolation. Maybe "legacy code" is the wrong way of framing it as it misses the importance of the relationship between the maintainers, the codebase and the surrounding context, and something like "dead project" is a little more helpful.
[f] https://www.oreilly.com/library/view/working-effectively-wit... [n] https://pages.cs.wisc.edu/~remzi/Naur.pdf