Live data from Hacker News

How to Improve a Legacy Codebase

jacquesmattheij.com

21–30 of 300 posts

Re: How to Improve a Legacy Codebase

#21
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…

Frankly, I never quite understood the importance of clear documentation until I found one such code base smoldering on my porch.

Re: How to Improve a Legacy Codebase

#24
post #17
post #4

I mostly agree with this - bite-sized chunks is really the main ingredient to success with complex code base reformations. FWIW, if you want to have a look at a reasonably complex code base being broken up into maintainable modules of modernized code, I rewrote Knockout.js with a view to creating version 4.0 with modern tooling. It is now in alpha, maintained as a monorepo of ES6 packages at https://github.com/knocko…

> In retrospect it would've been much faster to just rewrite Knockout from scratch. Why do you say that? The idea one could get it right writing from scratch is one of those seductive thoughts, but in my experience it never works out that way.

Amen. By the time (if ever) the rewrite has reached feature parity with the original, it is as bad as the original.

Also second system syndrome.

Re: How to Improve a Legacy Codebase

#25
post #17
post #4

I mostly agree with this - bite-sized chunks is really the main ingredient to success with complex code base reformations. FWIW, if you want to have a look at a reasonably complex code base being broken up into maintainable modules of modernized code, I rewrote Knockout.js with a view to creating version 4.0 with modern tooling. It is now in alpha, maintained as a monorepo of ES6 packages at https://github.com/knocko…

> In retrospect it would've been much faster to just rewrite Knockout from scratch. Why do you say that? The idea one could get it right writing from scratch is one of those seductive thoughts, but in my experience it never works out that way.

> Why do you say that? The idea one could get it right writing from scratch is one of those seductive thoughts, but in my experience it never works out that way.

Of course the alternate route – rewriting - is just a hypothetical so we can only suppose how it would've turned out.

That said, rewriting from scratch would've been pretty straightforward, since the design is pretty much set.

The real value of the existing code resides in the unit tests that Steve Sanderson, Ryan Niemeyer, and Michael Best created – since they illuminated a lot of weird and deceptive edge cases that would've likely been missed if we had rewritten from scratch.

So I suspect you are right, that it's just a seductive thought.

Re: How to Improve a Legacy Codebase

#26
post #14

Are there businesses building automation and tooling for working with legacy codebases? It seems like a really good "niche" for a startup. The target market grows faster every year :)

Specifically to do what?

- Help developers build a high level understanding of the code and relationships between modules (with millions of lines, this is extremely hard)

- Automate refactoring code to reduce complexity and cross-dependencies

- Automate rewriting parts of code in mode modern languages and replacing it with some mediation layer (protobuf etc)

I think industries like finance would welcome with open arms something that can do this. And it could go for a high price if it's still saving them money on countless hours of developer time. It's a growing cost every year to maintain legacy code that was written 3+ developer generations ago, and it's dangerous in cases where peoples' lives depend on the code being bug-free (infrastructure, medical)

I started thinking about this problem a few days ago in a thread about AI https://news.ycombinator.com/item?id=14430652

Re: How to Improve a Legacy Codebase

#27

Delete it... (Speaking from experience from work)

Is there someone who left the legacy code and became beneficial?

As a result of my work experience, it was more beneficial to delete the legacy code and only provide the necessary functions when renewing the system.

Re: How to Improve a Legacy Codebase

#29
I used to work on a messy legacy codebase. I managed to clean it, little by little, even though most of my colleagues and the management were a bit afraid of refactoring. It wasn't perfect but things kinda worked, and I had hope for this codebase.

Then the upper management appointed a random guy to do a "Big Bang" refactor: it has been failing miserably (it is still going on, doing way more harm than good). Then it all started to go really bad... and I quit and found a better job!

Re: How to Improve a Legacy Codebase

#30
post #4

I mostly agree with this - bite-sized chunks is really the main ingredient to success with complex code base reformations. FWIW, if you want to have a look at a reasonably complex code base being broken up into maintainable modules of modernized code, I rewrote Knockout.js with a view to creating version 4.0 with modern tooling. It is now in alpha, maintained as a monorepo of ES6 packages at https://github.com/knocko…

KnockoutJS is hands down my favourite JS library of all times (it's a large part of why I build things in a structured better way (I was/am primarily a backend dev)), it's awesome to see that it has a modern future since I have quite a few projects using it and 'porting' will be a lot easier so thanks for the amazing work you are doing :).
Post reply on HN