Code review

Feature branches

Peale ülesande endale määramist ning selle "tegemisel" märkimist tuleks lisada kommentaar, kus hindan ülesande peale kuluvat aega enne sellega alustamist.

/estimate 30m

Enne kui alustan tööga:

  • Projekt on lokaalselt kloonitud

  • Loodud on uus haru, mille nimi algab pileti numbriga (näiteks: 4-exit-button-bug)

Nüüd võib tööle hakata.

Ühel piletil üks haru

Mida suuremaks koodibaas kasvad, seda olulisem on, et muudatused oleksid seotud kindla piletiga.

Seetõttu on hea tava luua iga pileti jaoks eraldi haru - muudatused ja commit sõnumid on git'i ajaloost hästi jälgitavad ning osutuvad tagant järgi vaadates kasulikuks.

Eraldi harud muudavad ka kindlate muudatuste valmissaamise lihtsalt - kui sul on CI/CD paigas, siis haru liitmine main haruga käivitab enamasti automaatslet build'i.

Commit sõnumid

Commi't sõnumid peaksid olema:

  • Lühikesed kuid informatiivsed

  • Arusaadavad ka teistele

Commit’i sõnumite reeglid varieeruvad tiimiti, kuid sageli järgitakse seda formaati:

Kui mergetakse, siis see commit {teeb mida}

Isegi kui sinu tiim ei ole commit sõnumite osas väga range, peaksid siiski alati dokumenteerima, mida tegid. Kommentaarid nagu fix, mis toimps, lol ei anna teistele koodibaasi kasutajatele suurt midagi. Sageli teed ka sellega endale karuteene, sest ei mäleta 3 kuud hiljem, mida seal tegid.

Commit message comic

See on väike asi, kuid väga tähtis.

Kui tahad commit sõnumis lisada pikema selgituse või bullet-listi parandustest, jaga see mitmele reale - commiti pealkiri peaks mahtuma 100 tähemärgi sisse. Erinevad koodiredaktorid/IDE-d kuvavad blame’i erinevalt, kuid lühike ja sisukas kokkuvõte on tavaliselt kõige informatiivsem.

Pull/merge requestid and koodiülevaatused

Kui olen oma ülesandega ühele poole jõudnud, tuleks lasta ka mõnel teisel inimesel/spetsialistil see üle vaadata enne kui seda main harusse lisada. See ongi sisuliselt koodiülevaatus.

Neid tehakse peamiselt Merge Request'ide (GitHub'is Pull Request'ide) kaudu. Nende formaat varieerub tihti vastavalt tiimist/töökohast. Üldjuhul sisaldab see vabas vormis kirjeldust tehtust, viidet seotud piletile või teistele merge request'idele ning samme, millega saab kinnitada funktsionaalsuse ootuspärast töötamist.

Repode omanikud määravad tihti kohustuslikuks, et vähemalt kaks inimest peavad muudatused üle vaatama enne, kui need põhiharusse lisatakse - see aitab tagada, et serveritesse ning klientideni jõuab vaid kontrollitud kood.

Koodiülevaatuste rangus varieerub tiimiti, kuid mõistlik on:

  • Branch lokaalselt check outida

  • Muudatused oma arvutis üle testida (see on märksasti kergem kui koodikirjutaja on ette kirjutanud, mida testida - nii nagu eelnevalt rääkisime)

Võib olla, et nende kood töötas ainult nende lokaalses seadmes, konkreetses brauseris või ainult teatud olukorras.

Kui teed kontrolli, mõtle:

  • Kas kood saaks olla efektiivsem?

  • Kas on erijuhte, mis on jäänud käsitlemata?

  • Kas uutele funktsionaalsustele on ka testid kirjutatud?

  • Kas sul tekib mingite otsuste/lahendusviiside kohta küsimusi?

  • Kas see kood läheb vastuollu tiimis kokkulepitud tavadega?

  • Kas koodis on liiga palju/vähe kommentaare?

Jäta kommentaare! Väga harva leidub merge requeste, kus esimesel korral on kõik ideaalne ning enesestmõistetav. Kui tekib küsimusi või miski tundub puudulik tuleks jätta kommentaare.

Lisamärkused

  • Väga kasulik tööriist, mida kasutatakse näiteks NodeJS/JavaScript projektides on commitlint.

See sunnib sind kirjutama korralikke commit sõnumeid või siis täielikult blokeerib commiti, kui sõnum ei vasta reeglitele. Esialgu on see väga tüütu kuid pikas perspektiivis tuleb see kogu tiimile väga palju kasuks.

  • Kui alustad arendajatööd võta aega, et mõista oma tiimi commit'i tavasid. See võib tunduda nagu väike asi, kuid mida kiiremini sa sisse sulandud, seda produktiivsemad saavad nii sina kui sinu tiim olla.