Comment by dgb23
9 months ago
Clean code, design patterns etc. were also picked up by teachers, professors and course instructors.
I think these paradigms and patterns often operate on the wrong layer of abstraction, while mostly ignoring the things that matter the most, like efficiency, error handling and debugging.
But getting good at these things requires a lot more blood, sweat and tears, so there's no easily teachable recipe for that.
Clean Code is trying to operate at a layer far more important than efficiency: code maintenance. In the vast majority of cases computers are fast enough that you don't need to worry about efficiency. (part of this is any modern language provides all the common algorithms that are already highly optimized and easier to use than the writing them by hand and so the common places where you would want to worry are already efficient).
Of course error handling and debugging are part of maintenance. However there is a lot more than those two that need to be considered as well.
There is reason to hate Clean Code, but the worst adherents to the rules are still producing far better code than some of the impossible stuff that happened before. "Goto considered harmful" is one of the early steps in fixing all the bad things programmers used to do (and some still do), but you can follow the "rules" of goto considered harmful and still produce really bad code so we need more.
From personal experience, the most time consuming maintenance issues arise because of the following things:
- third party dependencies, compatibility issues, breaking changes
- code that is bloated with abstractions and indirection
- performance issues, especially when worked around via caching etc.
- bad error handling
- inconsistent data
Simpler code that can be followed and stepped through in a straight forward manner avoids 3/5 of these from the get go. Patterns and abstractions that emerge over time are sometimes beneficial. Legacy code or third party code that overuses abstractions is really more of a hindrance and significantly slows down how fast I can understand, own and fix things.
IME the most time consuming maintenance issues are due to inconsistent code, which is usually a result of trying to avoid "abstractions and indirection" and keep it straightforward. A bunch of classes that just call each other is annoying, but trying to solve that by inlining the code results in something worse.
2 replies →
It sounds like you have been lucky enough to avoid some of the worst code practices of history. Good for you.
I hope you can come up with a good answer to fix the problems you cite. I haven't seen anything I have confidence in.