kehittäjinä kuulemme usein kliseisiä lauseita, joita heitellään ympäriinsä kuten ”Älä toista itseäsi”. Otamme tällaisia ideoita ja juoksemme niiden kanssa, joskus vähän liiankin pitkälle.

on hyödyllistä astua taaksepäin ja arvioida, miksi teemme näitä asioita. Katsotaan nyt vaihtoehtoista ideologiaa kuivalle ohjelmoinnille.

kuiva määritellään (Wikipedian mukaan) seuraavasti:

jokaisella tiedolla on oltava yksi, yksiselitteinen, arvovaltainen esitys järjestelmässä.

osa tästä saattaa mennä hieman pedanttiseksi, mutta siitä voi olla apua, kun miettii jotain tällaista. Hajotetaan fraseerauksen osat.

jokainen pala

mikä on ”jokainen pala”? Voimmeko koskaan toistaa muuttujan nimeä? HTML-entiteetti?

Ok, ok. Joten voimme toistaa <div>’s ilman suurempia kysymyksiä, enkä usko kenenkään loukkaantuvan siitä. Mutta tämä herättää kysymyksen: milloin päätämme, että jostakin on tullut ”tieto”? Reactissa hyvä esimerkki voisi olla komponentti-mutta onko se PrimaryButton ja SecondaryButton vai tarkoittaako se yleistettyä Button luokkaa? Vastaus on yleensä pidetään ”mitä tahansa organisaatio valitsee”, mutta tämä voi silti jättää hyvä hieman epäselvyyttä noin mitä valitsemme Abstrakti.

tieto

Tämä on toinen monitulkintainen kohta – mitä määrittelemme tiedoksi? Harkitse tyyliteltyä nappielementtiä, jossa käytetään joitakin atomiluokkia, ja reagoi. Jos Senior dev 10 sekuntia luoda, he eivät ehkä pidä sitä tietoa kannattaa abstrahoida. Mutta nuoremmalle kehittäjälle, joka ei tunne järjestelmää hyvin, se tieto voisi olla hyvä abstraktio. Muuten he saattavat joutua metsästämään luokat, muistuttamaan itseään siitä, miten painikkeet toimivat, ja selvittämään syntaksin onClick. Tieto on suhteellista ja sen käyttäminen määritelmässä lisää epäselvyyttä.

päivitys: Xander jätti alla olevan kommentin. Mielestäni tämä artikkeli tekee hyvää työtä selittää, mitä ”tietoa” pitäisi tarkoittaa.

halusi vain jättää tämän tänne kiinnostuneille.

”kuivassa on kyse tiedosta, koodien päällekkäisyydestä ei ole kyse”
verraes.net/2014/08/dry-is-about-k …

yksi, yksiselitteinen, arvovaltainen esitys

”yksi” esitys jättää paljon toivomisen varaa. Devops-insinöörin näkökulmasta yksi esitys voi olla kokonainen sovellus, jonka he tarvitsevat käyttöönsä. Frontend Deville se voi olla komponentti. Ja backend dev, se voi olla menetelmä luokan tai API päätepiste. Mihin raja vedetään?

meillä on myös sana ”yksiselitteinen” – mutta kuten juuri totesin, tämän lauseen loppuosa määrittelee enemmän monitulkintaisuutta. ”Arvovaltainen” on järkevää – kuiva koodi pitäisi määritellä tarkasti, mitä se tekee ja olla totta, että määritelmä. Kuitenkin, että ei nimenomaisesti rajoitu kuiva koodi.

systeemi

vihdoin meillä on maailman ”järjestelmä” – tämä saa takaisin ”yhden” lausuman, josta keskustelimme hetki sitten. Mikä on ”järjestelmä”? Reactissa se voi olla komponentti tai Redux action/component/reducer. Konttiohjelmistossa voitaisiin puhua kokonaisesta kapselista tai vain yhdestä instanssista.

lopussa kuiva kaikki edistää usein ennalta optimointia, joka on tarpeetonta ja joskus jopa vahingoittaa kykyä kirjoittaa koodia. Joskus on vaikeampaa muokata abstraktia komponenttia tiettyyn käyttötapaukseen sopivaksi. Lisäät paljon monimutkaisuutta tai hajotat sen komponentin joksikin uudeksi-joka ei ole super kuiva. Et voi tietää jokaista käyttötapausta komponentillesi ensimmäisenä päivänä.

an alternative – Write Everything Twice (WET) programming

sen sijaan ehdotan WET-ohjelmointia. Minulle määritelmä olisi:

voit kysyä itseltäsi ”enkö ole kirjoittanut tätä ennen?”kaksi kertaa, muttei koskaan kolmea.

tällä määritelmällä fokus siirtyy pois ennenaikaisesta optimoinnista ja sen sijaan mahdollistaa saman koodin toistamisen pari kertaa. Se myös siirtää fokuksen enemmän suolistoreaktioon. Sen avulla voit tehdä päätöksiä tarkan käyttötapauksen perusteella. Jos olet rakentamassa web-sovellusta, haluat luultavasti abstrahoida painikkeesi osaksi komponenttia, koska aiot käyttää niitä paljon. Mutta jos on yksi sivu, joka on joitakin erityisiä muotoilu (ehkä hinnoittelu sivu?), sitten sinun ei tarvitse huolehtia liikaa abstracting pois komponenttien, että sivu. Itse asiassa, tässä järjestelmässä, jos tarvitset uuden sivun, joka oli samanlainen kuin erityinen sivu, voit vain kopioida / liittää ja muuttaa koodia tarvitset. Kuitenkin tällä hetkellä, että se tapahtuu kolmannen kerran, sen aika viettää hieman aikaa abstrahoimalla pois osat, jotka voidaan abstrahoida.

lisäisin myös tämän ehdon (sekä märkä – että KUIVAOHJELMAAN):