3 ms·
Two? Sure. How about when the whole application is tightly coupled so a change in one class necessitates changes in 4 others? And sure if the logic is straight
by sfn42 3y ago
Two? Sure. How about when the whole application is tightly coupled so a change in one class necessitates changes in 4 others? And sure if the logic is straight forward and simple that's fine, but add in that the code is a complete mess with a bunch of weird convoluted solutions to things and whoever wrote it is long gone so nobody knows what it's supposed to do beyond "exactly what it currently does".
I think I'm pretty good at programming but that's generally what I've been doing in my career and to me it's incredibly difficult. Not that much new code, just a lot of wrangling shitty old code and in retrospect regretting that I didn't just delete it and write everything from scratch.
- josephg 3y agoBad code is still bad code. And correctly abstracting everything is still the ideal. Abstractions are like hinges. Too few and everything is a big fused mess. Too many and your system is a wobbly mess you can get lost in. You need the right abstractions in the right places. For my money the way to do that is to start with as few abstractions as possible and only add them in the places you need them, when you need them. Start simple and refactor as you go. If you try to predict where the abstractions go before you’ve designed your system, you’ll get it wrong and then you’ll either leave your code with bad abstractions or spend far longer than you had to refactoring. (Since refactoring is harder the more code you have).