Duplication is far cheaper than the wrong abstraction.
https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstracti...
Goodbye, Clean Code
81–90 of 599 posts
Re: Goodbye, Clean Code
#82So the two cases against writing the most legible, succinct code given the specifications at the time of writing it are: >Firstly, 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…
The code is not large enough to need maintenance at a fine-grained level. There is a secondary rule to the DRY "rule of three": If I can blow it away and rewrite it so easily, there is nothing to reuse or refactor in it. The feature is done, and we are into code golf and speculation, neither of which are productive uses of time. In my experience the success rate of speculative refactors like the one author made has p…
The author also didn't sound like a particularly senior engineer at the time for many reasons. So the original code author and the "boss" may have been taking into consideration timelines and future work/requirements coming down the pipe.
A very valid reason could have been as simple as "We are re-visiting this in a couple sprints after feedback and will have a better idea of how it needs to change. The extra day spent on this wasn't worth pushing getting it into peoples hands, and we don't know if it would be a waste." The author would have known this if he started a conversation about it.
Re: Goodbye, Clean Code
#83To me the #1 thing that fixes the social issues described in this post (changing code someone checking in code a few hours after they pushed it) is a code review process. The most valuable thing about always doing pull requests and code review is sharing information and having discussion about changes, not necessarily the immediate improvement of the code. A team will gain more knowledge about what everyone is doing by reviewing each others pull requests than they do from a daily standup by a pretty large margin in my opinion.
In this particular example, reviewing a PR would have meant that a discussion about whether or not that abstraction was a good change before the code was ever merged.
Re: Goodbye, Clean Code
#84The first thing I did when I read this was come to the HN comments and search for people complaining about DRY:
https://news.ycombinator.com/item?id=22022599
https://news.ycombinator.com/item?id=22022842
https://news.ycombinator.com/item?id=22022896
https://news.ycombinator.com/item?id=22022836
The author of this piece was not engaging in a DRY activity even if he thought he was. He (perhaps unwittingly) admits to it himself:
> My code traded the ability to change requirements for reduced duplication, and it was not a good trade.
The acronym DRY was coined in The Pragmatic Programmer, and the author of that book makes it clear that DRY is about not repeating requirements in code. You definitely don't want to deduplicate similar code if it involves multiple requirements because then you entangle yourself, which is what the author of this piece did.
Re: Goodbye, Clean Code
#85To me this sounds like he gave up on producing something with craftsmanship. It sounds like he's getting bullied by someone of lessor experience.
If the code was blainently duplicated, that's going to create problems later.
Re: Goodbye, Clean Code
#86The first thing I did when I read this was come to the HN comments and search for people complaining about DRY: https://news.ycombinator.com/item?id=22022599 https://news.ycombinator.com/item?id=22022842 https://news.ycombinator.com/item?id=22022896 https://news.ycombinator.com/item?id=22022836 The author of this piece was not engaging in a DRY activity even if he thought he was. He (perhaps unwittingly) admits to it…
Are you saying that they're repeating themselves?
Re: Goodbye, Clean Code
#87Code is not clean : code is cleanable. What is clean today might not be clean tomorrow (Robert C. Martin, author of the book "Clean Code")
Trying to evaluate code cleanliness in isolation is a waste of time ; as it strongly depends on the way your requirements evolve (but it's not subjective). You only need abstraction points at the frontiers between parts of your requirements that change at different times.
Duplication is better than a wrong abstraction (Sandi Metz, author of Practical Object Oriented Design in Ruby).
Trying to religiously factorize every structural similarity you can find, for the sake of the almighty DRY principle, without taking into account how business requirements evolve, is counterproductive.
Re: Goodbye, Clean Code
#88I’ve usually heard this phenomenon called “incidental duplication,” and it’s something I find myself teaching junior engineers about quite often. There are a lot of situations where 3-5 lines of many methods follow basically the same pattern, and it can be aggravating to look at. “Don’t repeat yourself!” Right? So you try to extract that boilerplate into a method, and it’s fine until the very next change. Then you ne…
Good generics can be really helpful here.
Can't be specific without knowing the exact helper function but I find sitting down with a cuppa (away from the computer) and planning an interface (If it's C++) that accepts (say) a policy class with a default and a callable object ("Functor") very helpful.
Sometimes it can't be done but it's better to have a bugfree building block (Macros don't count!) that can accept buggy user defined tasks than lots of repitition.
Re: Goodbye, Clean Code
#89The article didn’t mention if the team that wrote the dirty code had done a code review. If they did, it doesn’t mention whether the author of the article looked at the interaction between the code author(s) and the reviewer. Perhaps this was discussed and the repetitive code accepted with good reason?
When code is merged, it should be too late for further discussion. The review is done and flaws like this is debt that should be taken care of the next time someone needs to touch it.
Re: Goodbye, Clean Code
#90Earlier quoted context omitted.
Go error handling is a good example of this. So far all the attempts to reduce the repetitive `if err != nil { ... }` through some abstraction failed. Look at https://github.com/golang/go/issues/32825
In the language maybe but both Rust and Zig show that it's possible to have much less 'bloat' for error handling even without using exceptions. I'd say that go designers have still work to do: Zig especially show that you can be a 'simple' language and yet have both sane error handling and generics.
If someone else is looking for examples too, I found those:
https://www.reddit.com/r/Zig/comments/99zlc9/exceptions_or_e...