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

How to Improve a Legacy Codebase

jacquesmattheij.com

Post reply on HN
Print view View original

91–100 of 300 posts

Re: How to Improve a Legacy Codebase

#91

Post by lol768 »

Any advice on what steps to take when the legacy codebase is incredibly difficult to test?

I completely agree with the sentiment that scoping the existing functionality and writing a comprehensive test suite is important - but how should you proceed when the codebase is structured in such a way that it's almost impossible to test specific units in isolation, or when the system is hardcoded throughout to e.g. connect to a remote database? As far as I can see it'll take a lot of work to get the codebase into a state where you can start doing these tests, and surely there's a risk of breaking stuff in the process?

Re: How to Improve a Legacy Codebase

#92

Post by korzun »

markatkinson wrote: post #89
korzun wrote: post #68

> Before you make any changes at all write as many end-to-end and integration tests as you can. I don't agree with this. People can't write proper coverage for a code base that they 'fully understand'. You will most likely end up writing tests for very obvious things or low hanging fruits; the unknowns will still seep through at one point or another. Forget about refactoring code just to comply with your tests and br…

I gasped when I saw this article at the top of HN due to the relevance of it right now in my life. I am currently working on a real monolithic jambalaya that suffers from a lack of documentation, architecture, extreme abstraction, rampant tight coupling and no previous source control. Your point on performing architecture discovery and documentation is spot on. It has really helped me to strip away the mess and under…

> I gasped when I saw this article at the top of HN due to the relevance of it right now in my life.

You are not the only one :)

Re: How to Improve a Legacy Codebase

#93

Post by rocky1138 »

quadcore wrote: post #19

From what I've seen the most common mistake when starting working on a new codebase is to not read it all before doing any change. I really mean it, a whole lot of programmers simply dont read the codebase before starting a task. Guess the result, specially in terms of frustration.

Sometimes the code is so horribly written we have nothing else to try but to poke at it with a stick in different ways until it breaks.

Re: How to Improve a Legacy Codebase

#94

Post by douche »

specialist wrote: post #33

Sound advice. re: Write Your Tests I've never been successful with this. Sure, write (backfill) as many tests as you can. But the legacy stuff I've adopted / resurrected have been complete unknowns. My go-to strategy has been blackbox (comparison) testing. Capture as much input & output as I can. Then use automation to diff output. I wouldn't bother to write unit tests etc for code that is likely to be culled, replac…

> My go-to strategy has been blackbox (comparison) testing. Capture as much input & output as I can. Then use automation to diff output. I wouldn't bother to write unit tests etc for code that is likely to be culled, replaced.

I think that is precisely what the article advocates - although the definition of what end-to-end and integration tests are varies wildly from place to place.

> First step to any project is to add build numbers. Semver is marketing, not engineering. Just enumerate every build attempt, successful or not. Then automate the builds, testing, deploys, etc.

A thousand times this. And get to a point where the build process is reproducible, with all dependencies checked in (or if you trust your package manager to keep things around...). You should be able to pull down any commit and build it.

Re: How to Improve a Legacy Codebase

#95

Post by kentt »

> Do not ever even attempt a big-bang rewrite

I'd love to hear a more balanced view on this. I think this idea is preached as the gospel when dealing with legacy systems. I absolutely understand that the big rewrite has many disadvantages. Surely there is a code base that has features such that a rewrite is better. I'm going to go against the common wisdom and wisdom I've practiced until now, and rewrite a program I maintain that is

1. Reasonably small (10k loc with a large parts duplicated or with minor variables changed).

2. Barely working. Most users cannot get the program working because of the numerous bugs. I often can't reproduce their bugs, because I get bugs even earlier in the process.

3. No test suite.

4. Plenty of very large security holes.

5. I can deprecate the old version.

I've spent time refactoring this (maybe 50 hours) but that seems crazy because it's still a pile of crap and at 200 hours I don't think it look that different. I doubt it would take 150 hours for a full rewrite.

Kindly welcoming dissenting opinions.

Re: How to Improve a Legacy Codebase

#96

Post by eej71 »

OutsmartDan wrote: post #31

Big bang rewrites are needed in order to move forward faster. A huge issue with sticking to an old codebase for such a long time is that it gets older and older. You get new talent that doesn't want to manage it and leave, so you're stuck with the same old people that implemented the codebase in the first place. Sure they're smart, knowledgable people in the year 2000, but think of how fast technology changes. Change…

