←back to thread

1468 points nromiun | 1 comments | | HN request time: 0s | source
Show context
exclipy ◴[] No.45077894[source]
This was my main takeaway from A Philosophy Of Software Design by John Ousterhout. It is the best book on this subject and I recommend it to every software developer.

Basically, you should aim to minimise complexity in software design, but importantly, complexity is defined as "how difficult is it to make changes to it". "How difficult" is largely determined by the amount of cognitive load necessary to understand it.

replies(11): >>45077906 #>>45077954 #>>45078135 #>>45078497 #>>45078728 #>>45078760 #>>45078826 #>>45078970 #>>45079961 #>>45080019 #>>45082718 #
bsenftner ◴[] No.45077954[source]
Which is why I consider DRY (Don't Repeat Yourself) to be an anti-rule until an application is fairly well understood and multiple versions exist. DO repeat yourself, and do not create some smart version of what you think the problem is before you're attempting the 3rd version. Version 1 is how you figure out the problem space, version 2 is how you figure out your solution as a maintainable dynamic thing within a changing tech landscape, and version 3 is when DRY is look at for the first time for that application.
replies(5): >>45078178 #>>45078299 #>>45078606 #>>45078696 #>>45079410 #
zahlman ◴[] No.45078299[source]
DRY isn't about not reimplementing things; it's about not literally copying and pasting code. Which I have seen all the time, and which some might find easier now but will definitely make the system harder to change (correctly) at some point later on.
replies(10): >>45078465 #>>45078493 #>>45078525 #>>45078789 #>>45078797 #>>45078961 #>>45079164 #>>45079325 #>>45079628 #>>45079966 #
ryeats ◴[] No.45078493[source]
This is a trap junior devs fall into DRY isn't free it can be premature optimization since in order to avoid copying code you often add both an abstraction AND couple components together that are logically separate. The issues are at some point they may have slightly different requirements and if done repeatedly you can get to a point that you have all these small layers of abstraction that are cross cutting concerns and making changes have a bigger blast radius than you can intuit easily.
replies(5): >>45078671 #>>45078700 #>>45079551 #>>45080482 #>>45081244 #
rkomorn ◴[] No.45078671[source]
The reverse of that is people introducing bugs because code that wasn't DRY enough was only changed in some of the places that needed to be changed instead of all the places.

To me, it's the things that are specifically intended to behave the same should be kept DRY.

replies(2): >>45079743 #>>45081298 #
pkolaczk ◴[] No.45081298[source]
An obvious example of that is defining named constants and referring them by name instead of repeating the same value in N places. This is also DRY and good kind of DRY.
replies(1): >>45082660 #
1. ryeats ◴[] No.45082660[source]
This is actually a particular pet pieve of mine because I worked with the Camel framework which has a lot of boilerplate in strings but if you start using constants for the common parts you now have an unreadable mess of constants concatenated together that buys you nothing.