som utviklere, hører vi ofte cliched setninger kastet rundt som «Ikke Gjenta Deg selv». Vi tar ideer som dette og kjører med dem, noen ganger litt for langt.

Å Gå tilbake og vurdere hvorfor vi gjør disse tingene er nyttig. Så i dag, la oss se på en alternativ ideologi TIL TØRR programmering.

TØRR er definert (Ifølge Wikipedia) som:

hvert stykke kunnskap må ha en enkelt, entydig, autoritativ representasjon i et system.

Noe av dette kan bli litt pedantisk, men det kan være nyttig når du vurderer noe slikt. La oss bryte ned delene av fraseringen der.

Hvert stykke

Hva er «hvert stykke»? Kan vi aldri gjenta et variabelt navn? EN HTML-enhet?

Ok, ok. Så vi kan gjenta <div> er uten mye problem, og jeg tror ikke at noen vil fornærme det. Men dette bringer opp spørsmålet – når bestemmer vi at noe har blitt et «stykke kunnskap»? I React kan et godt eksempel være en komponent – men er det PrimaryButton og SecondaryButton eller betyr det en generalisert Button klasse? Svaret er generelt ansett for å være «Hva organisasjonen velger», men dette kan fortsatt la en god bit av tvetydighet rundt hva vi velger å abstrahere.

kunnskap

dette er et annet tvetydig punkt – hva definerer vi som kunnskap ? Vurder et stylet knappelement ved hjelp av noen atomklasser og React. Hvis det tar en senior dev 10 sekunder å lage, kan de ikke vurdere den kunnskapen verdt å abstrahere. Men til en mer junior utvikler som ikke kjenner systemet godt, kan den kunnskapen være en god abstraksjon. Ellers må de kanskje jakte på klassene, minne seg om hvordan knapper fungerer, og finne ut syntaksen for en onClick. Kunnskap er relativ og bruker den i en definisjon legger til tvetydighet.

Oppdatering: Xander forlot følgende kommentar nedenfor. Jeg tror at artikkelen gjør en god jobb med å forklare hva «kunnskap» skal bety.

ville bare forlate dette her for folk som er interessert.

«TØRR handler Om Kunnskap, kode duplisering er ikke problemet.»
verraes.net/2014/08/dry-is-about-k…

enkelt, entydig, autoritativ representasjon

en «enkelt» representasjon etterlater mye å være ønsket. Fra en devops-ingeniørs syn kan en enkelt representasjon være et helt program de trenger å distribuere. Til en frontend dev, kan det være en komponent. Og til en backend dev, kan det være en metode på en klasse eller ET API-endepunkt. Hvor blir linjen trukket?

vi har også ordet «entydig» – men som jeg nettopp har påpekt, definerer resten av denne setningen mer tvetydighet. «Autoritativ» er fornuftig – DIN TØRRE kode bør definere nøyaktig hva den gjør og være tro mot den definisjonen. Det er imidlertid ikke eksplisitt begrenset TIL TØRR kode.

system

Endelig har vi verdens «system» – dette kommer tilbake til «single» – setningen vi diskuterte for et sekund siden. Hva er et «system»? I React kan Det være en komponent eller En Redux action/component/reducer. I containerisert programvare kan vi snakke om en hel pod eller bare en enkelt forekomst.

PÅ slutten av dagen, TØRK alt for ofte å fremme pre-optimalisering, noe som er unødvendig og noen ganger faktisk gjør vondt din evne til å skrive kode. Noen ganger er det vanskeligere å endre en abstrahert komponent for å passe til en bestemt brukstilfelle. Du legger til mye kompleksitet, eller du bryter den komponenten ut i noe nytt-som ikke er supertørr. Du kan ikke vite hver brukstilfelle for komponenten din på dag ett.

et alternativ-Skriv Alt To ganger (VÅT) programmering

I Stedet foreslår JEG VÅT programmering. For meg vil definisjonen være:

du kan spørre deg selv «Har jeg ikke skrevet dette før?»to ganger, men aldri tre.

med denne definisjonen beveger fokuset seg bort fra for tidlig optimalisering og lar deg i stedet gjenta lignende kode et par ganger. Det skifter også fokus til en mer gut reaksjon. Den lar deg ta avgjørelser basert på den eksakte brukstilfelle du ser på. Hvis du bygger en webapp, vil du sannsynligvis abstrahere knappene dine til en komponent, fordi du skal bruke mange av dem. Men hvis det er en enkelt side som har noen spesiell styling(kanskje en prisside?), så trenger du ikke å bekymre deg for mye om å abstrahere komponentene på den siden. Faktisk, under dette systemet, hvis du trengte en ny side som ligner på den spesielle siden, kan du bare kopiere / lime inn og endre koden du trenger. Men i det øyeblikket det skjer en tredje gang, er det på tide å bruke litt tid på å abstrahere delene som kan abstraheres.

jeg vil også legge til denne bestemmelsen (TIL BÅDE VÅT og TØRR programmering):