Hacker News Reader

Hacker News

Comment by sdevonoes | Hacker News Reader

Full thread

sdevonoes

I found out that some fellow engineers do not want to write maintainable code, they instead want to write code that:

- follows SOLID principles

- follows Clean Code principles

- follows Hexagonal architecture principles

- ...

Sometimes such principles do lead to maintainable code, but, most of the time they don't (at least in my limited working experience of around 10 years). An example: If you duplicate code because at the end it seems to be the proper way to write a piece of functionality that will be easier to maintain in the future (and most importantly, it communicates clearly its intention)... well, that's a no-go for some fellow engineers because, somehow, that violates all or some of the principles they have read in some blog post owned by internet celebrities.

View on HN

Yeah, obsession with DRY to the detriment of readability and maintainability does happen. If you need to write another script like the one you wrote yesterday (but slightly different, and you don't know exactly how different), then starting with a copy&paste is a valid strategy. As you go on you will realize the common points of both scripts, and then you can DRY them both. Or not, if the common parts are too few to bother. Creating complex class hierarchies to "promote reuse" before there even is a case for reuse could be seen as premature optimization or YAGNI.

On the flip side, in my experience, people with certain amount of years under their belts tend to treat all those principles in a way they should be, ie. as inspiration instead of as law.

This is something I've seen described as "optimizing for deletion" which is the only way to have true modularity.

Yes! And deleting large amounts of code from a massive tightly-coupled monolith is a great way to learn that first-hand. I like to say that you learn a lot more from dealing with a legacy monolith than you do by implementing the latest clean patterns. It eliminates a lot of cargo-cult mentality and lets you really see what patterns make the difference.

My personal pet-peeve is when the obsession with DRY carries over to testing. Testing is not the place for DRY. Reading a test should be like reading a recipe: do A then do B, then do C, then expect result X. When you start abstracting the setup to the nth degree it becomes much harder to understand the test because you have to click around the code to following the abstractions like a trail of bread crumbs, when really what you want is for the stack trace to say "error on line 123" and the cause to easily found near line 123. Tests shouldn't be dry, they should be wet.

This might be a reference to WET (write everything twice): https://dev.to/wuz/stop-trying-to-be-so-dry-instead-write-ev...

It's a trade off for sure. I have seen people write test code with no regards to DRY and it results in tests that are hundreds of lines of setup trying to wire up the inputs and the expectations when a little bit of thought to remove all that repetitive code would go a long way in making the tests readable.

I do agree that there doesn't need to be obsession with DRY when it comes to writing tests (esp when you are bouncing around multiple functions and files just to understand the testcase) but completely abandoning it either isn't great either.

Usually hunderds of lines of set up code point out the issue in the code itself -it's usually a smell of a god object/function that has too many responsibilities

I've run into exactly this, where each developer has their own test setup abstraction and attempt at automation. Difficult to add your own tests and difficult to fix theirs. It's maddening.

A sensible suggestion i've found in regards to code duplication and DRY is the rule of three: https://en.wikipedia.org/wiki/Rule_of_three_(computer_progra...

If you run into the same code three times, that's when you consider refactoring. Of course, in practice it can be ignored like any rule as long as you keep the ideas behind it in mind (small amounts of duplication are usually manageable).

Sometimes you have a shared context which might indeed use the same code and you'll want to apply DRY sooner, whereas other times you'll have code that is the same only incidentally, but is a part of two or more different contexts which may evolve independently.

Edit: If only we had tooling on top of Git to give us hints about how the codebase has evolved over time, like: "Hey, this file is 84% similar to this one other file, which was added under ISSUE-2415 3 years ago by $PERSON for $PURPOSE. Click here to see the current diff between these files and how they've evolved over time."

The current workflows around git blame feel lacking, especially if you are ever dealing with files that have been deleted (e.g. the "origin" for the current file was actually a different file that was deleted way back for another reason that you won't know about now without digging through the Git history for thousands of commits).

A faulty/clumsy abstraction is worse than duplication.

And writing your abstraction before you have two or three different uses for it can often make it clumsy and/or faulty.

The key is this: If you have to change one, do you have to change all copies? The problem is not duplicated code; the problem is duplicated concepts.

DRY was a response to cut-and-paste programming, not thoughtful application of the same (or similar) code to different problems.

The problem often arises when two pieces of code happen to look the same, but are conceptually doing two different things.

I have seen far too many codebases where a junior engineer took it upon himself to DRY-ify two similar looking bits of code, only to have to later go start adding knobs and if-branches to handle differing evolution between the two problem domains.

If the original piece of code had some logic bug, sure, it will likely be necessary to go fix that bug in all of the duplicated spots. But if the code evolves in one place due to the problem domain changing slightly, that rarely implies that the duplicated code needs to change.

I coined it initially for configuration management, but... "Keep accidental an intentional identity apart".

By that I try to convey that just because two things look the same doesn't mean that they are by necessity the same. So if it is a case of "happens to look the same", keep things separate, but if they're fundamentally linked, keep only one copy and reference it.

In terms of code, I think that means "repeat the codepath if the two copies just happen to look the same today, but are not necessarily going to do so in the future" and "if the code paths are always going to be identical, make a function/procedure". That can probably e extended to subclassing as well.

From your example, it sounds like your gripe is more with engineers that follow a given principle dogmatically, rather than applying it judiciously based on context.

Although I think there is some value in principles like these, I am always wary of anyone that's overly absolute in their thinking.

I once worked with a principal who applied a dogmatic view of the 12 Factor App and developed a framework based on those principles. It was to be the One Framework to Rule Them All, and the framework upon which our entire portfolio's application infrastructure was to be based because it would make everybody's lives so much easier and novice programmers could be productive right away, etc.

Maintaining code in it was a hassle. Code was scattered to the four winds in a required directory structure. But because simply importing modules wasn't allowed -- modules had to be structured as functions that accepted a "dependency manifest" containing all the modules they depended on -- it was difficult to figure out where your implementations lived. So instead of being able to read the code and figure out what was going on, you had to navigate this tangled web of dependencies and guess or search for where some of them lived.

Thankfully, with the arrival of a new system architect, cooler heads started to prevail and the company abandoned plans to go "all in" on this solution.

I'm a big fan of the 12 Factor App, but I don't think prohibiting importing modules is one of the 12 Factors.

yeah some people think this has to be done. But duplication can be cheaper especially if you are building the wrong abstraction.

https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction

Reply on news.ycombinator.com