Earlier quoted context omitted.
Premature abstraction is the root of all evil.
There are only two hard things in Computer Science: cache invalidation and to know when not to use abstraction.
But what about naming things
Goodbye, Clean Code (2020)
71–80 of 224 posts
Re: Goodbye, Clean Code (2020)
#72Having duplication does not mean your code is not clean. Sometimes, having duplication is actually cleaner, and easier to understand. Removing duplication may introduce complexities, and force developers to untangle the additional logic that was introduced to remove dupes. Good duplication means code just happened to be the same in a few places (but it can be potentially different). It's fine and easy to read. On the…
Would you go with a simple comment/tag to denote both piece of code are identical but not abstracted away on purpose ?
I do this
// @note this code is duped in ../../some/other/file.code
Re: Goodbye, Clean Code (2020)
#73When we don’t feel confident in our code, it is tempting to attach our sense of self-worth and professional pride to something that can be measured. I don't think assuming people who disagree with you lack confidence and are "compensating" is an effective way to reach an audience. Rewriting your teammate’s code There should be no such thing as "your teammates code", there is only your team's code. If the changes were…
You should 100% talk to the original author before rewriting though. Not doing so communicates that you think you know better than them, so much better than them that you don't even need to talk to them to understand why they wrote it the way they did, and the tradeoffs. This is very arrogant and would most likely bother the original developer, which is bad for team dynamics.
Re: Goodbye, Clean Code (2020)
#74All of that would have been avoided with a code review.
Re: Goodbye, Clean Code (2020)
#75This seems close to illustrating a thought I've been toying with turning into a blog post but need some more examples of before I do: "Abstract over data, not behaviour" This seems to fall into the trap of abstracting over behaviour. The best other example I've thought of for this is the 'generic repository pattern' common in C# and I'd guess Java. Just because CRUD on types is all similar behaviour you can't really…
Ah, thank you. I never managed to put it quite clearly as that. But thinking back and considering the intuition I built around when an abstraction makes sense and when it's just going to be unhelpful cruft, boils down to this. Abstracting over behavior gets messy very quickly. Special cases will probably arise on the next requirement change. Unless they're already there and you missed the subtle interaction. And if y…
The abstraction is the standard case and should invite custom behaviour to be added dynamically. This extra behaviour should be added by the caller / user of the abstraction.
Especially in a CRUD situation, every custom procedure will probably have a few basic steps that stay the same. All you usually need is a pre and a post hook.
Re: Goodbye, Clean Code (2020)
#76Re: Goodbye, Clean Code (2020)
#77I have seen this so many times, it is not even funny anymore.
Refactoring is fine. Abstraction is fine. But programmers fall to, at some point in time, some sort of tunnel vision that drives us to use either tool to target the wrong thing.
At my current job, we have this tool to create query abstractions, a Spring Data of sorts if you will. It seems nice, and it naturally feels better than the alternative, which is allow the upper layers to issue queries themselves.
But it is wrong. All flexibility is gone. Our team is just not big enough to expand the functionalities of such library, so the queries it can handle are pretty basic. Also, there are at least five layers to go through in order to debug it, and the only thing it really does is converting objects into queries.
Of course, most API consumers have to bypass the library. It is just not flexible or powerful enough.
Moral of the story is, to accomplish a big refactor, having a clear, global vision of the long term benefits and shortcomings, is essential. Refactoring just for the sake of making something look good, is not worth the time.
Re: Goodbye, Clean Code (2020)
#78"A little duplication is better than the wrong abstraction" (https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction)
My current codebase has a lot of duplication for fairly trival things, because the previous codebase tried generic solutions, only to end up needing a lot of exceptions, which ended up making the code look messy and hard to maintain.
Re: Goodbye, Clean Code (2020)
#79Having duplication does not mean your code is not clean. Sometimes, having duplication is actually cleaner, and easier to understand. Removing duplication may introduce complexities, and force developers to untangle the additional logic that was introduced to remove dupes. Good duplication means code just happened to be the same in a few places (but it can be potentially different). It's fine and easy to read. On the…
IME abstractions generally begin with the latter case. Perhaps there's one or two corner cases that the abstraction also covers, but it seems justifiable at the time because the core of the code really ought to work the same across all cases. Then you slowly start adding corner cases, or you change your new feature slightly so that the abstraction has to change. Little by little you end up with this insanely complica…
An issue in the duplicated approach is keeping track of the different blocks once they diverge enough.
In the best case scenario they all slighty change over time without forcing complexity on each other. But it becomes a problem as changes that should be breaking only break part of the code, and the rest can go unfixed as nobody remembers all the linked bits.
It would be critical for instance if the duplicated bits were involved in invoicing procedures, and one in five remained unchanged while the other got updated.
Re: Goodbye, Clean Code (2020)
#80I'm shocked that from all discussion nobody noted the root of all evil:
"It was already late at night (I got carried away). I checked in my refactoring to master and went to bed, proud of how I untangled my colleague’s messy code."
No PR, no code review, no CI. Just a cowboy pushing to the master..