How to Improve a Legacy Codebase • Hacker News Board

Re: How to Improve a Legacy Codebase

#111

Post by jacquesm » Tue, May 30, 2017, 3:56 PM UTC

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…

10k loc is very very minor league. You can do anything you want on a base that size, it won't matter.

100's of thousands to millions of loc is a lot more problematic, many moving parts and weird interplay is to be expected.

Re: How to Improve a Legacy Codebase

#112

Post by anilshanbhag » Tue, May 30, 2017, 3:56 PM UTC

sz4kerto wrote: post #105

The OP has so many reasonable, smart-sounding advice that doesn't work in the real world. 1) "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." Thanks. However, in many situations this is simply not possible because the business is not there yet so you need to keep adding new features and fix bugs. And still,…

While the advice sounds cool, doing one feature at a time is often impractical. I recently moved an old app with spaghetti Jquery to Vue. The paradigm is completely different. What ended up happening is I had a base that worked, moved a set of features at a time from the old to the new. This is more like rebuilding the git history from a new base compared to doing incremental one change at a time that the article advocates.

Re: How to Improve a Legacy Codebase

#113

Post by ef4 » Tue, May 30, 2017, 3:56 PM UTC

Yhippa wrote: post #104

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…

Not a dissenting opinion but I'd love to see some case studies on rewrites. As a consultant this is a frequent request and will probably be big business in the future as people migrate off of expensive legacy mainframe or other applications from the 80's, 90's, and possibly 2000's.

It's not "rewrite" that's bad, it's thinking you can cut over to a new system in a "big bang".

Rewrites are definitely common and beneficial, but the successful ones always run the new code and the old code side-by-side for an extended period of time. Which means you're still tending and caring about the old code, even as you strive to direct most of your effort into the new code.

Re: How to Improve a Legacy Codebase

#114

Post by taude » Tue, May 30, 2017, 3:56 PM UTC

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…

To help others with this strategy of blackbox/comparison testing, it's also often called "characterization" testing [1]. (In case you want to read more about this strategy.)

[1] https://en.wikipedia.org/wiki/Characterization_test

Re: How to Improve a Legacy Codebase

#115

Post by hacker_9 » Tue, May 30, 2017, 3:57 PM UTC

sz4kerto wrote: post #105

The OP has so many reasonable, smart-sounding advice that doesn't work in the real world. 1) "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." Thanks. However, in many situations this is simply not possible because the business is not there yet so you need to keep adding new features and fix bugs. And still,…

But.. all these things do work in the real world. Keeping refactorings to a separate commit is important as when you break something, you can just roll it back. Countless times I've seen new people come in and try refactoring things to their liking as they work on some other feature. Then when it later breaks some component they didn't know about, we have to unpick their commit and manually separate out the crap 'refactoring' they did and the actual feature they were working on.

End to end tests are great to test the system actually works as expected as per the requirements spec. You should know how to write this, else.. how are you even testing your feature to begin with after you've written it?

And big rewrites always take longer than people think, which can sink a business if they're not careful with their resources and don't manage their time appropriately. All in all, these points you've mentioned all seem actually very reasonable to me.

Re: How to Improve a Legacy Codebase

#116

Post by pinaceae » Tue, May 30, 2017, 3:59 PM UTC

First and foremost, do not assume that everyone who ever worked on the code before is a bumbling idiot. assume the opposite.

If it's code that has been running successfully in production for years, be humble.

Bugifxes, shortcuts, restraints - all are real life and prevent perfect code and documentation under pressure.

The team at Salesforce.com is doing a massive re-platforming right now with their switch to Lightning. Should provide a few good stories, switching over millions of paying users, not fucking up billions in revenue.

Re: How to Improve a Legacy Codebase

#117

Post by b0rsuk » Tue, May 30, 2017, 3:59 PM UTC

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…

The application may be a steaming pile of crap, but you probably don't have as much knowledge of the problem domain as the creators did. You will get there, over time. Starting a complete rewrite throws away the bad parts, but it also throws away accumulated knowledge.

Re: How to Improve a Legacy Codebase

#118

Post by pc86 » Tue, May 30, 2017, 3:59 PM UTC

sz4kerto wrote: post #105

The OP has so many reasonable, smart-sounding advice that doesn't work in the real world. 1) "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." Thanks. However, in many situations this is simply not possible because the business is not there yet so you need to keep adding new features and fix bugs. And still,…

A "big-bang rewrite" means rewriting the entire app from scratch. So if you're rewriting pieces as modules you are by definition not doing a big-bang rewrite.

Re: How to Improve a Legacy Codebase

#119

Post by hinkley » Tue, May 30, 2017, 3:59 PM UTC

sz4kerto wrote: post #105

The OP has so many reasonable, smart-sounding advice that doesn't work in the real world. 1) "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." Thanks. However, in many situations this is simply not possible because the business is not there yet so you need to keep adding new features and fix bugs. And still,…

#1 is just refactoring.

Make the change simple, then make the simple change.

They only know it took you three days to implement the feature. They don't need to know how you spent the first 2 days.

Paying down that debt allows the team to scale larger and maintain velocity longer. If they don't like your rate of delivery now, how are they going to like it when the code calcifies and everything takes twice as long?

Re: How to Improve a Legacy Codebase

#120

Post by anarazel » Tue, May 30, 2017, 4:00 PM UTC

xemdetia wrote: post #43

_virtu wrote: post #2

How does one get better if they only ever work in code bases that are steaming piles of manure? So far I've worked at two places and the code bases have been in this state to an extreme. I feel like I've been in this mode since the very beginning of my career and am worried that my skill growth has been negatively impacted by this. I work on my own side projects, read lots of other people's code on github and am alwa…

I generally clear my head by reading mailinglists and looking at how projects of my interests do things and keep their commits in order, especially around bugfixes. OpenBSD is a fun one to read through as well as others. I also go to/watch talks about people managing their own piles of manure and change processes. As long as you keep your eyes open to other people doing what your organization is struggling with right…

> I've been planning on reading the Postgres 9.6 changes for parallel queries to understand how they did the magic in a sane and controlled manner and shipped a working feature.

Very incrementally - we've been adding more and more infrastructure since PostgreSQL 9.4. Which finally was user visible with some basic parallelism in 9.6, which'll be greatly expanded in 10. There's some things that we'd have done differently if we'd started in a green field, that we had to less optimally to avoid breaking the world...