als ontwikkelaars, We horen vaak clichézinnen die rond worden gegooid als “herhaal jezelf niet”. We nemen ideeën als deze en lopen met hen, soms een beetje te ver.

een stap terug doen en evalueren waarom we deze dingen doen is nuttig. Laten we vandaag eens kijken naar een alternatieve ideologie voor droog programmeren.

DRY wordt gedefinieerd (volgens Wikipedia) als:

elk stukje kennis moet een eenduidige, gezaghebbende representatie hebben binnen een systeem.

sommige hiervan kunnen een beetje pedant worden, maar dat kan nuttig zijn als je zoiets overweegt. Laten we de delen van de frasering hier opsplitsen.

elk stuk

Wat is “elk stuk”? Kunnen we nooit een variabele naam herhalen? Een HTML-entiteit?

Ok, ok. Dus we kunnen <div>’s herhalen zonder veel problemen en ik denk niet dat iemand er aanstoot aan zal nemen. Maar dit roept wel de vraag op – wanneer beslissen we dat iets een “stukje kennis”is geworden? In React kan een goed voorbeeld een component zijn – maar is dat PrimaryButton en SecondaryButton of betekent het een gegeneraliseerde Button klasse? Het antwoord wordt over het algemeen beschouwd als “wat uw organisatie kiest”, maar dit kan nog steeds een groot beetje onduidelijkheid over wat we kiezen te abstraheren.

kennis

Dit is een ander dubbelzinnig punt – wat definiëren we als kennis? Overweeg een vormgegeven knop element met behulp van een aantal atomaire klassen en reageer. Als het een senior dev 10 seconden kost om te creëren, zullen ze die kennis misschien niet de moeite waard vinden om te abstraheren. Maar voor een junior ontwikkelaar die het systeem niet goed kent, kan die kennis een goede abstractie zijn. Anders moeten ze misschien de klassen opzoeken, zichzelf eraan herinneren hoe knoppen werken, en de syntaxis voor een onClickachterhalen. Kennis is relatief en het gebruik ervan in een definitie voegt dubbelzinnigheid toe.

Update: Xander liet hieronder het volgende commentaar achter. Ik denk dat dat artikel een geweldige job doet om uit te leggen wat “kennis” zou moeten betekenen.

wilde dit hier laten voor mensen die geïnteresseerd zijn.

“droog is over kennis, code duplicatie is niet het probleem.”
verraes.net/2014/08/dry-is-about-k …

enkele, ondubbelzinnige, gezaghebbende representatie

een” enkele ” representatie laat veel te wensen over. Vanuit het oogpunt van een devops engineer, een enkele vertegenwoordiging kan een volledige toepassing die ze nodig hebben om te implementeren. Voor een frontend dev, kan dat een component zijn. En voor een backend dev, dat kan een methode op een klasse of een API eindpunt. Waar wordt de grens getrokken?

we hebben ook het woord “ondubbelzinnig” – maar zoals ik net heb opgemerkt, de rest van deze zin definieert meer ambiguïteit. “Gezaghebbend” is zinvol – uw droge code moet precies definiëren wat het doet en trouw zijn aan die definitie. Echter, dat is niet expliciet beperkt tot droge code.

systeem

ten slotte hebben we de wereld “systeem” – dit gaat terug naar de “single” statement die we een seconde geleden hebben besproken. Wat is een “systeem”? In React kan het een component of een Redux actie/component/reducer zijn. In containerized software, kunnen we praten over een hele pod of slechts een enkele instantie.

aan het eind van de dag bevordert DRY all to vaak pre-optimalisatie, wat onnodig is en soms zelfs je vermogen om code te schrijven schaadt. Soms is het moeilijker om een geabstraheerd onderdeel aan te passen aan een specifieke use case. Je voegt veel complexiteit toe of je breekt dat onderdeel uit in iets nieuws – dat niet superdroog is. Je kunt niet elke use case voor uw component weten op dag één.

een alternatief-schrijf alles tweemaal (WET) programmeren

in plaats daarvan stel ik WET programmeren voor. Voor mij zou de definitie zijn:

je kunt jezelf afvragen ” heb ik dit niet eerder geschreven?”twee keer, maar nooit drie.

Met deze definitie beweegt de focus weg van vroegtijdige optimalisatie en in plaats daarvan kunt u soortgelijke code een paar keer herhalen. Het verschuift ook de focus naar een meer darmreactie. Hiermee kunt u beslissingen nemen op basis van de exacte use case waar u naar kijkt. Als je een web app aan het bouwen bent, wil je waarschijnlijk je knoppen abstraheren in een component, omdat je er veel van gaat gebruiken. Maar als er een enkele pagina die een aantal speciale styling heeft (misschien een prijslijst Pagina?), dan hoef je niet te veel zorgen te maken over het abstraheren van de componenten op die pagina. In feite, onder dit systeem, als je een nieuwe pagina die vergelijkbaar is met die speciale pagina nodig had, je kon gewoon kopiëren/plakken en de code die u nodig hebt wijzigen. Echter, op het moment dat dat een derde keer gebeurt, is het tijd om een beetje tijd te besteden aan het abstraheren van de delen die kunnen worden geabstraheerd.

Ik zou ook deze bepaling willen toevoegen (aan zowel natte als droge programmering):