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

51–60 of 300 posts

Re: How to Improve a Legacy Codebase

#51

Post by jacquesm »

deedubaya wrote: post #46

Yeah, I've done this. It's frustrating and easy to burn out doing it because progress seems so arbitrary. Legacy upgrades are usually driven by large problems or the desire to add new features. Getting a grip on the code base while deflecting those desires can be hard. This type of situation is usually a red flag that the company's management doesn't understand the value of maintaining software until the absolutely h…

> This type of situation is usually a red flag that the company's management doesn't understand the value of maintaining software until the absolutely have to.

Recent conversation with the manager of a company: "I've yet to see anybody give me a good reason why we need to maintain the software we already built if it work."

No kidding.

Re: How to Improve a Legacy Codebase

#52

Post by chiph »

cafard wrote: post #21
_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…

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

At the very least, write a doc that explains how to build the product, including where to find the parts in source control, what the dependencies are, what servers it'll get installed on, and so on.

The goal being to increase your shop's "Bus Factor"

https://en.wikipedia.org/wiki/Bus_factor

Re: How to Improve a Legacy Codebase

#53

Post by humanrebar »

weef wrote: post #38

Great advice. Writing integration tests or unit tests around existing functionality is extremely important but unfortunately might not always be feasible given the time, budget, or complexity of the code base. I just completed a new feature for an existing and complex code base but was given the time to write an extensive set of end-to-end integration tests covering most scenarios before starting my coding. This prov…

> Writing integration tests or unit tests around existing functionality is extremely important but unfortunately might not always be feasible given the time, budget, or complexity of the code base.

Bottom line: If the project cannot afford to properly maintain the code, it's a failure of the business model. Projects can be maintained indefinitely, but it costs money. And that means the project has to bring in enough money to pay for those maintenance costs.

The options, as I see them:

1. Accept that this particular project, and those that intimately depend on it, has a lifecycle and will eventually die, either slowly or quickly. Prepare for that fact, staying ahead of the reaper by quitting, transferring to another project, etc.

2. Build a case to leadership that the project is underfunded long-term. This takes communication skills, persuasion skills, technical skills, and political skills. You'll need to go to all the stakeholders in their frame of reference and explain the risk involved in fundamentally depending on legacy code.

Anyway, engineers tend to see the "legacy code" problem as a technical one. It is in the sense it takes technical work to fix it. But the root cause is a misallocation of resources. If the needed resources aren't there in the first place, the problem is a bad business model.

Re: How to Improve a Legacy Codebase

#54

Post by mannykannot »

WRT architecture: In my experience, you would be lucky if you are free to change the higher level structure of the code without having to dive deeply into the low-level code. Usually, the low-level code is a tangle of pathological dependencies, and you can't do any architectural refactoring without diving in and rooting them out one at a time (I was pulling up ivy this weekend, so I was primed to make this comment!)

Re: How to Improve a Legacy Codebase

#55

Post by yeukhon »

artursapek wrote: post #26
yeukhon wrote: post #14

Earlier quoted context omitted.

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 t…

I think some of this already exists using APM and code analysis. The only issue is existing toolsets often display ugly diagrams in like ER format or some flow diagram. Hard to read.

Re: How to Improve a Legacy Codebase

#56

Post by humanrebar »

jacquesm wrote: post #48
humanrebar wrote: post #47

Earlier quoted context omitted.

> In retrospect it would've been much faster to just rewrite Knockout from scratch. You're getting a bit of pushback on this sentiment, so I'll play devil's advocate a bit here. I've tried gradual refactors in the past, with poor results, because unfocused technical teams and employee turnover can really kill velocity on long-term goals that take gradual but detailed work. That is, replacing all those v1 API calls wi…

The rewrite only works - in my experience, YMMV - if the team is already 100% familiar with the codebase as it is and the task is a relatively simple one and there is a nice set of tests and docs to go with the whole package. Outside that boundary you're set up for failure.

I agree about the YMMV part. The same caveats, small scope and developers with expertise, apply in the gradual migration plans as well in my experience. It's clearly true in the extreme cases (python2 -> python3) and I've seen the same patterns happen inside companies as well.

Re: How to Improve a Legacy Codebase

#57

Post by Anderkent »

lloeki wrote: post #10
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…

> bite-sized chunks is really the main ingredient to success with complex code base reformations. An excellent talk about this is "The Scandalous Story of the Dreadful Code Written by the Best of Us" by Katrina Owen [0] [0] http://www.kytrinyx.com/talks/scandalous-story/

Is anyone else flabbergasted by the amount of effort required to mock a function call in Go, as described by this talk?

Like, when at 3:20 the presenter says there's a thing you can do that makes it utterly trivial to test this feature, I immediately assumed she'll just have to write some mocks for the `comm` package, and plug that in. Cool, I guess she'll talk about a nice mocking library or something, or there's some business complexity involved where the comm package is particularly stateful and so difficult to mock.

But no. The big difficulty seems to be that the language doesn't allow you to mock package-level functions; and so before you can mock anything you have to introduce an indirection - add an interface through which the notify package has to call things, move the code in the comm package into methods on that interface, correct all code to pass around this interface and call methods on it.

Why would you choose to work in language that makes the most common testing action so painful?

Re: How to Improve a Legacy Codebase

#58

Post by tjalfi »

artursapek wrote: post #9

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 :)

Semantic Designs[0] is one of several companies that sells software for working with legacy codebases and programming language translation. [1] is a SO post by one of their founders that describes some of the difficulties in programming language translation.

[0] http://www.semdesigns.com/

[1] https://stackoverflow.com/a/3460977/3465526

Re: How to Improve a Legacy Codebase

#59

Post by jacquesm »

mannykannot wrote: post #54

WRT architecture: In my experience, you would be lucky if you are free to change the higher level structure of the code without having to dive deeply into the low-level code. Usually, the low-level code is a tangle of pathological dependencies, and you can't do any architectural refactoring without diving in and rooting them out one at a time (I was pulling up ivy this weekend, so I was primed to make this comment!)

That's a good point I'll update the post. Thank you.

Re: How to Improve a Legacy Codebase

#60

Post by _pmf_ »

chiph wrote: post #52
cafard wrote: post #21

Earlier quoted context omitted.

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

At the very least, write a doc that explains how to build the product, including where to find the parts in source control, what the dependencies are, what servers it'll get installed on, and so on. The goal being to increase your shop's "Bus Factor" https://en.wikipedia.org/wiki/Bus_factor

> At the very least, write a doc that explains how to build the product, including where to find the parts in source control, what the dependencies are, what servers it'll get installed on, and so on.

... in the form of a Jenkins build configuration. (If possible; if the system requires legacy compilers that only run on old Windows versions or a proprietary compiler for an embedded target, good luck.)

Post reply on HN