How to Improve a Legacy Codebase
jacquesmattheij.com
How to Improve a Legacy Codebase
1–10 of 300 posts
Re: How to Improve a Legacy Codebase
#2I work on my own side projects, read lots of other people's code on github and am always looking to improve myself in my craft outside of work, but I worry it's not enough.
Re: How to Improve a Legacy Codebase
#3[1] https://www.safaribooksonline.com/library/view/working-effec...
Re: How to Improve a Legacy Codebase
#4FWIW, 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/knockout/tko
You can see the rough transition strategy here: https://github.com/knockout/tko/issues/1
In retrospect it would've been much faster to just rewrite Knockout from scratch. That said, we've kept almost all the unit tests, so there's a reasonable expectation of backwards compatibility with KO 3.x.
Re: How to Improve a Legacy Codebase
#5(Speaking from experience from work)
Re: How to Improve a Legacy Codebase
#6I 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…
Re: How to Improve a Legacy Codebase
#7How 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 one thing you can do is attempt to isolate the code surrounding the next chunk you work on. Do as much as you reasonably can of the things the article mentions. This may only be writing tests and adding logging, but if it's an improvement over what's there, you'll improve the experience of the next person involved with that code.
I'd warn you against jumping ship in hopes of finding a "clean" code base. Most code is somewhere on a spectrum of "maintainable enough" and something... grimmer.
If you really are unhappy and don't feel like you're growing or have the ability to grow, maybe try out contributing to a well-maintained OSS project. If you find yourself immensely happier, dust off your resume ;)
Re: How to Improve a Legacy Codebase
#8How 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…
Re: How to Improve a Legacy Codebase
#9Re: How to Improve a Legacy Codebase
#10I 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…
An excellent talk about this is "The Scandalous Story of the Dreadful Code Written by the Best of Us" by Katrina Owen [0]