Write tests. Most likely those 300k lines of code contain a TESST folder with 4 unit tests written by an intern who retired to become a bonsai farmer in the 1990s, and none of them pass anymore. Things become much less stressful if you have something basic telling you you're still good.
The problem with complex legacy codebases is that you don’t know about the myriads of edge cases the existing code is covering, and that will only be discovered in production on customer premises wreaking havoc two months after you shipped the seemingly regression-free refactor.
It helps if tests are well written such that they help you with refactoring, rather than just being the implementation (or a tightly coupled equivalent) but with assertions in it.
Rare to see though. I don't think being able to write code automatically means you can write decent tests. Skill needs to be developed.
And the challenge with writing tests well is that it might be difficult or impossible without the refactor...
I agree. This is one area I'm hoping that AI tools can help with. Given a complex codebase that no one understands, the ability to have an agent review the code change is at least better than nothing at all.
You can infer based on code coverage. If coverage is low, tests are likely insufficient and change is risky
If you save a log of input on the production system you can feed it to old and new versions to find any changed in behavior.
The best time to write tests was 20 years ago. The second best is now, provided you've applied to all the companies with better culture.
I've been working on react and react native applications professionally for over ten years, and I have never worked on a project with any kind of meaningful test coverage
I have not seen tests in any code base I worked on in the past 20 years. I have noticed that there is some kind of sanctimonious demeanor to quite a few people that advocate for tests (on comment boards). I find the reactions to discussions on tests fascinating because it seems to elicit very strong opinions, sort of a "do you put your shopping cart back" kind of topic, but for programmers.
People who advocate “writing tests” never admit any of the costs and difficulties of automated output checking.
As you change your codebase you will experience lots of “failures” that are not failures. You still have to burn your time investigating them.
Many checks will require elaborate mocking or other kinds of setup, that give lie to the claim that designing them is simple and straightforward.
over 20 years, many stacks, and same
> I have never worked on a project with any kind of meaningful test coverage
That says more about you and the care you put into quality assurance than anything else, really.
Presumably you mean me, and every current and former team-member I've ever had? If so, you're talking about hundreds of engineers.
Have you ever worked at a place where you were put on an existing codebase, and that code has no tests? Have you ever worked at a place where, when you try to fix that, management tells you that they don't have the time to do so, they have to crank out new features?
Is ipsento606 working at such a place? I don't know, and neither do you. Why do you jump to the conclusion that it's their personal failing?