3 ms·
> I have seen many examples where developers thought they were improving code quality by implementing some pattern or architecture but actually made it worse.
by sdevonoes 5y ago
> I have seen many examples where developers thought they were improving code quality by implementing some pattern or architecture but actually made it worse.
> - Code quality is quite subjective and the field is driven by opinions and fads.
Agree. In almost every team I have been part of, when discussing code quality there was almost never consensus regarding what's good and bad.
Besides, in almost every company I have worked for, modules (or products) were usually refactored after 3 years or so (as in: the code that deals with retrieving data from the DB remains almost intact, but everything else is moved out to its own repository: the frontend as microfrontend and a new in-between layer (call it a proxy or "backend for frontend"))... so there was never a huge motivation to write quality code, just to write "good enough" code.
- deleted 5y ago[deleted]
- goostavos 5y ago>when discussing code quality there was almost never consensus regarding what's good and bad. FWIW, I've found that the best way to approach dragging a team in a new direction is to not focus on what "quality" is at all, but see if everyone can agree on what the problems are. I think if you can get people aligned on the problems -- specifically high level 'above the code' ones like "X keeps breaking" or "X is really hard to change" -- you can sneak quality into the discussion without it being an attack on any individual developer's code. "why is X hard to change" can become a conversation about loose coupling, cohesion, state, etc..