AHA - Avoid Hasty Abstraction

Et alternativ til DRY og WET.
#inanutshell

🌰 I et nøtteskall

  • Avoid Hasty Abstractions
  • Prefer duplication over the wrong abstraction
  • Optimize for change first

📄 In a summary

Å abstrahere duplisert kode til en felles klasse eller metode betyr ikke at denne abstraksjonen er hellig. Optimaliser for endring først. (Dette kan sees på som en spesialisering av ETC - Easy To Change konseptet fra The Pragmatic Programmer)

Ofte vil man abstrahere kode som er duplisert to steder til ett sted (Følger DRY prinsippet).
Senere, når krav endres, kan denne abstraheringen føles hellig. Man vil ikke ta bort det harde arbeidet som er blitt gjort. Man introduserer heller et parameter til metoden, som man så sjekker og gjør ulike ting basert på verdien.

En universal abstraksjon oppfører seg nå forskjellig for forskjellige caser.

Når behovet for å gjøre forskjellige ting utifra hvem som kaller metoden oppstår, ødelegg heller abstraksjonen og gjør følgende :

  1. Dupliser koden alle steder hvor den kalles.
  2. På hvert sted den kalles, se på hvilke parametre som ble brukt, og finn hvilken kode denne spesifikke kalleren bruker.
  3. Slett koden som ikke trengs for denne kalleren.

Koden hver kaller bruker kan da vise seg å være nokså unik. Etter man har gjort dette kan man igjen fjerne duplisering og abstrahere på nytt der det gir mening.

Kilde: https://kentcdodds.com/blog/aha-programming, https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction

Relevant:
https://stitcher.io/blog/dont-be-clever