ca Dezvoltatori, auzim adesea fraze clișe aruncate în jur ca „nu te repeta”. Luăm astfel de idei și alergăm cu ele, uneori puțin prea departe.

este util să ne retragem și să evaluăm de ce facem aceste lucruri. Deci, astăzi, să ne uităm la o ideologie alternativă la programarea uscată.

uscat este definit (conform Wikipedia) ca:

fiecare bucată de cunoaștere trebuie să aibă o reprezentare unică, lipsită de ambiguitate, autoritate în cadrul unui sistem.

unele dintre acestea s-ar putea obține un pic pedant, dar care poate fi de ajutor atunci când se analizează ceva de genul asta. Să descompunem părțile frazării de acolo.

fiecare piesă

Ce este „fiecare piesă”? Nu putem repeta niciodată un nume de variabilă? O entitate HTML?

bine, bine. Deci, putem repeta <div>este fără prea multe probleme și nu cred că cineva se va supăra. Dar acest lucru ridică întrebarea-când decidem că ceva a devenit o „cunoaștere”? În React, un exemplu bun ar putea fi o componentă-dar este PrimaryButton și SecondaryButton sau înseamnă o clasă generalizată Button? Răspunsul este, în general, considerat a fi „orice alege organizația dvs.”, dar acest lucru poate lăsa totuși un pic de ambiguitate în jurul a ceea ce alegem să abstractizăm.

cunoașterea

acesta este un alt punct ambiguu – ce definim ca cunoaștere? Luați în considerare un element de buton stilat folosind unele clase Atomice și reacționați. Dacă este nevoie de un dev senior 10 secunde pentru a crea , este posibil să nu considere că cunoștințele merită abstracte. Dar pentru un dezvoltator mai junior care nu cunoaște bine sistemul, acea cunoaștere ar putea fi o abstracție bună. În caz contrar, ar putea fi nevoiți să vâneze clasele, să-și amintească cum funcționează butoanele și să-și dea seama de sintaxa pentru un onClick. Cunoașterea este relativă și utilizarea acesteia într-o definiție adaugă ambiguitate.

actualizare: Xander a lăsat următorul comentariu mai jos. Cred că acest articol face o treabă excelentă de a explica ce ar trebui să însemne” cunoașterea”.

am vrut doar să las asta aici pentru cei interesați.

„uscat este despre cunoștințe, duplicarea cod nu este problema.”
verraes.net/2014/08/dry-is-about-k …

reprezentare unică, lipsită de ambiguitate, autoritară

o reprezentare „unică” lasă mult de dorit. Din punctul de vedere al unui inginer devops, o singură reprezentare ar putea fi o aplicație întreagă pe care trebuie să o implementeze. Pentru un dev frontend, care ar putea fi o componentă. Și la un dev backend, care ar putea fi o metodă pe o clasă sau un punct final API. Unde se trage linia?

avem și cuvântul „lipsit de ambiguitate” – dar așa cum tocmai am subliniat, restul acestei propoziții definește mai multă ambiguitate. „Autoritar” are sens – codul dvs. uscat ar trebui să definească exact ceea ce face și să fie fidel acestei definiții. Cu toate acestea, acest lucru nu se limitează în mod explicit la codul uscat.

sistem

În cele din urmă, avem „sistemul” mondial – aceasta se întoarce la declarația „unică” pe care am discutat-o acum o secundă. Ce este un „sistem”? În React, ar putea fi o componentă sau o acțiune Redux/componentă/reductor. În software-ul containerizat, am putea vorbi despre un pod întreg sau doar o singură instanță.

la sfârșitul zilei, uscat toate pentru a promova de multe ori pre-optimizare, care este inutilă și, uneori, de fapt doare capacitatea de a scrie cod. Uneori este mai dificil să modificați o componentă abstractizată pentru a se potrivi unui caz de utilizare specific. Adăugați o mulțime de complexitate sau rupeți acea componentă în ceva nou – care nu este super uscat. Nu puteți cunoaște fiecare caz de utilizare pentru componenta dvs. în prima zi.

o alternativă – scrie totul de două ori (umed) programare

în schimb, propun programare umed. Pentru mine definiția ar fi:

vă puteți întreba „nu am scris asta înainte?”de două ori, dar niciodată de trei ori.

cu această definiție focalizarea se îndepărtează de optimizarea prematură și în schimb vă permite să repetați codul similar de câteva ori. De asemenea, mută accentul pe o reacție mai intestinală. Vă permite să luați decizii pe baza cazului exact de utilizare la care vă uitați. Dacă construiți o aplicație web, probabil că doriți să vă abstractizați butoanele într-o componentă, deoarece veți folosi multe dintre ele. Dar dacă există o singură pagină care are un stil special (poate o pagină de prețuri?), atunci nu trebuie să vă faceți griji prea mult cu privire la abstractizarea componentelor de pe acea pagină. De fapt, în cadrul acestui sistem, dacă aveți nevoie de o pagină nouă care să fie similară cu acea pagină specială, puteți doar să copiați/lipiți și să schimbați codul de care aveți nevoie. Cu toate acestea, în momentul în care acest lucru se întâmplă a treia oară, timpul său de a petrece un pic de timp abstractizând părțile care pot fi abstractizate.

aș adăuga și această prevedere (atât la programarea umedă, cât și la cea uscată):