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!

DRY makes sense in JavaScript or I guess dynamic languages but in rust DRY is a waste of time and annoying

so now I have to re-habituate myself and it was very confusing there for a while until I had given in

Nah, the opposite of dry is making stuff generic. And if you have everything generic and your product becomes bigger, you have to implement exceptions and stuff and make the generic system support everything in the end. Making those exceptions becomes harder and harder to make it all work together. If you actually did duplicate code, for example html pages, in both pages you can implement easy an exception without breaking something else. If you want to display something on both pages, yes, ofc, you have to do that two times. But often it's better to do that. I worked at a company that did repeat itself full time regarding html templating and it was the right choice. It was for a hosting management platform. It really paid of those have a specific template for every page instead of making stuff too generic.

It's more a discussion of doing initially work 'smart' or initially work 'hard'. Also, repeated code doesn't have to be changed by hand. You can make tools to do batching.

Stripping of all frameworks, heavy agree for things that you do well understand yourself. If you understand the subject very well yourself - a framework is full of choices you wouldn't take. I'm writing my own form library now that executes server side validation and shows it life client side so it feels like client side validation. Benefit is, that I only have one layer of validation. Also this validation is applied on model level. So the database will never have wrong data, it's just not possible by design. Every field has support for regex and you can override the the validate method completely to do "check if user already exists" for username field for example.

Why write this myself? There are a lot of forms libraries. Well, in my opinion they're not good. They're general purpose and do only the minimum and if they do more, it's even worse.

Will it pay off in time spent? Not sure, but i'm 100% happy about my implementation now. That's not the case when using framework.

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.

duplicate code has to be kept in sync < you change a baseline DRY code and everything breaks everywhere for the next 2 months until you're done the refactor

generics make sense if you're making a library. you can't really make a library until you map out a bunch of use-cases, aka all use cases you think you'll ever need because this is statically typed and not dynamically, and the same problem will apply that if you need to change something in how it works that's going to be hell to refactor (though with a library you can just switch out the old version and switch in the new one under a different name... if it's not a library and instead a file it's a little more icky perhaps)

I'm finding duplicate code is a far lot saner a strategy