Thank you so much GUYS 😁 Really appreciate it! It feels good to know that there are more than just one way to solve the problem. I’m getting that book ASAP! And for the people in the comment section, Thank you so much for sharing your experience!
My experience with legacy code has always been far from pleasant. And it usually involves transitioning from initial confusion, through to anger, followed by incremental stages of understanding, and finally into contemptuous abandon - because it's always culminated in the realisation that the person(s) responsible for the code didn't care and were likely subject to the exact same "just make the thing work" external pressure that only grows with time. Although I will at least add a comment of apology when I've knowingly slapped a bandaid on code cancer.
Git it first, its the first critical thing you must do Make legacy raker branch, rebuild it on a clean virtual machine to be shure that there are no errors in build and deployment system Interactuve debugger the only tool you can do anything Draw huge amount of schemes manually with paper and pencil, to grok intrtnal structure Cover all existing code wiyh tests, while not doing any change in this code Start to do tiny refactoring steps and test suite on every change Rollback to previuos version, or use meld fir comparing code with original
A rewrite is ALWAYS a bad idea... UNTIL it's not. Here are some problems, some were mentioned in the video: You have parallel development. You aren't writing new bug-free code, so you also have parallel bugfixes. Also, you must deploy 100% feature parity, there is NO iteration. The legacy product went through a LOT of iteration and bugfixing. To the customer, your rewrite must be 100% feature complete, and 100% bug-free. Which is impossible.
I thought from the thumbnail that this was going to be a discussion about the Michael Feathers book but it’s only mentioned in passing while they reminisce about past projects.
Working on legacy project sucks.I am working on core banking application for 6 months .The code was written in 2004 and it is garbage .First you need to learn JSF and JSF sucks.Methods have 300-600 lines of code and strange logic.One method can go on Db for 6x times and debugging is hell.Working on this projects is not worth a money and stress.There is no progress because you are fixing old code and use someones logic that maybe is not good.You can only learn bad programming practices .You should be up to date with newest technology for this example Java with REST and Angular a not with Java and JSF or JSP
I had an internship at a pretty big firm (not like google but still making millions each year) and their entire codebase was in Delphi. Just because the founder used to develop in Delphi and "wanted to understand what his employees wrote". Their IDE had a memory leak so it was common practice to close and start the IDE again each 20 minutes. And the IDE was no longer maintained. My talk-to-person also told me that its usual for new employees to take a year to get into the codebase.
I have heard the claim that rewriting legacy code is almost always a mistake. While I can agree that rewriting code just for the sake of it is the wrong approach, I can't agree that it is a bad thing when done right for the right reasons. When you have hacks doing it then sure, it won't turn out well. I've done a few rewrites of legacy systems over the years and never had any problems and the result was always praised as being better than the original. So I can't completely get behind that claim.
You guys did not hear about state machine maybe where there switch inside infty loop. Or that is more probable legacy spaghetty maker did not know that idea, and monkey patched this state loop.
Is it required to build some special translator or transpiler which can eat legacy code, do analysis which we want on the codebase and throw out some Java code with reborned app?
i got the task of working with a app that was build in a php-cms and then a other php-cms copy then make to replace it and the way this then was publish was just copy the coming cms in to the old one, and then other guys then modified both cms systems so must that the time to make any thing new in it was just ... well, fix this by writing down all the features i could find and then talking with customers, i made a new node.js app, with no real problems, it was just so easy, but i was a little lucky, plus node.js or more like JS is so easy to work with, you do not need to use the high amount of time that is needed for languages with static types.
I used to work for a software company where parts of the application were considered 'black boxes' as none of the dev knew completely how the code worked. They would pass data in and get data out and, at times, post process the output to get the results they wanted. No one wanted to spend the time and money to rewrite these parts of the code base. It was a shame as new features would often get dropped because of the development overhead in dealing with this code.
What I do sometimes is to find smaller cases of pain. let's say a widget... and rewrite that, not all the system that feeds data to the widget. just the widget. and go on, and on, and on ... The other most important thing to approach like that is to have a team supporting you, if you're alone tasked with solving the widget in page B instead of fixing the widget itself... you the team to be aboard with then applying the new fixed/improved widget to the whole site when time's available.
