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

41–50 of 74 posts

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

#41

Post by bsder »

Maybe the technical aspects of the book are okay.

However, the big problem with legacy code is always political. And the only book I've seen ever try to address that is "Kill It with Fire".

It's one of the few books that talks about the need to keep your team motivated and plugged into the political system given that they are working on the thing that's super important but also almost invisible. You need to be constantly selling what is going on in front of the important eyeballs.

Unfortunately, a lot of the anecdotes have an undercurrent of "Until the system has actively exploded into a million pieces such that somebody with real power has their ass on the line, don't bother."

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

#42

Post by guardian5x »

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.

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

#43

Post by zabil »

commandlinefan wrote: post #10

Kind of depressing to read because it's so accurate, yet so likely to be ignored. I remember when Martin Fowler first published the book "Refactoring" - I was so relieved at the time because somebody with some clout that executives might actually listen to had not only identified what was wrong with software but identified a way to fix it and even gave it a name! Boy was I wrong - now you have to be careful how and w…

Part of this is on developers. Refactoring is fine, but too often it turns into yak-shaving and nothing ships. The approach usually works: refactor in small steps and tie it to a feature so it’s testable and adds value.

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

#44

Post by pydry »

commandlinefan wrote: post #10

Kind of depressing to read because it's so accurate, yet so likely to be ignored. I remember when Martin Fowler first published the book "Refactoring" - I was so relieved at the time because somebody with some clout that executives might actually listen to had not only identified what was wrong with software but identified a way to fix it and even gave it a name! Boy was I wrong - now you have to be careful how and w…

It's not a phenomenon specific to refactoring. Humans just arent good at appreciating abstract gains or abstract risks.

The proliferation of technically clueless managers of tech projects and their "control systems" such as scrum has exacerbated the problem.

I met some doctors recently that made some rhyming complaints when non-medical mba management took over a practice.

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

#45

Post by tome »

PaulHoule wrote: post #23
commandlinefan wrote: post #10

Kind of depressing to read because it's so accurate, yet so likely to be ignored. I remember when Martin Fowler first published the book "Refactoring" - I was so relieved at the time because somebody with some clout that executives might actually listen to had not only identified what was wrong with software but identified a way to fix it and even gave it a name! Boy was I wrong - now you have to be careful how and w…

My feeling about it is that there is not a tension between refactoring and feature work but rather that a specific bit of feature work is best done with a refactoring. For instance about 10 components on a certain page I was working on all had the same accessibility problem which involved changed the HTML and then changing the CSS so this is a good chance to make a single component which can be used to replace the pr…

Yes, I have the same experience. Most of my features are implemented as double figures of tiny refactoring commits to prepare the code so that the feature can be implemented in a straightforward way.

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

#46

Post by pkdpic »

Love this resource, really looking forward to perusing the full text.

And to echo what others are saying I have spent the last month experiencing for the first time how not simple throwing a meaningful test suite together is for a ginormous legacy codebase. I was glad the author briefly seemed to acknowledge that but still... the pain...

They said the playwright ui was supposed to make it easy... Just plug it into an LLM they said... It should just take a few days right?

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

#47

Post by internet_points »

The most important part:

> You have to deal with Legacy Code every day.

Legacy code is code you didn't write. It used to be that code you didn't write was written by past team members. These days, we have legacy-code-generators that write code you didn't write at a much higher rate then your company can fire team members.

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

#48

Post by arkh »

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…

> And I can't even call any tests because I can't extend a non existant class, there's no objects in here!.

I'm gonna preach for the church of "away with unit tests": so what? You don't want to test code. Code is not what the user care about.

You want to test behavior. And for this you don't need to extend classes. You should not have to rewrite any code from your application. Like you say: write tests at the seam. Automate user inputs and checking outputs.

A good test suite should not need to be rewritten during refactoring. It should even allow you to change language or replace for an off-the-shelf solution you did not write. If a unit test suite does not allow that, unit tests are an impediment. And I don't care about the "test pyramid", like the IRL ones, it is just a relic; from an age when launching all your tests in parallel was unfathomable.

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

#49

Post by eschneider »

zabil wrote: post #43
commandlinefan wrote: post #10

Kind of depressing to read because it's so accurate, yet so likely to be ignored. I remember when Martin Fowler first published the book "Refactoring" - I was so relieved at the time because somebody with some clout that executives might actually listen to had not only identified what was wrong with software but identified a way to fix it and even gave it a name! Boy was I wrong - now you have to be careful how and w…

Part of this is on developers. Refactoring is fine, but too often it turns into yak-shaving and nothing ships. The approach usually works: refactor in small steps and tie it to a feature so it’s testable and adds value.

Very much this. There's no need (and certainly never time) to add tests to the world or refactor everything. But it's often practical to figure out "I need to make changes "here" and add tests for that section and do whatever cleanup helps for that bit.

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

#50

Post by SideburnsOfDoom »

arkh wrote: post #48
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…

> And I can't even call any tests because I can't extend a non existant class, there's no objects in here!. I'm gonna preach for the church of "away with unit tests": so what? You don't want to test code. Code is not what the user care about. You want to test behavior. And for this you don't need to extend classes. You should not have to rewrite any code from your application. Like you say: write tests at the seam. A…

> You don't want to test code. You want to test behavior. A good test suite should not need to be rewritten during refactoring.

100% agreed.

> I'm gonna preach for the church of "away with unit tests"

I disagree with the semantics here.

From the article: "In short, your test is not unit if it doesn’t run fast or it talks to the Infrastructure (e.g. a database, the network"

This says _nothing_ about what part of the app structure you test. It's not always a class-method test. Outside-in, behaviour centric tests that are not close-coupled to structure, can also be unit tests. And most of the time, it's a better kind of unit test.

Kent Beck said many times: "tests should be coupled to the behavior of code and decoupled from the structure of code."

"test behavior" was the original intent of unit tests. The idea that unit tests are only close-coupled class-method tests, or that testing 2 collaborating classes from the same app at once counts as an "integration test" is a latter-day misconception. A dumbing down.

Post reply on HN