←back to thread

Good Software Development Habits

(zarar.dev)
361 points mmphosis | 8 comments | 17 Nov 24 16:34 UTC | HN request time: 1.041s | source | bottom
Show context
leetrout ◴[17 Nov 24 18:05 UTC] No.42165704[source]▶
> It's better to have some wonky parameterization than it is to have multiple implementations of nearly the same thing. Improving the parameters will be easier than to consolidate four different implementations if this situation comes up again.

Hard disagree. If you cant decompose to avoid "wonky parameters" then keep them separate. Big smell is boolean flags (avoid altogether when you can) and more than one enum parameter.

IME "heavy" function signatures are always making things harder to maintain.

replies(17): >>42165868 #>>42165902 #>>42166004 #>>42166217 #>>42166363 #>>42166370 #>>42166579 #>>42166774 #>>42167282 #>>42167534 #>>42167823 #>>42168263 #>>42168489 #>>42168888 #>>42169453 #>>42169755 #>>42171152 #
thfuran ◴[17 Nov 24 18:27 UTC] No.42165868[source]▶
I think it's especially bad advice with the "copy paste once is okay". You absolutely do not want multiple (even just two) copies of what's meant to be exactly the same functionality, since now they can accidentally evolve separately. But coupling together things that only happen to be mostly similar even at the expense of complicating their implementation and interface just makes things harder to reason about and work with.
replies(7): >>42166007 #>>42166141 #>>42166159 #>>42166278 #>>42166385 #>>42166712 #>>42187622 #
chipdart ◴[17 Nov 24 19:29 UTC] No.42166385[source]▶
> I think it's especially bad advice with the "copy paste once is okay". You absolutely do not want multiple (even just two) copies of what's meant to be exactly the same functionality, since now they can accidentally evolve separately.

Hard disagree. Your type of misconception is the root cause of most broken and unmaintainable projects, and the root of most technical debt and accidental complexity.

People who follow that simplistic logic of "code can accidentally evolve separately" are completely oblivious to the fact that there is seemingly duplicate code which is only incidentally duplicate, but at its core should clearly be and remain completely decoupled.

More to the point, refactoring two member functions that are mostly the same is far simpler than refactoring N classes and interfaces registered in dependency injection systems required to DRY up code.

I lost count I had to stop shortsighted junior developers who completely lost track of what they were doing and with a straight face were citing DRY to justify adding three classes and a interface to implement a strategy pattern because by that they would avoid adding a duplicate method. Absurd.

People would far better if instead of mindlessly parrot DRY they looked at what they are doing and understood that premature abstractions cause far more problems than the ones they solve (if any).

Newbie, inexperienced developers write complex code. Experienced, seasoned developers write simple code. Knowing the importance of having duplicate code is a key factor.

replies(5): >>42166615 #>>42167259 #>>42167267 #>>42168379 #>>42169272 #
1. twic ◴[17 Nov 24 21:08 UTC] No.42167267[source]▶
What thfuran said was:

> You absolutely do not want multiple (even just two) copies of what's meant to be exactly the same functionality, since now they can accidentally evolve separately. But coupling together things that only happen to be mostly similar even at the expense of complicating their implementation and interface just makes things harder to reason about and work with.

So, if things are fundamentally the same, do not duplicate, but if they are fundamentally different, do not unify. This is absolutely correct.

To which you replied:

> People who follow that simplistic logic of "code can accidentally evolve separately" are completely oblivious to the fact that there is seemingly duplicate code which is only incidentally duplicate, but at its core should clearly be and remain completely decoupled.

Despite the fact that this is exactly what the comment you replied to says.

Then you go on a clearly very deeply felt rant about overcomplication via dependency injection and architecture astronautics and so on. Preach it! But this is also nothing to do with what thfuran wrote.

> Newbie, inexperienced developers write complex code. Experienced, seasoned developers write simple code.

Sounds like the kind of overgeneralisation that overconfident mid-career developers make to me.

replies(2): >>42167782 #>>42168986 #
2. deely3 ◴[17 Nov 24 22:08 UTC] No.42167782[source]▶
The issue is that you actually never really know is things are fundamentally the same. To know it you have to know the future.
replies(4): >>42168392 #>>42168533 #>>42168831 #>>42169889 #
3. dustingetz ◴[17 Nov 24 23:46 UTC] No.42168392[source]▶
or study abstract algebra (but you’re now a researcher, because programming isn’t yet solved)
4. Aeolun ◴[18 Nov 24 00:14 UTC] No.42168533[source]▶
I think this is what the original post that people took issue with said? By the time you write the same thing for the third time you are not predicting the future any more, you have practical evidence.
replies(1): >>42188887 #
5. Ma8ee ◴[18 Nov 24 01:14 UTC] No.42168831[source]▶
Not the future, but the domain.
6. djmips ◴[18 Nov 24 01:41 UTC] No.42168986[source]▶
To be fair thfuran was hard to decipher and should be refactored to be more clear.
7. strken ◴[18 Nov 24 05:13 UTC] No.42169889[source]▶
"Know the future" is part of a software engineer's job description, at least insofar as "know" means "make informed predictions about".

Consider the case of making API calls to a third party. You, today, are writing a function that calls the remote API with some credentials, reauthenticates on auth failure, handles backoff when rate limited, and generates structured logs for outgoing calls.

You need to add a second API call. You're not sure whether to copy the existing code or create an abstraction. What do you do?

Well, in this case, you have a crystal ball! This is a common abstraction that can be identified in other code as well as your own. You don't know the future with 100% confidence, but it's your job to be able to make a pretty good guess using partial information.

8. thfuran ◴[19 Nov 24 22:45 UTC] No.42188887{3}[source]▶
But a thing that you wrote the same a few times isn't something that's definitively required to be the same, it's something that happens to be the same right now. You can often clean things up by factoring out that duplication, but needing to add a bunch of parameters to the resulting function is probably a sign that you're trying to combine things that aren't the same and shouldn't be coupled together.

Where I'm saying you absolutely shouldn't copy paste is where there's a business or technical requirement for something to be calculated/processed/displayed exactly a certain way in several contexts. You don't want to let those drift apart accidentally, though you certainly might decouple them later if that requirement changes.