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

151–160 of 300 posts

Re: How to Improve a Legacy Codebase

#151

Post by rb808 »

_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 think its pretty common- and I think you're lucky.

I was surprised to see the article say "It happens at least once in the lifetime of every programmer,". I think if you work on greenfield projects your whole career you're likely the one who's creating these 'steaming piles of manure'.

By working on bad legacy projects you learn an awful lot of things about what works and what is a problem to maintain - it will make you a better developer.

The only issue is if you always work on legacy stuff and never get to write greenfield you might get typecast as such. Whether that is a problem of not is up to you. Sounds like you care enough you can change when/if you want to.

Re: How to Improve a Legacy Codebase

#152

Post by erikpukinskis »

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…

> re: Write Your Tests, I've never been successful with this ... I wouldn't bother to write unit tests etc for code that is likely to be culled, replaced.

I think you misread the author. He says "Before you make any changes at all write as many end-to-end and integration tests as you can." (emphasis mine)

> My go-to strategy has been blackbox (comparison) testing. Capture as much input & output as I can. Then use automation to diff output.

That's an interesting strategy! Similar to the event logs OP proposes?

Re: How to Improve a Legacy Codebase

#153

Post by stickfigure »

maxxxxx wrote: post #79

How do people handle this in dynamic languages like JavaScript? I have done a lot of incremental refactoring in C++ and C# and there the compiler usually helped to find problems. I am now working on a node.js app and I find it really hard to make any changes. Even typos when renaming a variable often go undetected unless you have perfect test coverage. This is not even a large code base and I find it already hard to…

I think you just captured the essence of why microservices are so popular. Dynamic languages just don't scale to large codebases, so there's enormous pressure to decompose software into chunks that can be digested more easily.

Some amount of this is good, but it often forces the chunk boundaries to be smaller than the "natural" clumping of data and behavior in a distributed system. IMHO this is a much worse problem than a messy monolith; you can refactor a monolithic codebase to be more modular, but refactoring hundreds of microservices is a herculean endeavor.

My problem with microservices is the word micro.

Re: How to Improve a Legacy Codebase

#154

Post by jacquesm »

d--b wrote: post #142

I agree with most of this, though I think it doesn't dive into the main problem: Freezing a whole system is practically impossible. What you usually get is a "piecewise" freeze. As in: you get to have a small portion of the system to not change for a given period. The real challenge is: how can you split your project in pieces of functionalities that are reasonably sized and replaceable independently from each other.…

I could probably do a better job of making that clear in the article. The whole point is to iterate and to lock and release parts selectively so you are never working on more than one thing at the time.

Re: How to Improve a Legacy Codebase

#155

Post by rileytg »

erikpukinskis wrote: post #152
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…

> re: Write Your Tests, I've never been successful with this ... I wouldn't bother to write unit tests etc for code that is likely to be culled, replaced. I think you misread the author. He says "Before you make any changes at all write as many end-to-end and integration tests as you can." (emphasis mine) > My go-to strategy has been blackbox (comparison) testing. Capture as much input & output as I can. Then use aut…

much like https://github.com/github/scientist

Re: How to Improve a Legacy Codebase

#156

Post by maxxxxx »

stickfigure wrote: post #153
maxxxxx wrote: post #79

How do people handle this in dynamic languages like JavaScript? I have done a lot of incremental refactoring in C++ and C# and there the compiler usually helped to find problems. I am now working on a node.js app and I find it really hard to make any changes. Even typos when renaming a variable often go undetected unless you have perfect test coverage. This is not even a large code base and I find it already hard to…

I think you just captured the essence of why micro services are so popular. Dynamic languages just don't scale to large codebases, so there's enormous pressure to decompose software into chunks that can be digested more easily. Some amount of this is good, but it often forces the chunk boundaries to be smaller than the "natural" clumping of data and behavior in a distributed system. IMHO this is a much worse problem…

"hundreds of microservices"

I can't imagine a scenario where you need hundreds although I don't doubt that people will create such a system.

Re: How to Improve a Legacy Codebase

#157

Post by rattray »

> Yes, but all this will take too much time!

I'm actually quite curious; how long does this process typically take you?

What are the most relevant factors on which it scales? Messiness of existing code? Number of modules/LOC? Existing test coverage?

Re: How to Improve a Legacy Codebase

#158

Post by rattray »

jacquesm wrote: post #32
bmh_ca wrote: 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. That's most likely not true, but looking backwards it often feels that way. The problem is that you're now a lot wiser about that codebase than you were at the beginning and if you had done that rewrite there could have easily been fatalities. But of course it feels as if the rewrite would be faster and cleaner. How bad could it be, r…

> The problem is that you're now a lot wiser about that codebase than you were at the beginning

That may not be true in this case, if the rewriter is also the original author and has remained active in the codebase over the years.

Re: How to Improve a Legacy Codebase

#159

Post by [deleted] »

bmh_ca wrote: 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…

[deleted]

Re: How to Improve a Legacy Codebase

#160

Post by kod »

jacquesm wrote: post #149
kod wrote: post #131

Earlier quoted context omitted.

Serious question - what platforms are you working on that you can't send a udp packet that looks like "somecounter:1|c"

Hehe. If you can't imagine that then you have a sheltered and probably very happy life. I don't care if it speaks ethernet, arcnet, twinax, X.25 or nothing at all, we'll find a way. By the time you can start sending UDP packets you are already on very solid footing. Be happy if your dev environment does not include an emulated version of the real hardware that mysteriously does not seem to be 100% representative of t…

Telling someone they lead a sheltered life isn't the same as actually answering the question.

What actual systems have you worked on that were connected to a database, but couldn't send UDP?

Post reply on HN