The issue to think about is - if you don't know enough to "upgrade/replace in place" - then you probably won't know enough to rewrite from scratch.

Re: How to Improve a Legacy Codebase

#97

Post by misja111 »

korzun wrote: post #68

> Before you make any changes at all write as many end-to-end and integration tests as you can. I don't agree with this. People can't write proper coverage for a code base that they 'fully understand'. You will most likely end up writing tests for very obvious things or low hanging fruits; the unknowns will still seep through at one point or another. Forget about refactoring code just to comply with your tests and br…

I agree with you, I don't know why you were downvoted. In my experience the first and biggest problem when taking over legacy codebases is the lack of knowledge of what features the code is supposed to support. Just starting out with writing integration test has a risk that you end up with even more meaningless code to maintain.

Actually, contrary to the advise of the writer, I like to start out with fixing some bugs. I find it a great way to gain some knowledge and it has the added benefit of keeping business stakeholders happy. And while fixing those bugs you can start writing the first integration and unit tests.

Re: How to Improve a Legacy Codebase

#98

Post by gary__ »

jacquesm wrote: post #88
apeace wrote: post #67

> Do not fall into the trap of improving both the maintainability of the code or the platform it runs on at the same time as adding new features or fixing bugs. I don't disagree at all, but I think the more valuable advice would be to explain how this can be done at a typical company. In my experience, "feature freeze" is unacceptable to the business stakeholders, even if it only has to last for a few weeks. And for…

These problems tend to be systemic, not just tech problems and usually by the time we reach this stage management is a little more amendable to things like feature freezes than what the regular crew would be dealing with. There is a reason you get to that stage. So I can see how we have (much) more freedom when it comes to setting the time table and more diplomacy and better salesmanship might be required at an earli…

Extreme planned refactoring perhaps:

"Many teams schedule refactoring as part of their planned work, using a mechanism such as "refactoring stories". Teams use these to fix larger areas on problematic code that need dedicated attention. Planned refactoring is a necessary element of most teams' approach - however it's also a sign that the team hasn't done enough refactoring using the other workflows."

https://martinfowler.com/articles/workflowsOfRefactoring/

Re: How to Improve a Legacy Codebase

#99

Post by ethbro »

apeace wrote: post #67

> Do not fall into the trap of improving both the maintainability of the code or the platform it runs on at the same time as adding new features or fixing bugs. I don't disagree at all, but I think the more valuable advice would be to explain how this can be done at a typical company. In my experience, "feature freeze" is unacceptable to the business stakeholders, even if it only has to last for a few weeks. And for…

From personal experience, a good way of approaching the sell to business stakeholders is getting them involved in the bug triage and tracking process.

You need to make the invisible (refactoring and code quality) visible (tracking) so they can see what the current state is and map the future.

The biggest reason business stakeholders push back against this is that developers tend to communicate this in terms of "You don't need to know anything about this. But we've decided it needs to be done." Which annoys someone when they're paying the hours.

I've had decent success with bringing up underlying issues on roadmaps, even to the generalness of "this feature / component has issues." It's a lot easier conversation if it's adding "That thing that we've had on our to-do list for a couple months" vs "This new thing that I never told you about."

And as far as pitching, if the code is at all modular, you can usually get away with "new feature in code section A" + "fixes and performance improvements in unrelated section B" in the same release.

PS: I love the simple counter-based bookkeeping perspective from the linked post. (And think someone else suggested something similar in a previous performance / debugging front page article)

Re: How to Improve a Legacy Codebase

#100

Post by tyingq »

kentt wrote: post #95

> Do not ever even attempt a big-bang rewrite I'd love to hear a more balanced view on this. I think this idea is preached as the gospel when dealing with legacy systems. I absolutely understand that the big rewrite has many disadvantages. Surely there is a code base that has features such that a rewrite is better. I'm going to go against the common wisdom and wisdom I've practiced until now, and rewrite a program I…

There are cases where you can do a rewrite, but still avoid the big-bang cutover, by exposing the new app only to some subset of customers or transactions. That isn't possible with every app, of course.

I think the gospel view is when you have to do both...rewrite and big bang cutover. Especially when there is no obvious fallback.

Post reply on HN