Tørt, vådt, varmt, koldt. Det er bare ord, ikke sandt? Jeg er her for at fortælle dig, at de kan være mere.
De fleste, hvis ikke alle, programmører vil have hørt om udtrykkene DRY og WET, da de vedrører kode. Men lad os først erklære, hvad disse akronymer står for, så ingen er dårligt informeret.
DRY – Don’t Repeat Yourself
WET – Write Everything Twice
Tag et øjeblik til eftertanke … hvilket akronym lyder som om, at det kunne være den bedre kodningspraksis? Hvis din fornemmelse pegede dig i retning af DRY, ville du have ret. Tja, 90 % af tiden.
Som programmør er det generelt den bedste praksis at stræbe efter at holde din kode DRY, dvs. ikke at gentage din kode. Men der er tidspunkter, hvor det kan gøre dit liv lidt lettere at få tilsat lidt fugt til din kode.
Lad os først tage et kig på et eksempel på hver af dem.
Her er, hvordan noget WET-kode ser ud: (med Ruby)
class John
def build(n)
n + 1
end def destroy(n)
n - 1
end
end class Peter
def build(n)
n + 1
end
end
Fandt du pletterne Write Everything Twice?
I dette tilfælde har begge klasser, John & Peter, mulighed for at bruge build-metoden. Men hvis der i fremtiden skulle foretages en ændring af build-metoden, skal den foretages to gange, hvert sted hvor build-metoden bruges.
Men på den anden side, hvis koden var DRY, ville vi kun skulle foretage ændringen én gang. I dette tilfælde kan brugen af et modul være med til at holde vores kode DRY:
module Builder
def build(n)
n + 1
end
endclass John
include Builder def destroy(n)
n - 1
end
endclass Peter
include Builder
end
Ved hjælp af et modul får begge klasser mulighed for at bygge. Og John beholder selvfølgelig stadig sin destroy-metode.
Det er mest nyttigt at holde din kodebase DRY på steder, hvor du forudser, at der sker ændringer ret ofte. Hvis du har DRY-kode, betyder det, at du kun behøver at foretage disse ændringer på ét eller få områder i stedet for alle de steder, hvor den pågældende kode kan blive brugt.
Måske vigtigst af alt reducerer det at have DRY-kode din chance for fejl. Forestil dig, at der skal foretages en ændring i identisk kode på fem forskellige steder, men du glemmer at ændre koden på et af disse steder… Kan du se problemet? Enten vil dit program gå ned, eller måske endnu værre, bruge en forældet procedure, mens det ser normalt ud.
Det sagt, har WET-kode sine fordele. Hvis du forudser, at den identiske kode senere vil forkaste sig i forskellige retninger, kan det at have WET-kode gøre den fremtidige ændring lettere.
Dertil kommer, at alt for DRY-kode kan skabe hovedpine for den næste programmør, der bruger din kode, hvilket kan omfatte dig selv. Dette kan skyldes, at man skal foretage en kedelig mængde logiske spring for at finde ud af, hvilke faktorer der er i spil i en bestemt kodelinje.
Det sagt, som en generel tommelfingerregel, skal du holde din kode DRY folkens. Morgendagens dig vil sætte pris på det.