3 ms·
> The idea that, basically, bad code no one ever has to touch again is in fact good code How do you know no one would ever have to touch that code again, at th
by pkolaczk 4y ago
> The idea that, basically, bad code no one ever has to touch again is in fact good code
How do you know no one would ever have to touch that code again, at the moment of writing it?
Nevertheless, generally I agree that isolated complexity is much better than complexity that spreads everywhere through explicit or hidden dependencies (e.g. global state). So dirty complex code hidden behind a simple API is actually not bad code.
- Mr_P 4y agoThis is literally the 'O' in SOLID. The key idea is to break code into "chunks" that each do one thing. Then, if you have to add a new feature, it goes into another chunk, instead of editing/modifying existing code. The same logic applies to system design at different scales, whether fine-scale OOP or coarser-scale (micro)service architecture. The ideal size of an individual "chunk" is somewhat subjective & debatable, of course. It's like Haskell-style immutable data structures, but applied to writing the code, itself.
- giraffe_lady 4y agoIt's less a guideline for writing code than one I use when deciding where to spend my efforts with existing code. I've mostly worked in long-lived codebases of profitable software, so nearly everything is a strong candidate for refactoring off of "quality" alone. When you find something real blood-curdling but the last commit in that file was three and a half years ago, you just close it and pretend you didn't see. Better to spend the effort somewhere it will definitely benefit someone soon, rather than maybe some day.