Koodikatselmointikulttuuri ja PR-käytännöt

Koodikatselmointi ei ole portinvartijuutta, vaan tapa oppia yhdessä, siirtää vastuuta ja pitää laatu korkealla. Hyvä katselmointikulttuuri vahvistaa koko tiimiä; huono kulttuuri luo pullonkauloja ja katkeruutta.

1) Pidä se pienenä (mahdollisuuksien mukaan alle 400 riviä). 2) Kirjoita selkeä kuvaus: miksi, mitä ja miten testataan. 3) Linkitä tiketti. 4) Lisää käyttöliittymämuutoksiin kuvakaappauksia tai videoita. 5) Tarkista diff itse ennen katselmoijien pyytämistä.

Käytä samoja vakiintuneita etuliitteitä kuin commit-viesteissä: feat: add user profile page, fix: handle 404 in fetch wrapper, refactor: extract Avatar component. Monet tiimit luovat näistä muutoslokit automaattisesti.

Useimmilla tiimeillä on PR-malli — asenna se tiedostoon .github/pull_request_template.md.

Käy oma diffisi rivi riviltä läpi ennen katselijoiden pyytämistä. Lisää kommentteja, jotka selittävät epäselvät ratkaisut. Usein löydät omat virheesi ennen kuin jonkun muun tarvitsee löytää ne.

2000 rivin PR katselmoidaan harvoin perusteellisesti. Jaa se osiin: 1) refaktorointi (ei käyttäytymismuutoksia), 2) uusi toiminnallisuus, 3) käyttöliittymän viimeistely. Jokainen osa on helpompi katselmoida ja palauttaa ennalleen.

Muotoile palaute kysymyksiksi, älä käskyiksi: 'Mitä mieltä olet tämän siirtämisestä hookiin?' toimii paremmin kuin 'siirrä tämä'. Erota pakolliset korjaukset hyödyllisistä mutta valinnaisista parannuksista. Käytä etuliitteitä: nit:, question:, blocker:.

'Tämä on sekava' ei kerro tekijälle mitään. 'Minun piti lukea tämä kolme kertaa ymmärtääkseni aikaisen palautuksen — voisimmeko irrottaa tästä guard clausen?' antaa hänelle jotain, jonka perusteella toimia.

Kommentoi myönteisesti oivaltavia ratkaisuja, hyvää nimeämistä ja hyödyllisiä testejä. Se kannustaa toistamaan näitä käytäntöjä ja pehmentää muuta palautetta. PR:t, jotka saavat osakseen pelkkää kritiikkiä, tuntuvat vastakkainasettelulta.

Prettier huolehtii muotoilusta. ESLint huolehtii tyylistä. Älä tuhlaa katselmointikierroksia sarkainten ja välilyöntien vertailuun. Jos jokin tyylisääntö nousee jatkuvasti esiin, määritä se linterissä.

Testit ovat myös koodia. Varmista, että uudelle koodille on testit. Tarkista, että testit todella testaavat oikeaa asiaa — monet testit menevät läpi rikkinäisinäkin, koska ne tarkistavat väärän asian.

Vastaa jokaiseen kommenttiin, vaikka vain peukkuemojilla. Perustele eriävä mielipiteesi ehdotuksista, joista olet eri mieltä (sinä kirjoitit koodin, joten sinulla saattaa olla lisäkontekstia). Merkitse ratkaistut keskustelut ratkaistuiksi. Päivitä PR:n kuvaus, jos laajuus muuttuu.

Katselmoi yhden työpäivän kuluessa. Vanhentuneet PR:t menettävät kontekstinsa — tekijä on siirtynyt eteenpäin ja haara tarvitsee rebasoinnin. Viikon ajan odottavat suuret PR:t johtavat aina tuskallisiin yhdistämisiin.

GitHubin ehdotusominaisuuden avulla tekijä voi hyväksyä korjauksen yhdellä napsautuksella. Se on paljon nopeampaa kuin kirjoittaa tekstinä 'muuta tämä rivi muotoon X'.

Hyväksy, kun koodi on oikein, testit menevät läpi, ymmärrät muutoksen ja sen voi yhdistää turvallisesti. Hyväksyminen tarkoittaa, että otat osavastuun lopputuloksesta. Älä hyväksy automaattisesti — jos et lukenut muutosta, sano se.

Tekijä: pienet, hyvin kuvatut PR:t, joissa on kuvakaappaukset ja testit. Tarkista ensin itse. Katselmoija: rakentavaa, kysymyksiin perustuvaa palautetta. Erota estävät ongelmat pienistä huomioista. Kehu hyvää. Ohita tyyli — anna työkalujen hoitaa se. Katselmoi päivän kuluessa. Hyväksy vain, kun ymmärrät muutoksen. PR-mallit yhdenmukaistavat prosessin. Katselmoinnit ovat yhteistyötä, eivät portinvartijuutta.