Atomic Spin

Dezvoltatorii de software sunt foarte buni la recunoașterea tiparelor. Poate că este o abilitate inerentă care ne atrage spre această profesie. Sau poate că procesul de scriere de software este cel care dezvoltă această abilitate. Oricum ar fi, „nu te repeta” (DRY) este o aplicație naturală a acestei abilități.

Cu toate acestea, repetiția în sine nu este dușmanul pe care acest principiu îl face să pară.

Nu te repeta

La fel de intuitiv cum poate fi „nu te repeta”, The Pragmatic Programmer îl rezumă astfel:

Care cunoștință trebuie să aibă o reprezentare unică, lipsită de ambiguitate și autoritară în cadrul unui sistem.

Nu este greu de imaginat beneficiile reducerii sau eliminării repetițiilor.

• Mai puține dublări înseamnă mai puțin cod de întreținut. Și dacă cel mai bun cod este să nu existe niciun cod, acest lucru sună ca un lucru bun.
• O sursă unică de adevăr elimină posibilitatea ca lucrurile să nu fie sincronizate. S-a schimbat vreo regulă de afaceri? Actualizați-o într-un singur loc și gata.
• Codul este reutilizabil. Aveți un proces care este împărtășit de trei lucruri și adăugați un al patrulea? Cea mai mare parte a lucrului a fost deja făcută.

Încercați să vă repetați uneori

Să deveniți prea zeloși în ceea ce privește reducerea duplicării aparente poate crea mai multe probleme decât rezolvă. Spun „duplicare aparentă” pentru că, uneori, lucrurile care par similare nu sunt de fapt legate între ele. De exemplu, două structuri de date cu proprietăți și tipuri identice pot fi identice din punct de vedere structural, dar nu și din punct de vedere semantic.

O strategie comună pentru reducerea codului duplicat este de a factoriza părțile comune și de a le ascunde în spatele unei abstracțiuni. Dar un efect secundar nedorit al acestui lucru este că se cuplează orice folosește abstracția. Orice schimbare în abstracție afectează toți consumatorii săi. Și, de asemenea, abstracția poate fi nevoită să fie îndoită pentru a se potrivi cerințelor unui singur consumator.

Această creștere a cuplării vine, de asemenea, cu o scădere a flexibilității. Să spunem că aveți un proces care este utilizat în trei locuri. Este aproape la fel în toate cele trei locuri, cu doar câteva diferențe importante. Așadar, implementați procesul ca un singur modul care ia câțiva parametri pentru a acoperi diferențele.

Dezvoltarea procesului pentru doar unul singur dintre aceste cazuri de utilizare este acum imposibilă: orice modificare la unul dintre ele le afectează pe toate trei. Sigur, puteți adăuga mai mulți parametri (sau cazuri speciale!) pe măsură ce cazurile de utilizare diferă. Dar va deveni rapid imposibil să distingi părțile importante ale procesului de infrastructura care separă cazurile de utilizare.

Întrebări de pus

Când refactorizez codul existent sau scriu cod nou care poate fi potențial duplicat, mă întreb:

Este aceasta o singură bucată de cunoștințe care a fost duplicată sau este doar o infrastructură care se întâmplă să arate similar?

Așa că ați răscolit prin CSS și ați găsit o clasă care se întâmplă să aibă stilurile pe care le doriți. Probabil că acesta nu este un motiv suficient de bun pentru a evita definirea unei alte clase.

De câte ori a fost repetat acest lucru?

Până când un lucru cu adevărat redundant nu apare de cel puțin trei ori, aș fi foarte sceptic cu privire la orice reducere a repetiției care crește complexitatea.

Reducerea duplicării acum va face mai dificilă personalizarea cazurilor individuale în viitor?

Există ceva satisfăcător în refactorizarea unei grămezi de cod copy-and-paste în ceva mai raționalizat și reutilizabil. Dar blocarea atât de strânsă a codului încât orice schimbare ar introduce cazuri speciale nu este un compromis bun.

Dacă reduc această duplicare, care este raportul dintre dimensiunea abstractizării și numărul de parametri pe care îi va lua?

Bibliotecile și cadrele sunt grozave pentru că oferă cod reutilizabil cu relativ puțini parametri pentru personalizare. Dar imaginați-vă o funcție specifică unei aplicații pentru prezentarea unei casete de dialog care a crescut și acum acceptă 20 de parametri. Orice beneficiu de reducere a repetiției care a existat atunci când avea 2 parametri nu mai există.

Concluzie

Ca și în cazul multor principii de dezvoltare software, „nu te repeta” este mai mult o îndrumare decât o mantră.

.