This is how you grow your web app indefinitely:
1. Strip the codebase of all frameworks
2. Ban DRY principle. Don't reuse the code, period.
3. When feeling the urge to write a unit test, refactor the code instead.
4. When seniors “discover” a new “paradigm” that applies to the codebase and want to make a framework, rotate them.
5. Profit!

Not only do you have to find all occurrences of something to change it, but you're strictly forbidden from automatically checking that they're the same for future reference, and you've fired everyone who knew the complete list because they invariably attempted to formalize the dispatch in code to mitigate the chaos.

Instant legacy project powder, stir in a glass of cold cash for 2 years for an accurate imitation of a 20 year old codebase.

Nah, just hire manager, or better two and your codebase will become infinite!

Pile

Of

Crap

@lorentz have you tried my strategy? Because I tried both mine way and the industry standard way, and mine worked better. Less team burnout, quicker delivery times, fewer bugs, higher morale.

Also, “rotate” here doesn't mean “fire”, it means moving them to another project/area of the codebase.

@kiki You evidently have more data than me, but the project I'm currently on is suffering from those exact issues. Duplicate logic in innumerable places that has to be kept in sync manually, domain knowledge gone with the original authors, no unit tests meaning constant hidden breakage, and lucky initialization due to a shitty bespoke DI scheme that didn't work everywhere and so later work didn't even use it. Anyone with even close to a sweeping knowledge of the codebase is assigned to fix the constant stream of stupid bugs that could be caught easily if we had multiple layers of automated tests rather than one or two e2e UI tests per feature.

I'll readily believe that you did these things and your teams were happy and productive, but it wasn't just because of this, you did something else really well that isn't trivial, because I cannot pinpoint why this project is in such a shit state.

@lorentz one year ago, if you asked me to name one thing that made all the difference, I would've named sinking hours upon hours into designing the DB schema. As some smart programmer said, if you get your data structure right, the rest of the code just writes itself.

But if you ask me now, I'll say it was the principle of one file per route, no matter the LOC length. Code is copied and pasted, never reused. Even if the file is 5000 lines long (never happened, may happen in the future), you KNOW that if a route breaks, the bug IS within this file. And you know that if you change anything — anything at all — within the logic of one route, the remaining routes won't change at all.

During my 10 years of experience, I only had like 3 cases when I had to change every route. Yet I had a LOT of cases when had to change just one route's logic without touching anything else, but it was hard because of the cult of DRY. Everything is an import, everything is a shared trait. Bwaagh.

@lorentz I'll admit that in this knucklehead hardcore DRY environment, unit tests are islands of sanity in this stormy ocean of shit. But if it's just one file, and there are no GOTO statements because it's JS, then… yeah, you already know that I didn't need unit tests.