som utvecklare hör vi ofta klichade fraser kastade runt som ”upprepa inte dig själv”. Vi tar ideer som detta och kör med dem, ibland lite för långt.

att gå tillbaka och utvärdera varför vi gör dessa saker är till hjälp. Så idag, låt oss titta på en alternativ ideologi till torr programmering.

torr definieras (enligt Wikipedia) som:

varje kunskap måste ha en enda, entydig, auktoritativ representation inom ett system.

en del av detta kan bli lite pedantiskt, men det kan vara till hjälp när man överväger något liknande. Låt oss bryta ner delarna av formuleringen där.

varje bit

vad är ”varje bit”? Kan vi aldrig upprepa ett variabelnamn? En HTML-enhet?

Ok, ok. Så vi kan upprepa <div>s utan mycket problem och jag tror inte att någon kommer att ta anstöt på det. Men det här tar upp frågan-när bestämmer vi att något har blivit en”kunskap”? I React kan ett bra exempel vara en komponent – men är det PrimaryButton och SecondaryButton eller betyder det en generaliserad Button klass? Svaret anses allmänt vara” vad din organisation väljer”, men det kan fortfarande lämna en bra bit av tvetydighet kring vad vi väljer att abstrahera.

kunskap

detta är en annan tvetydig punkt-vad definierar vi som kunskap? Tänk på ett stylat knappelement med hjälp av vissa atomklasser och reagera. Om det tar en senior dev 10 sekunder att skapa , kanske de inte anser att kunskapen är värd att abstrahera. Men för en yngre utvecklare som inte känner till systemet väl kan den kunskapen vara en bra abstraktion. Annars kan de behöva jaga klasserna, påminna sig om hur knappar fungerar och räkna ut syntaxen för ett onClick. Kunskap är relativ och att använda den i en definition ger tvetydighet.

Uppdatering: Xander lämnade följande kommentar nedan. Jag tycker att artikeln gör ett bra jobb med att förklara vad” kunskap ” borde betyda.

ville bara lämna detta här för människor som är intresserade.

”torr handlar om kunskap, koddubblering är inte problemet.”
verraes.net/2014/08/dry-is-about-k …

enkel, entydig, auktoritativ representation

en” enkel ” representation lämnar mycket att önska. Från en DevOps-ingenjör kan en enda representation vara en hel applikation som de behöver distribuera. Till en frontend dev, som kan vara en komponent. Och till en backend dev kan det vara en metod på en klass eller en API-slutpunkt. Var dras linjen?

Vi har också ordet ”otvetydigt” – men som jag just har påpekat definierar resten av denna mening mer tvetydighet. ”Auktoritativ” är vettigt – din torra kod ska definiera exakt vad den gör och vara sann mot den definitionen. Det är dock inte uttryckligen begränsat till torr kod.

system

Slutligen har vi världens ”system” – detta kommer tillbaka till det” enda ” uttalandet som vi diskuterade för en sekund sedan. Vad är ett ”system”? I React kan det vara en komponent eller en Redux-åtgärd/komponent/reducerare. I containeriserad programvara kan vi prata om en hel pod eller bara en enda instans.

i slutet av dagen främjar DRY all to ofta föroptimering, vilket är onödigt och ibland faktiskt skadar din förmåga att skriva kod. Ibland är det svårare att modifiera en abstraherad komponent för att passa ett specifikt användningsfall. Du lägger till mycket komplexitet eller du bryter den komponenten ut i något nytt – vilket inte är supertorrt. Du kan inte veta alla användningsfall för din komponent på dag ett.

ett alternativ-skriv allt två gånger (våt) programmering

istället föreslår jag våt programmering. För mig skulle definitionen vara:

Du kan fråga dig själv ” har jag inte skrivit det här förut?”två gånger, men aldrig tre.

med denna definition flyttas fokus bort från för tidig optimering och låter dig istället upprepa liknande kod ett par gånger. Det skiftar också fokus till en mer tarmreaktion. Det låter dig fatta beslut baserat på det exakta användningsfallet du tittar på. Om du bygger en webbapp vill du förmodligen abstrahera dina knappar till en komponent, eftersom du kommer att använda många av dem. Men om det finns en enda sida som har någon speciell styling (kanske en prissättningssida?), då behöver du inte oroa dig för mycket för att abstrahera komponenterna på den sidan. I själva verket, under det här systemet, om du behövde en ny sida som liknade den speciella sidan, kan du bara kopiera/klistra in och ändra koden du behöver. Men i det ögonblick som det händer en tredje gång är det dags att spendera lite tid på att abstrahera de delar som kan abstraheras.

Jag skulle också lägga till denna bestämmelse (till både våt och torr programmering):