Atomic Spin

A szoftverfejlesztők nagyszerűek a minták felismerésében. Talán ez egy veleszületett képesség, ami ehhez a szakmához vonz minket. Vagy talán a szoftverírás folyamata fejleszti ezt a képességet. Akárhogy is, a “ne ismételd magad” (DRY) ennek a képességnek a természetes alkalmazása.

Az ismétlés azonban önmagában nem olyan ellenség, mint amilyennek ez az elv beállítja.

Ne ismételd magad

Amilyen intuitív is lehet a “ne ismételd magad”, a Pragmatikus programozó így foglalja össze:

Minden tudásnak egyetlen, egyértelmű, hiteles reprezentációval kell rendelkeznie egy rendszeren belül.

Nem nehéz elképzelni az ismétlések csökkentésének vagy megszüntetésének előnyeit.

• A kevesebb duplikáció kevesebb karbantartandó kódot jelent. És ha a legjobb kód az, ha egyáltalán nincs kód, akkor ez jó dolognak hangzik.
• Az egyetlen igazságforrás kiküszöböli annak lehetőségét, hogy a dolgok ne legyenek szinkronban. Valamilyen üzleti szabály megváltozott? Frissítse egy helyen, és kész.
• A kód újrafelhasználható. Van egy folyamat, amelyet három dolog oszt meg, és hozzáad egy negyediket? A munka nagy részét már elvégezték.

Néha ismételd magad

A látszólagos duplikációk csökkentésének túlbuzgósága több problémát okozhat, mint amennyit megold. Azért mondom, hogy “látszólagos duplikáció”, mert néha a hasonlónak tűnő dolgok valójában nem kapcsolódnak egymáshoz. Például két azonos tulajdonságokkal és típusokkal rendelkező adatszerkezet lehet, hogy szerkezetileg azonos, de szemantikailag nem.

A duplikált kód csökkentésének gyakori stratégiája, hogy a közös részeket kiszűrjük és egy absztrakció mögé rejtjük. Ennek azonban nemkívánatos mellékhatása, hogy az absztrakciót használó bármit összekapcsol. Az absztrakció bármilyen változása kihat az összes fogyasztójára. És ugyanígy előfordulhat, hogy az absztrakciót meg kell hajlítani, hogy megfeleljen egyetlen fogyasztó követelményeinek.

Ez a fokozott csatolás a rugalmasság csökkenésével is jár. Tegyük fel, hogy van egy folyamat, amelyet három helyen használnak. Mindhárom helyen majdnem ugyanaz, csak néhány fontos különbséggel. Ezért a folyamatot egyetlen modulként implementálod, amely néhány paramétert vesz fel, hogy lefedje a különbségeket.

A folyamatot csak egyetlen ilyen felhasználási esethez igazítani már lehetetlen: az egyik módosítás mindháromra hatással van. Persze, hozzáadhatsz további paramétereket (vagy speciális eseteket!), ahogy a használati esetek eltérnek egymástól. De hamar lehetetlenné válik a folyamat fontos részeinek megkülönböztetése a felhasználási eseteket elválasztó infrastruktúrától.

Kérdések, amelyeket fel kell tenni

A meglévő kód refaktorálásakor vagy új kód írásakor, amely potenciálisan duplikálódhat, megkérdezem magamtól:

Ez egyetlen tudásdarab, amely duplikálódott, vagy ez csak infrastruktúra, amely történetesen hasonlóan néz ki?

Szóval átkutattad a CSS-t, és találtál egy osztályt, amely történetesen rendelkezik a kívánt stílusokkal. Ez valószínűleg nem elég jó indok arra, hogy elkerüld egy másik osztály definiálását.

Hányszor ismétlődött ez a dolog?

Amíg egy valóban redundáns dolog nem jelenik meg legalább háromszor, én nagyon szkeptikus lennék minden olyan ismétlés-csökkentéssel kapcsolatban, ami növeli a komplexitást.

A duplikáció mostani csökkentése megnehezíti a jövőben az egyes esetek testreszabását?

Van valami kielégítő abban, amikor egy csomó copy-and-paste kódot refaktorálsz valami áramvonalasabbá és újrafelhasználhatóbbá. De a kód olyan szoros lezárása, hogy bármilyen változtatás speciális eseteket vezetne be, nem jó kompromisszum.

Ha csökkentem ezt a duplikációt, milyen arányban lesz az absztrakció mérete és a paraméterek száma között?

A könyvtárak és keretrendszerek azért nagyszerűek, mert újrafelhasználható kódot biztosítanak viszonylag kevés paraméterrel a testreszabáshoz. De képzeljünk el egy alkalmazásspecifikus függvényt egy párbeszédpanel megjelenítésére, amely megnőtt, és most már 20 paramétert fogad el. Bármilyen előnye is volt az ismétléscsökkentésnek, amikor 2 paramétere volt, már nincs meg.

Következtetés

Mint sok szoftverfejlesztési alapelv esetében, a “ne ismételd magad” inkább iránymutatás, mint mantra.