Perinteiset Commits eivät pelasta commit-viestejäsi
Tutkii, miksi pelkkä perinteisten committien noudattaminen ei riitä hyvien commit-viestien kirjoittamiseen, ja esittelee keskeisiä ajattelustrategioita, jotka parantavat kehitysprosessiasi ja luovat luonnollisesti merkityksellisiä committeja.
Nopea internet-haku paljastaa runsaasti artikkeleita, jotka opettavat sinulle, miten kirjoittaa commit-viestejä. 90 % näistä artikkeleista kehottaa käyttämään perinteisiä committeja. Silti huomattava määrä kehittäjiä kamppailee edelleen tämän kanssa. He tietävät, että heidän pitäisi noudattaa näitä konventioita, mutta he kokevat niiden soveltamisen käytännössä vaikeaksi. Joka kerta kun he tekevät committia koodille, he pohtivat tuskallisesti, pitäisikö heidän kirjoittaa "refactor" vai "chore". Olen jopa nähnyt projekteja, joissa commit-viestien lista koostuu pelkästään samasta viestistä: "feat: add page", koska commit-viestien kirjoittaminen oli heille liian haastavaa, ja he yksinkertaisesti luovuttivat.
On liian aikaista puhua perinteisistä committeista#
En sano, että perinteiset commitit ovat huonoja. Niillä on monia tunnettuja etuja:
Ne tarjoavat yhtenäisen muodon, mikä tekee commit-viesteistä standardisoidumpia
Ne ovat helppoja automaattisten työkalujen tulkita, mahdollistaen automaattisen muutoslokiin luomisen
Ne auttavat tiimin jäseniä ymmärtämään koodimuutosten tarkoituksen ja laajuuden
Ne mahdollistavat erilaisten koodimuutostyyppien nopean tunnistamisen
Kuitenkin, kun kehittäjä kamppailee edelleen hyvien commit-viestien kirjoittamisessa jopa perinteisiä committeja käyttäessään, artikkelin heittäminen heille siitä, kuinka käyttää perinteisiä committeja ja opettaa heille, mitä feat-tyypin tai fix-tyypin tarkoittaa, on itse asiassa merkityksetöntä. Se on kuin antaisi kehittyneet keittokirjan henkilölle, joka ei osaa kokata, opettamatta heille, miten käyttää perusainesosia ja -välineitä. Silti tällaisia artikkeleita on kaikkialla internetissä. Vähänpä he tietävät, että perinteiset commitit voivat todella olla tehokkaita vain, kun kehittäjillä on selkeä ajattelu ja kyky jakaa tehtävät tarkasti.
Joten, perinteiset commitit eivät ole huonoja, mutta ennen kuin pääsemme siihen, meidän on luotava oikea kehitysmieli ja käytettävä tieteellistä kehittäjäajattelua asioiden tekemiseen.
Koodimuutoksien pitäisi tehdä yksi asia kerrallaan#
Ohjelmistokehityksessä "tee yksi asia kerrallaan" on tärkeä periaate. Tämä koskee paitsi koodin kirjoittamista myös koodin commitointia. Kun keskitymme yhteen tiettyyn tehtävään tai muutokseen kerrallaan, koodimme tulee selkeämmäksi ja aikomuksemme selvemmiksi. Tämä menetelmä parantaa paitsi koodin luettavuutta myös yksinkertaistaa huomattavasti koodi-arviointiprosessia. Arvioijat voivat helpommin ymmärtää ja vahvistaa kunkin muutoksen tarkoituksen.
Lisäksi tämä menetelmä tarjoaa mukavuutta potentiaalisille koodikäänteille. Jos ongelmia ilmenee, voimme helpommin löytää ja peruuttaa tiettyjä muutoksia vaikuttamatta muihin liittymättömään osiin. Mikä tärkeintä, kun kukin muutos tekee vain yhden asian, tätä muutosta kuvaavasta commit-viestistä tulee luonnollisesti tarkempi ja merkityksellisempi.
Käytännössä tämä tarkoittaa, että meidän on selkeästi määriteltävä tehtävä, joka on tehtävä ennen kuin aloitamme koodauksen. Tehtävän suorittamisen jälkeen meidän pitäisi välittömästi commitata koodi sen sijaan, että odotamme useiden tehtävien valmistumista ennen kuin commitoimme yhdessä. Jos havaitsemme muita alueita, jotka vaativat muutoksia nykyisen tehtävän suorittamisen aikana, paras lähestymistapa on kirjata ne ylös ja käsitellä ne erikseen nykyisen tehtävän suorittamisen jälkeen. Esimerkiksi, kun toteutat toiminnon ja löydät joitain olemassa olevia virheitä, sinun ei pitäisi korjata virhettä heti uuden toimintokoodisi kanssa, vaan toteuttaa toiminto ensin ja sitten korjata löydetty virhe uudessa commitissa, tai korjata virhe ensin ja sitten commitoida toiminto.
Commit-viestit ovat olemassa ennen koodin kirjoittamista#
Monet kehittäjät alkavat miettiä miten kirjoittaa commit-viestejä vasta koodin valmistuttua, mutta todellisuudessa commit-viestien pitäisi olla olemassa ennen kuin aloitamme koodaamisen. Tämä johtuu siitä, että commit-viestit heijastavat pohjimmiltaan ne askeleet, jotka teemme tehtävän suorittamiseksi. Toisin sanoen, ne ovat meidän todo-kohtamme.
Kun aloitamme tehtävän, meidän pitäisi ensin miettiä, mitkä erityiset askeleet ovat tarpeen tehtävän suorittamiseksi. Nämä askeleet ovat meidän todo-listamme, ja samalla ne ovat tulevat commit-viestimme. Tällä todo-listalla jokaisella koodimuutoksellamme on tarkoitus, pitäen meidät keskittyneenä koodaamisen aikana ja estäen meitä poikkeamasta tehtävästä.
Mikä tärkeintä, tämä menetelmä voi merkittävästi parantaa tehokkuuttamme. Kun suoritamme vaiheen, vastaava commit-viesti on jo valmis, ja voimme käyttää sitä suoraan, vähentäen aikaa kuluvaa ajatustyötä muutoksen kuvailemiseen. Samalla, koska nämä commit-viestit tehdään, kun olemme saaneet kattavan ymmärryksen tehtävästä, ne ovat yleensä korkeampilaatuisia ja informatiivisempia.
Oletetaan, että sinun täytyy toteuttaa uusi käyttäjän rekisteröintitoiminto. Voisit suunnitella tehtävän seuraavasti:
Refaktoroi olemassa oleva lomakekomponentti tehdäksemme siitä yleisemmän ja uudelleenkäytettävän
Luo käyttäjän rekisteröintilomake
Toteuta API-integraatio käyttäjän rekisteröinnille
Lisää yksikkötestit käyttäjän rekisteröintitoiminnolle
Päivitä dokumentaatio käyttäjän rekisteröintitoiminnolle
Näiden tehtäväaskeleiden vastaavat commit-viestit voivat olla seuraavia:
refactor: paranna olemassa olevaa lomakekomponenttia uudelleenkäytettävyyttä varten
feat: luo käyttäjän rekisteröintilomake
feat: toteuta käyttäjän rekisteröinnin API-integraatio
test: lisää yksikkötestit käyttäjän rekisteröinnille
docs: päivitä dokumentaatio käyttäjän rekisteröintitoiminnolle
Tällä tavalla sinulla on selkeät tehtäväaskeleet ja vastaavat ytimekkäät commit-viestit ennen kuin aloitat koodaamisen. Nämä commit-viestit ovat itse asiassa todo-listasi, joka opastaa sinua koko toiminnon toteutusprosessissa.
Kun suoritat jokaisen vaiheen, voit käyttää vastaavaa commit-viestiä commitoidaksesi koodisi. Tämä ei ainoastaan auta sinua paremmin järjestämään ja suorittamaan tehtäviä, vaan myös varmistaa, että kukin commit keskittyy tiettyyn vaiheeseen, mikä tekee koko kehitysprosessista selkeämmän ja hallittavamman. Jos sinun täytyy hieman säätää commit-viestiä todellisessa koodauksessa, voit tehdä pieniä muutoksia kuvaamaan tarkemmin todellisia muutoksia.
Perinteisistä commiteista tulee luonnollinen valinta#
Kun kehitämme oikeanlaisen kehitysmielen, perinteisten committien käyttäminen tulee luonnolliseksi. Tässä vaiheessa huomaat, että sopivan tyyppiprefiksin (kuten feat, fix, refactor, jne.) valitseminen tulee vaivattomaksi, koska commit-viestisi heijastavat jo selkeästi tehtäväaskeleitasi.
Jos haluat oppia lisää siitä, miten käyttää perinteisiä committeja, verkosta löytyy monia erinomaisia artikkeleita. Mutta muista, että nämä standardit voivat olla todella tehokkaita vain, kun ne perustuvat oikeaan kehitysmieleen.
Hyvien commit-viestien kirjoittaminen ei ole vain tietyn formaatin noudattamista. Se vaatii meitä ylläpitämään selkeää ajattelua kehitysprosessin aikana, selventämään kunkin muutoksen tarkoituksen ja miettimään, miten työskentelyämme kuvaillaan ennen kuin aloitamme koodaamisen.
Perinteiset commitit ovat todellakin hyödyllinen työkalu, mutta ne voivat saavuttaa maksimitehonsa vain yhdistettyinä oikeaan kehitysmieleen. Harjoittelemalla kahta periaatetta "tee yksi asia kerrallaan" ja "ajattele commit-viestejä etukäteen", voimme paitsi parantaa commit-viestien laatua myös lisätä kokonaiskehitystehokkuutta ja koodin laatua.
Toivon tämän artikkelin auttavan sinua pohtimaan uudelleen kehitysprosessiasi ja kannustavan kokeilemaan näitä menetelmiä. Muista, että hyvien kehitystottumusten kehittäminen vie aikaa, mutta kun ne ovat muodostuneet, ne parantavat huomattavasti työtehokkuuttasi ja koodin laatuasi.
