"first you learn the value of abstraction, then you learn the cost of abstraction, then you're ready to engineer" - Kent Beck
Premature abstraction is the root of all evil.
Goodbye, Clean Code (2020)
31–40 of 224 posts
Re: Goodbye, Clean Code (2020)
#32This 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 you didn't, and actually handled that properly, your abstraction will have a lot of hooks and bells and whistles to support the different behaviors, and it'll just be hell to maintain.
Data can change underneath you, sure, but I think we as humans have a much better intuition about concrete things rather than algorithms, so it's easier to abstract data in a useful way. Which is why I think that works better.
Re: Goodbye, Clean Code (2020)
#33[deleted]
Re: Goodbye, Clean Code (2020)
#34This blog is essentially a journey of self discovery arriving at https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction "duplication is far cheaper than the wrong abstraction."
The thing I hate most is when some creates the "new way of doing things". Then fails to convert most of the existing code which is "doing things the old way" even when it's clear that it is the same thing.
Re: Goodbye, Clean Code (2020)
#35This article really buries the most important lesson about refactoring: > I didn’t talk to the person who wrote it. I rewrote the code and checked it in without their input. Even if it was an improvement (which I don’t believe anymore), this is a terrible way to go about it. A healthy engineering team is constantly building trust. Rewriting your teammate’s code without a discussion is a huge blow to your ability to e…
Why one should ask to the original developer if the code can be modified? If I see a code I want to change, I do it. I don't ask for permission. And colleagues can do the same with code I wrote. We trust each other.
The student said to the teacher:
"This fence is in the way and obstructing the flow, it should be removed"
The teacher said to the student:
"If you can tell my why someone made the fence in the first place, I will allow you to remove it."
Note that this has nothing to do with "code ownership". If you worked for me and randomly changed code that you did not like, I would fire you.
Re: Goodbye, Clean Code (2020)
#36Clean code vs dirty code is not a problem here.
Rewriting someone else's code (no matter how dirty) without telling or consulting was the bigger mistake. This can poison professional relationships for life.
Re: Goodbye, Clean Code (2020)
#37Having 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 complicated (and unclean) abstraction which is arguably significantly worse than simply duplicating the code would have been in the first place. I make this remark because I think that "the code needs to be the same in a few places" may not be a sufficiently strong reason for writing an abstraction right away. Even in these cases, sometimes it's ok to leave duplication in your codebase for a little while while you let the feature you're working on shake itself out, then come back and see if the abstraction is worth writing. That's the only way to break the cycle.
Re: Goodbye, Clean Code (2020)
#38This article really buries the most important lesson about refactoring: > I didn’t talk to the person who wrote it. I rewrote the code and checked it in without their input. Even if it was an improvement (which I don’t believe anymore), this is a terrible way to go about it. A healthy engineering team is constantly building trust. Rewriting your teammate’s code without a discussion is a huge blow to your ability to e…
Why one should ask to the original developer if the code can be modified? If I see a code I want to change, I do it. I don't ask for permission. And colleagues can do the same with code I wrote. We trust each other.
If I ever see you again rewrite someone else's code without asking, I will fire you on the spot.
Re: Goodbye, Clean Code (2020)
#39Earlier quoted context omitted.
Why one should ask to the original developer if the code can be modified? If I see a code I want to change, I do it. I don't ask for permission. And colleagues can do the same with code I wrote. We trust each other.
The student said to the teacher: "This fence is in the way and obstructing the flow, it should be removed" The teacher said to the student: "If you can tell my why someone made the fence in the first place, I will allow you to remove it." Note that this has nothing to do with "code ownership". If you worked for me and randomly changed code that you did not like, I would fire you.
> If you worked for me and randomly changed code that you did not like, I would fire you.
From one extreme to the other? People make mistakes, educate them instead of brutally punishing them. Talk it through - isn't this exactly the mistake that was made by the developer (they didn't talk to their peers)? If they do not respond to feedback, that can eventually lead to a firing.
Re: Goodbye, Clean Code (2020)
#40This blog is essentially a journey of self discovery arriving at https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction "duplication is far cheaper than the wrong abstraction."
The thing I hate most is when some creates the "new way of doing things". Then fails to convert most of the existing code which is "doing things the old way" even when it's clear that it is the same thing.
Which then devolves into five ways of doing things after a few more iterations. Kitchen sink architecture.