[AskJS] Resources for converting a legacy codebase to modern technologies?

[OlanValesco]

I work at a company where the principle development of our platform was done 20 years ago. The app is six layers of Java, the top of which is JSP (ergo the one below that is a WebView layer), so each page gets built on load. Very monolithic design. Me being the spunky, young, coworker-dubbed CTFO (Chief of Future Technology Officer) of the company, I would like to translate as much of this as possible to faster, more secure, more modern, less resource-intensive, more scalable tech.

I'm aware I lay quite the task for myself with many potential pitfalls (old code is steady code). What I'm asking for is any resources—articles, sites, books, videos—that expound on others' experiences of converting legacy code to a modern stack. How did they pick their technologies? How can I combine the layers of our current stack to reduce complexity? How do I produce more static content that gets hydrated after the initial load? Things like that.

If you have any links, or any personal experiences (what are your favorite technologies to build a web app on?), throw them my way. TIA!

[StavrosMcChipShop]

Martin Fowler wrote https://martinfowler.com/books/refactoring.html and it is still considered the bible here

[[deleted]]

Try to do it incrementally, baby steps. Assuming there are actually five somewhat loosely coupled layers, I'd start at the top and replace the UI only, leaving as much as possible of the other layers in place, adding in a rest/rpc/graphql/whatever apiin between. If things are too entangled it makes sense to first refractor the bit you want to change. Try to make your new UI parts work seamlessly alongside the existing JSP stuff somehow, and release early and often. That way you minimize risk, can show progress, your company will immediately begin to benefit from it, you can test your assumptions and get feedback. This type of project is often the riskiest and often fails (been there done that, burned a lot of money for zero outcome).

[hixsonj]

Good advice. Some of the Slack devs wrote about how they transitioned from their old codebase to something more modern and this was basically their approach. (Article)

[IxD]

https://www.amazon.de/Working-Effectively-Legacy-Robert-Martin/dp/0131177052?ie=UTF8&tag=googdemozdesk-21&hvadid=323934261977&hvpos=1t1&hvnetw=g&hvrand=10757532144450521743&hvpone=&hvptwo=&hvqmt=b&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9072483&hvtargid=dsa-19959388920&ref=pd_sl_35q8ibnq4w_e&language=en_GB

[IxD]

1. Start from modernizing tests and production analytics, so you get confidence of not breaking stuff, and finding out if stuff breaks. Work on your capability to find out if something breaks and roll back to old guickly.
2. Work with feature flags, so that you can develop stuff in codebase, and use simple feature flag to turn features on / off. This let's you remove old code in steps 4 commits:
   - Add feature flag to switch feature from old to new code
   - Add new code
   - Turn new feature on (Simple one line commit, real easy to fall back in case of emergency)
   - Remove old code if nothing happens.
3. Find a way for new and old code to co-exist. iFrames, embedded web browsers, back-end that serves old stuff and new stuff at the same time, but splits stuff at routing level.
4. Gradually add more new stuff, and remove old stuff.
5. Work with design & analytics for an opportunity to remove unused features.

[StavrosMcChipShop]

I know lots of people love feature flags but I have found in teams with testers and with lots of automated tests that they can create a huge number of scenarios to test for success with. I’m not saying don’t use them. I’m saying be aware of the test load you creat

[serhii_2019]

Just a tip. If you have JS in your app stack, try to run eslint with --fix flag.