som udviklere hører vi ofte klichede sætninger kastet rundt som “gentag ikke dig selv”. Vi tager ideer som denne og løber med dem, nogle gange lidt for langt.

det er nyttigt at træde tilbage og evaluere, hvorfor vi gør disse ting. Så i dag, lad os se på en alternativ ideologi til tør programmering.

tør er defineret som:

hvert stykke viden skal have en enkelt, entydig, autoritativ repræsentation i et system.

noget af dette kan blive lidt pedantisk, men det kan være nyttigt, når man overvejer noget som dette. Lad os nedbryde delene af formuleringen der.

hvert stykke

Hvad er “hvert stykke”? Kan vi aldrig gentage et variabelnavn? En HTML-enhed?

Ok, ok. Så vi kan gentage <div>‘s uden meget problem, og jeg tror ikke, at nogen vil fornærme det. Men dette rejser spørgsmålet – Hvornår beslutter vi, at noget er blevet et”stykke viden”? I React kan et godt eksempel være en komponent-men er det PrimaryButtonog SecondaryButtoneller betyder det en generaliseret Button klasse? Svaret anses generelt for at være” uanset hvad din organisation vælger”, men det kan stadig efterlade en god smule tvetydighed omkring det, vi vælger at abstrahere.

viden

dette er et andet tvetydigt punkt – hvad definerer vi som viden? Overvej et stylet knapelement ved hjælp af nogle atomklasser og reager. Hvis det tager en senior dev 10 sekunder at oprette , kan de ikke overveje den viden, der er værd at abstrahere. Men til en mere junior udvikler, der ikke kender systemet godt, kan denne viden være en god abstraktion. Ellers skal de muligvis jage klasserne, minde sig om, hvordan knapper fungerer, og finde ud af syntaksen for en onClick. Viden er relativ, og at bruge den i en definition tilføjer tvetydighed.

opdatering: Sander forlod følgende kommentar nedenfor. Jeg synes, at artiklen gør et godt stykke arbejde med at forklare, hvad “viden” skal betyde.

ville bare forlade dette her for folk, der er interesserede.

” tør handler om viden, kode duplikering er ikke problemet.”
verraes.net/2014/08/dry-is-about-k…

enkelt, entydig, autoritativ repræsentation

en “enkelt” repræsentation lader meget tilbage at ønske. Set fra en devops-ingeniør kan en enkelt repræsentation være en hel applikation, de har brug for at implementere. Til en frontend dev, der kan være en komponent. Og til en backend dev, det kan være en metode på en klasse eller et API-slutpunkt. Hvor bliver linjen trukket?

Vi har også ordet” entydigt ” – men som jeg lige har påpeget, definerer resten af denne sætning mere tvetydighed. “Autoritativ” giver mening – din tørre kode skal definere nøjagtigt, hvad den gør, og være tro mod denne definition. Det er dog ikke eksplicit begrænset til tør kode.

system

endelig har vi verdens “system” – dette kommer tilbage til den “single” erklæring, vi diskuterede for et sekund siden. Hvad er et “system”? I React kan det være en komponent eller en ny handling/komponent/reducer. I containeriseret program kunne vi tale om en hel pod eller bare en enkelt forekomst.

i slutningen af dagen, tør alle til ofte fremmer pre-optimering, hvilket er unødvendigt og nogle gange faktisk gør ondt din evne til at skrive kode. Nogle gange er det sværere at ændre en abstraheret komponent, så den passer til en bestemt brugssag. Du tilføjer en masse kompleksitet, eller du bryder den komponent ud i noget nyt – hvilket ikke er super tørt. Du kan ikke kende alle brugssager til din komponent på første dag.

et alternativ – skriv Alt to gange (våd) programmering

i stedet foreslår jeg våd programmering. For mig ville definitionen være:

Du kan spørge dig selv ” har jeg ikke skrevet dette før?”to gange, men aldrig tre.

Med denne definition bevæger fokus sig væk fra for tidlig optimering og giver dig i stedet mulighed for at gentage lignende kode et par gange. Det skifter også fokus til en mere tarmreaktion. Det giver dig mulighed for at træffe beslutninger baseret på den nøjagtige brugssag, du ser på. Hvis du bygger en internetapp, vil du sandsynligvis abstrahere dine knapper til en komponent, fordi du vil bruge mange af dem. Men hvis der er en enkelt side, der har en særlig styling (måske en prisside?), så behøver du ikke bekymre dig for meget om at abstrahere komponenterne på den side. Faktisk under dette system, hvis du havde brug for en ny side, der lignede den specielle side, kunne du bare kopiere/indsætte og ændre den kode, du har brug for. Men i det øjeblik det sker en tredje gang, er det tid til at bruge lidt tid på at abstrahere de dele, der kan abstraheres.

Jeg vil også tilføje denne bestemmelse (til både våd og tør programmering):