The overarching strategy I use when I'm extending and maintaining a codebase is this:
Find Precedence in the codebase
First, I find places in the codebase I wrote similar code, or tried to accomplish similar goals. I might review this existing code to see if the way I did it was good or bad
Copy design & style
Next, I'll write my new code with the old code in mind. My goal is to keep the 2 similar parts of the code working the same way.
Refactor to DRY
Now that I have multiple pieces of code that work in the same way, I look for ways to have them share behavior, like by pulling out utility functions, wrapping logic into an object, or commenting my logic for why I chose to NOT do that.
Why it's good
I don't have to maintain some stupid friggin document which tells you how to code. you look at the code that's there and copy it.
DRY is just good. I don't need to defend it. you can read all about why DRY is good by googling it (see the amount of time I just saved by not repeating something? haha)
Only courting complexity demons the SECOND time you do something means you aren't wasting as much time overengineering something when YAGNI.
By commenting your logic for not DRYing some code out, you are saving yourself from needing to divine truth from bad commit messages
Why it's bad
Sometimes you have to fight the urge to fit 2 different pegs into the square hole
Sometimes the complexity demons kill you and eat all your code.
You also break a lot of things at once when you change a line of code in your DRY stuff.
i beat getting over it with bennet foddy the other day and ive now racked up 5 clears. this quote really resonated with me.
"An orange, is sweet juicy fruit locked inside a bitter peel. That's not how I feel about a challenge. I only want the bitterness. Its coffee, its grapefruit, its licorice."
Random images of one of my non game-related characters.
Moon Lizard (or just Moon)
He lives inside the moon and comes down to explore Earth to find cool stuff to collect.