Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The key points of "Working Effectively with Legacy Code"

understandlegacycode.com

Post reply on HN
Print view View original

51–60 of 74 posts

Re: The key points of "Working Effectively with Legacy Code"

#51

Post by dotancohen »

tonyedgecombe wrote: post #40
drzaiusx11 wrote: post #31

Earlier quoted context omitted.

From personal experience with bosses: no, often times it's not a sufficient argument. If the choice is thought to be between: * delivering value directly to the customer to justify a company's existence * or adding tests to things that already work (shore up) in an effort to make more correct changes in the future Will anyone be surprised how often it's the former that management will go for? I've found the appetite…

>Will anyone be surprised how often it's the former that management will go for? I don't think I have ever asked permission to do make what I thought was the correct change.

That's because you're not opening Jira tickets titled Refactor Foobar. You're just doing it as a consequence of resolving real business issues. I have seen developers, and once been the developer, suggesting a refactor to the PM. That rarely works: it does not (directly) address a business goal.

Re: The key points of "Working Effectively with Legacy Code"

#52

Post by eschneider »

th0ma5 wrote: post #21
Lovesong wrote: post #17

I understand and I agree with the author points, specially looking to distance yourself from the dependencies these systems are usually entangled with, however: >But the code examples are in Java and C++ and I do python/JavaScript/ruby/ The problem with real legacy code is that sometimes it's not even in those languages. It's VB.NET, COBOL, AS400, BASIC, FORTRAN...and these may not have a chance to "wrap around your…

I've skimmed the source material and it doesn't either except for the general advice of putting it all in some kind of conceptual box and slowly move parts to modern or better managed solutions as you try to reverse engineer it all. The underlying subtext was that it is all probably worse than you think and there isn't much good news... But "containment" in various forms is the direction forward mostly unfortunately.

TBF, that approach works and you won't go years w/o any deliverables with that approach.

Re: The key points of "Working Effectively with Legacy Code"

#53

Post by dotancohen »

ebiester wrote: post #4
allemagne wrote: post #2

I read through this book relatively recently and agree with the praise here for the core idea that legacy code is code that is untested. The first few chapters are full of pretty sharp insights that you will nod along to if you've spent a decent amount of time in any large codebase. However, most of the content in the last half of the book consists of naming and describing what seemed like obvious strategies for refa…

I think of the second half much more as reference. I can give it to a junior engineer or early mid-level and say "here is an example." It's harder if they can't read the older examples, but I can google for a more modern example as well. It gives nomenclature and examples.

  > It's harder if they can't read the older examples, but I can google for a more modern example as well. It gives nomenclature and examples.
Don't do that. Ostensibly you're giving these people the book so that they'll learn to deal with legacy code. Those older examples are exactly what they need to see, even if they're in a language that those devs are not using.

Re: The key points of "Working Effectively with Legacy Code"

#55

Post by yakshaving_jgt »

guardian5x wrote: post #42

It's easy to say 'write tests', but it's difficult to do so if you don't know what the actual requirements are. People often think they are doing it 'properly' now by starting simple, but as they learn more and add functionality, they end up with the same complex mess they wanted to avoid.

Right, but not knowing what tests to write is feedback that your [yet to exist] tests are trying to tell you.

Re: The key points of "Working Effectively with Legacy Code"

#56

Post by shahindohan »

The only issue I have with writing tests before refactoring is that sometimes it can take a really long time to write those tests and cover all the cases, not to mention needing to sometimes refactor to make the code even testable.

I've made huge successful refactors using nothing but carefulness and manual testing, maybe just a very little bit of unit testing :)

Re: The key points of "Working Effectively with Legacy Code"

#57

Post by gnulinux996 »

I feel like there is a need for a new paradigm on navigating code; and reference documentation for that matter.

I like how https://gwern.net and https://en.wikipedia.org allow you to hover over terms and show you a quick glance of a term you might not know, and then you can fan out to create an understanding for the basis needed to understand the material in front of you. I feel like some sort of windowing system where I can pin and move references around and then kinda have the llm explain or reference things might be of use to me, as in help me navigate the unknown. Is there a "study companion" application of the sort?

I find that this is easier to do with a language like Java than say Python, I need as much information as I can in order to understand the decisions that led to the current implementation.

Sometimes when I want to change some piece of legacy code, I need to know the rationale behind the code written here, although keeping the interfaces the same and changing the implementation allows me to go quite far.

Re: The key points of "Working Effectively with Legacy Code"

#58

Post by hiatus »

osigurdson wrote: post #37
kens wrote: post #29

Earlier quoted context omitted.

I read the book shortly after it came out, when I was working on an enormous system of legacy code. Unfortunately, I didn't find the book particularly helpful in terms of strategies for understanding or modifying legacy code. Yes, tests are a good thing, but I expected the book to provide a lot more. I agree with the parent comment that it is useful to follow the "trail" through the code. It can be a big effort just…

>> Yes, tests are a good thing, but I expected the book to provide a lot more It is strange, actually, how much value we place on any information that sits between two pieces of cardboard.

Wait till you hear about how much we value information stored in meat!

Re: The key points of "Working Effectively with Legacy Code"

#59

Post by jt2190 »

shahindohan wrote: post #56

The only issue I have with writing tests before refactoring is that sometimes it can take a really long time to write those tests and cover all the cases, not to mention needing to sometimes refactor to make the code even testable. I've made huge successful refactors using nothing but carefulness and manual testing, maybe just a very little bit of unit testing :)

I like to make the distinction that the absence of automated tests is not the absence of tests altogether, and that the time it takes to get an automated test set up might be longer than doing the test manually. This is especially important to be aware of if the tests will be temporary because the code is about to be changed.

Of course the goal is to reach an end state with automated tests, but insisting on 100% automated tests up-front can actually prevent the refactoring from even starting.

Re: The key points of "Working Effectively with Legacy Code"

#60

Post by sciurus »

avgcodor wrote: post #32

I've replaced a few large legacy systems over the years and I disagree with most of the points mentioned in the link. The only way guaranteed to work is to run the old system concurrently with the new system with live inputs and compare results for a trial period and fixing discrepancies as they arise. Only when there is 100% behavioral/data fidelity with the old system can a switchover to the new system occur. I'm n…

You're assuming the "legacy" system is being replaced by a new one, which isn't the scenario being described in the link or the book. They cover approaches for continuing to safely evolve the legacy (i.e. untested) system.
Post reply on HN