Fantastic video. I like to put a positive spin on Michael Feather's definition: Legacy Code is *valuable* code without tests. This is why legacy code is so difficult to change, as we're naturally concerned about disrupting our users' lives. Your last point is spot on - real change happens at the organisation level. (Unless you do it on the sly, of course ... ) Thanks for all the excellent content Dave!
Im extremely lucky I found your channel. Thank you so much for sharing your knowledge and experience in a well structured and organized way. I wish I could speak my mind half as good as you - my life would've been so much easier and less frustrating ;) I'm a huge fan of the content you make. Thanks, and wish you all the best.
I would say that code with tests can still be legacy code The tests themselves could be "legacy". That is, the tests are not maintained, are not understood, do not represent real behaviors of the system, are too coupled to the implementation, etc. Just because a test exists it doesn't mean it's a good one. Second, I believe that understanding and knowledge also plays a part. You can have the perfect piece of code, modular, testable, with tests, etc, but nobody in the team knows what it is really for, nobody in the business knows what value it provides to the company, but nobody wants to remove it because there might be some other consumer that uses that code (e.g if it's a web service). Lack of understanding and knowledge makes such code legacy too.
Apt. However, this is a situation where self documenting production code as well as test code play a huge role. As they would provide the first level of insight into what exactly the "legacy code" is doing.
Thanks for doing this great little talk. I enjoyed it a lot and it gave me some things to talk about with the team. +1 to a talk about refactoring legacy code if you're willing to do one in the future... Is be very interested to watch it :-).
I was watching another of your videos and I was thinking to myself "But what if our codebase is already extant and definitely did not follow BDD/TDD in its creation?" Then this video auto-played.
One simple yet effective step in refactoring is to simply move fields to the top of the class. This way is is often more obvious what the class actually is. Also moving public members to the top. And make everything private than can be. And everything static that can be.
Your examples refer to legacy code written in *modular* languages such as C and Java. It's much harder when the language is not modular and the experts who understand it have left the company or retired.
