I don't use Ruby, and don't do OOP either, but my favourite talk is still Sandi Metz's "All The Little Things" and I think that's where she says "prefer duplication over the wrong abstraction." That's really changed me. I've since been seeing DRY and other misapplied dogma in a new light and have grown much over the years since.
Goodbye, Clean Code
261–270 of 599 posts
Re: Goodbye, Clean Code
#262I’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…
That can be boiled down to the “Rule of 3”. My CTO often asks me to implement a feature to do X and make it “generic enough to handle future use cases”. My answer is always the same - either give me at least three use cases now or I am going to make it work with this one use case. If we have another client that needs the feature in the future then we will revisit it. Of course, there are some features that we know in…
The Rule of 3 is a great rule, except when it isn't.
I had a colleague some time ago who wrote a couple of data importers for FAA airspace boundaries. There were two data feeds we cared about, "class airspace" and "special use airspace". These airspace feeds have nearly identical formats, with altitudes, detailed boundary definitions, and such. There are a few minor differences between the two, for example different instructions for when a special use airspace may be active. But they are about 95% the same.
The developer wrote completely separate data definitions and code for the two. The data definitions mostly looked the same and used the same names for corresponding fields. And the code was also nearly the same between the two (in fact exactly the same for most of it).
It was clear that one importer was written first, and then the code and data structures were copied and pasted and updated in minor ways to create the second.
Because the data structures were unique for each (even if they looked very similar in the source code), this impacted all the downstream code that used this data. If you saw a field called FAA_AIRSPACE_MIN_ALTITUDE, you had be sure to not confuse the class airspace vs. special use airspace, because each of these had a field of the same name, the compiler wouldn't catch you if you used the wrong one, and you may have the wrong offset into the data structure.
I asked the developer and they told me, "I have this philosophy that says when you have only two of something, it's better to just copy and paste the code, but of course when you get to the third one you want to start to think about refactoring and combining them."
Yep, the Rule of 3.
In this case there were only ever going to be two. And the two were nearly the same with only minor differences.
But because of blind obedience to the Rule of 3, there were many thousands of lines of code duplicated, both in the importer and in its downstream clients.
I still like the Rule of 3 as a general principle, and I have espoused it myself. But I think it is best applied in cases where the similarities are less clear, where it seems that there may be something that could be refactored and combined, but it's not yet clear what the similarities are.
I think it is a very bad rule in a case like this, where it should be obvious from the beginning that there are many more similarities than differences.
Re: Goodbye, Clean Code
#263Earlier quoted context omitted.
One of the areas where I really like "incidental duplication" is in tests. Tests can sometimes be very repetitive and identical, and it's tempting to want to refactor it in some clever way. That's almost never good. On top of the reasons laid out in parent comment, tests also function as unofficial documentation. I like having everything explicit in there, it makes them easier to read and understand.
If you try to abstract away tests, you often just end up re-implementing the same abstractions used in the actual code, and you can end up not catching unfounded assumptions that your abstraction is making in both the tests and the code. There is a scope for having test helpers / utils to make tests easier to write, but you should be minimalist with these.
I agree, but some test helpers are reasonable. It's about balance and readability of the tests in question. Otherwise integration tests end up being a hundred lines of code.
Re: Goodbye, Clean Code
#264I don't use Ruby, and don't do OOP either, but my favourite talk is still Sandi Metz's "All The Little Things" and I think that's where she says "prefer duplication over the wrong abstraction." That's really changed me. I've since been seeing DRY and other misapplied dogma in a new light and have grown much over the years since.
Great quote. Link to the talk? When you say you don't use OOP, are you saying you use functional languages or you use imperative languages but don't do any of the OOP design crap?
Re: Goodbye, Clean Code
#265I have a Google One subscription so I pay Google for storage. Google could suspend my account and I'd have no recourse whatsoever? I'd have no way of getting my 10s of thousands of photos back?
Whoops, this comment was intended for a different post hah
Re: Goodbye, Clean Code
#266> A healthy engineering team is constantly building trust. Rewriting your teammate’s code without a discussion is a huge blow to your ability to effectively collaborate on a codebase together. I'm against the idea that people should be attached to "their" code (that is: the code they wrote). Now I also understand that humans that humans, but the priority should be to make them evolve toward more detachment from their…
> the priority should be to make them evolve toward more detachment from their work and acceptance that what they design "can" (actually will) be imperfect
In an ideal world, sure, but I've worked with enough people varying from professional-but-proud[1] to emotional-maturity-of-a-child to understand that this _shouldn't_ be prioritized, on grounds of feasibility. You may as well say "we don't need reasonable workdays, we need to teach employees to jettison their biological need for sleep".
I don't think it's _impossible_ to get people to be fully detached from their code, but I think that it's only possible in fairly narrow situations (perhaps in a small, tight-knit, talented team culture). Trying to get it to work in a general context is usually much more effort (and lower chance of success) than meeting it halfway with tweaks to communication style and process.
[1] To be fair, I'm quite sure I've slipped into this mode on occasion myself
Re: Goodbye, Clean Code
#267> I suggest to think deeply about what you mean when you say “clean” or “dirty”. I'd go one step further: I suggest to think deeply. Period. I used to think I was a slacker for taking one or two hours to go for a stroll during a work day, thinking hard about my code, my problems, the architecture, the abstractions... and daydreaming as well. I had to shut down my inner Jiminy boss who was telling me that an hour with…
Balancing thinking and doing is one of the Hard Problems™ of software development. I suspect successful methodologies work because they formalize the act of thinking about the code before implementing it. And that when methodologies fail the reason could be that they can easily be implemented such that people think more about the technicalities (assigning work, deadlines, estimation accuracy etc.) than the development (modularity, overlap with existing work, conflicts with concurrent work, security, third party dependencies etc.).
Re: Goodbye, Clean Code
#268I don't use Ruby, and don't do OOP either, but my favourite talk is still Sandi Metz's "All The Little Things" and I think that's where she says "prefer duplication over the wrong abstraction." That's really changed me. I've since been seeing DRY and other misapplied dogma in a new light and have grown much over the years since.
Great quote. Link to the talk? When you say you don't use OOP, are you saying you use functional languages or you use imperative languages but don't do any of the OOP design crap?
Been using mostly Elixir full time (w/ some JS here and there) for the last 3 years.
Talk link: https://youtu.be/8bZh5LMaSmE
Re: Goodbye, Clean Code
#269Waste of time.
Re: Goodbye, Clean Code
#270Earlier quoted context omitted.
> Then you need to start passing options and configuration into your helper method... and before long your helper method is extremely difficult to reason about In which case, you should split the helper function ( extract sub-part common to all cases, and report the differences where the helper function is called). I think I would most of the time go with de-duplicating as early as possible, as long as the helper fun…
> Duplicated code causes many issues. You mentioned introducing bugs, but it also makes the code harder to read That is I believe contestable. Yes, it can end up easier to read but there is a big tradeoff - when you remove code from its context it is much harder for a reader to reason about it. Once something is extracted into a function you can't see, you have to mentally ask the questions like "could this return nu…
[deleted]