←back to thread

Good Software Development Habits

(zarar.dev)
361 points mmphosis | 2 comments | 17 Nov 24 16:34 UTC | HN request time: 0s | source
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 #
bloopernova ◴[17 Nov 24 18:45 UTC] No.42166004[source]▶
Can you recommend any refactoring tutorials or books that teach those kinds of lessons?
replies(2): >>42166079 #>>42166206 #
1. leetrout ◴[17 Nov 24 18:55 UTC] No.42166079[source]▶
Not specifically this, per se, but I HIGHLY recommend "A Philosophy of Software Design" by Dr. John Ousterhout

https://web.stanford.edu/~ouster/cgi-bin/book.php

replies(1): >>42166776 #
2. mdaniel ◴[17 Nov 24 20:12 UTC] No.42166776[source]▶
I wish I could upvote this a million times

But, I'll also point out that just like reading about exercise, merely reading the book doesn't help unless one is willing to practice and -- much, much more difficult -- get buy-in from the team. Because software engineering is usually a team sport and if one person is reading these kinds of books and trying to put them into practice, and the other members of the team are happy choosing chaos, it's going to be the outlier who gets voted off the island