Atomic Spin

Ohjelmistokehittäjät ovat hyviä tunnistamaan malleja. Ehkä se on luontainen taito, joka vetää meitä tähän ammattiin. Tai ehkä se on ohjelmistojen kirjoittamisen prosessi, joka kehittää tätä taitoa. Oli miten oli, ”älä toista itseäsi” (DRY) on tämän taidon luonnollinen sovellus.

Mutta toisto itsessään ei ole se vihollinen, joksi tämä periaate sen tekee.

Don’t Repeat Yourself

Niin intuitiivista kuin ”älä toista itseäsi” voikin olla, The Pragmatic Programmer tiivistää sen näin:

Jokaiseen tietoon on saatava yksi ainoa, yksiselitteinen ja auktoritatiivinen esitys järjestelmässä.

Ei ole vaikea kuvitella hyötyjä, joita toiston vähentäminen tai poistaminen tuo mukanaan.

• Vähemmän päällekkäisyyttä tarkoittaa vähemmän ylläpidettävää koodia. Ja jos paras koodi on se, ettei koodia ole lainkaan, tämä kuulostaa hyvältä asialta.
• Yksittäinen totuuden lähde eliminoi sen mahdollisuuden, että asiat menevät sekaisin. Jokin liiketoimintasääntö on muuttunut? Päivitä se yhdessä paikassa, ja se on tehty.
• Koodi on uudelleenkäytettävää. Onko sinulla prosessi, joka on yhteinen kolmelle asialle, ja aiot lisätä neljännen? Suurin osa työstä on jo tehty.

Joskus toista itseäsi

Jos olet liian innokas vähentämään näennäistä päällekkäisyyttä, se voi luoda enemmän ongelmia kuin ratkaista. Sanon ”näennäinen päällekkäisyys”, koska joskus samankaltaisilta näyttävät asiat eivät todellisuudessa liity toisiinsa. Esimerkiksi kaksi tietorakennetta, joilla on identtiset ominaisuudet ja tyypit, voivat olla rakenteellisesti samoja, mutta eivät semanttisesti.

Yleinen strategia päällekkäisen koodin vähentämiseksi on poistaa yhteiset osat ja piilottaa ne abstraktion taakse. Tämän ei-toivottu sivuvaikutus on kuitenkin se, että se kytkee kaiken abstraktiota käyttävän. Mikä tahansa muutos abstraktiossa vaikuttaa kaikkiin sen kuluttajiin. Ja vastaavasti abstraktiota saatetaan joutua taivuttamaan yhden ainoan kuluttajan vaatimusten mukaiseksi.

Tämä kytkennän lisääntyminen merkitsee myös joustavuuden vähenemistä. Sanotaan, että sinulla on prosessi, jota käytetään kolmessa paikassa. Se on lähes sama kaikissa kolmessa paikassa, vain muutamia tärkeitä eroja lukuun ottamatta. Joten toteutat prosessin yhtenä moduulina, joka ottaa muutaman parametrin kattaakseen erot.

Prosessin muokkaaminen vain yhtä näistä käyttötapauksista varten on nyt mahdotonta: mikä tahansa muutos yhteen vaikuttaa kaikkiin kolmeen. Toki voit lisätä lisää parametreja (tai erikoistapauksia!), kun käyttötapaukset eroavat toisistaan. Mutta nopeasti käy mahdottomaksi erottaa prosessin tärkeitä osia käyttötapaukset erottavasta infrastruktuurista.

Kysymyksiä, joita kannattaa kysyä

Kun refaktoroin olemassa olevaa koodia tai kirjoitan uutta koodia, joka saattaa mahdollisesti olla päällekkäistä, kysyn itseltäni:

Onko tämä yksittäinen osaaminen, joka on päällekkäistä, vai onko tämä vain infrastruktuuria, joka sattuu näyttämään samankaltaiselta?

Kaivelit siis CSS:ää ja löysit luokan, jossa sattuu olemaan haluamasi tyylit. Se ei luultavasti ole tarpeeksi hyvä syy välttää toisen luokan määrittelyä.

Kuinka monta kertaa tämä asia on toistettu?

Kun todella redundantti asia ei esiinny vähintään kolmeen kertaan, olisin hyvin skeptinen kaikenlaisen monimutkaisuutta lisäävän toiston vähentämisen suhteen.

Meneekö päällekkäisyyksien vähentäminen nyt vaikeuttamaan yksittäisten tapausten muokkaamista tulevaisuudessa?

On jotain tyydyttävää siinä, kun refaktoroidaan joukko copy-and-paste-koodia joksikin virtaviivaisemmaksi ja uudelleenkäytettävämmäksi. Mutta koodin lukitseminen niin tiukasti, että mikä tahansa muutos toisi mukanaan erikoistapauksia, ei ole hyvä kompromissi.

Jos vähennän tätä päällekkäisyyttä, mikä on abstraktion koon ja sen tarvitsemien parametrien määrän suhde?

Kirjastot ja kehykset ovat loistavia, koska ne tarjoavat uudelleenkäytettävää koodia, jossa on suhteellisen vähän parametreja muokattavaksi. Mutta kuvittele sovelluskohtainen funktio valintaikkunan esittämiseen, joka on kasvanut ja ottaa nyt vastaan 20 parametria. Mikä tahansa toiston vähentämisen hyöty olikaan olemassa, kun sillä oli kaksi parametria, sitä ei enää ole.

Johtopäätös

Kuten monien ohjelmistokehitysperiaatteiden kohdalla, ”älä toista itseäsi” on enemmänkin ohje kuin mantra.