Junior-ohjelmistosuunnittelijana olen aina perehtynyt saamiini koodin tarkistuskommentteihin oppiaksesi siitä, kuinka tulla paremmaksi kooderiksi. Mutta kun tuli aika yrittää ensimmäistä koodin tarkistusta, tajusin, ettei kokemukseni ollut valmistellut minua olemaan toisella puolella.
Kehitin vakaan tapauksen, jolla esiintyy huijausoireyhtymää, kääntyen alaspäin kysymyksillä: Pitäisikö minun kommentoida tätä koodiriviä vai eikö se ole sen arvoista? Pitäisikö minun löytää artikkeleita jokaisen kommentin tueksi? Kaatunko sivuston hyväksymällä tämän? Vihaavatko he minua? Okei, myönnän, että spiraalin melko nopeasti. Puhuessani joillekin työtovereilleni tiesin, etten ollut yksin huolissani.
Junior-ohjelmistosuunnittelijat saatetaan heittää koodin tarkistamiseen olettamalla, joka on samanlainen kuin ”tiedät kuinka lukea kirjaa, niin osaat kirjoittaa kirjan, mikä ei ole totta”, sanoo GitHubin kokemusinsinööri Jessica Rudder.
Koodien tarkistamiseen liittyy odotuksia, ja prosessi voi olla hermoa raivoava. Joten haastattelin seitsemää muuta ohjelmistosuunnittelijaa kerätäkseen vinkkejä arvioivan ajattelutavan luomiseen.
1. Ajattele yleisiä vaikutuksia
Yleisesti ottaen hyvän pull-pyynnön (PR) tulisi vaikuttaa vain rajoitettuun osaan kooditietokantaa. Rajoitettu soveltamisala ei kuitenkaan saisi estää sinua ajattelemasta koodimuutosta suuremman kooditietokannan yhteydessä.
Nigel Munoz, entinen The Musen täyspino-insinööri ja nykyinen freelance-ohjelmistoinsinööri, rohkaisee tarkastajaa ajattelemaan ”miten tämä muutos vaikuttaa suurempaan ja pienempään kuvaan.” Suuremman kuvan huomioon ottaminen sisältää mahdollisten teknisten velkojen löytämisen - etsi koodi joka toistuu, ei ole modulaarinen tai ei noudata viimeisimpiä vakiokäytäntöjä - samoin kuin analysoi muutoksia kooditietokannan arkkitehtuuriin.
Hudson River Tradingin ydinkehittäjä Sam Donow uskoo, että ”mikään ei ole liian suuri tai liian pieni kommentoitavaksi. Ehdotukset pieniksi parannuksiksi voivat johtaa suurempiin parannuksiin koodekin useissa osissa. "
Voit käyttää PR-kommenttia GitHubissa antaaksesi positiivista palautetta sekä huomauttaaksesi, missä koodi voi poiketa Reakt-kehyksen vakiokäytännöistä.
Esimerkiksi yhden oman koodikatsaukseni aikana sain kommentin, että tietyt React-komponentin ominaisuudet olivat hämmentäviä, mikä herätti laajempia kysymyksiä komponentin käytöstä. Viime kädessä poistin ominaisuudet alkuperäisestä komponentista ja loin erillisen komponentin selventämään niiden ominaisuuksia ja varmistamaan, että molempia voidaan käyttää useammassa paikassa.
2. Harkitse turvallisuutta
Muista, että jotkut muutokset voivat vaikuttaa muutakin kuin vain kooditietokantaan. Rudder suosittelee arvioimaan, voisiko käyttäjä käyttää tätä toimintoa häiritäksesi toista vai väärinkäyttää järjestelmää. Esimerkiksi, jos vetämispyynnön uusi ominaisuus sisältää käyttäjän syöttämisen, etsi SQL-injektiota, pääsyä tietoihin, sivustojenvälisiä komentosarjoja ja muut turvallisuusheikkoudet.
3. Keskity virheisiin
Koodin avustajat - riippumatta siitä, kuinka robottisina ne näyttävät - ovat ihmisiä, ja ihmiset saattavat rikkoa tai unohtaa toiminnot. Joten varmista, että “tarkistat testit samalla merkityksellä kuin muilla koodeilla”, neuvoja Abhishek Pillai, opettajien palkkaopettajien tekninen johtaja. "Ne estävät uusia virheitä ja toimivat dokumentaatiomuotona kaikille muille, jotka työskentelevät tämän parissa tulevaisuudessa."
Testien lukeminen voi auttaa sinua ymmärtämään uuden ominaisuuden toimivuutta ja nähdä sen käyttöön otettavat eri tapaukset, kun taas testien analysointi voi auttaa sinua osoittamaan puuttuvat tapaukset ja löytämään ominaisuuksia, joita tämä PR ei sisällä. Jos koodimuutokseen ei sisälly testejä ja ne vaikuttavat merkityksellisiltä, on aiheellista pyytää niitä tarkistuksen yhteydessä.
Mutta testit eivät ole kaikkea. ”Älä luota liikaa järjestelmään, ” Donow varoittaa. "Vain siksi, että suoritetut testit eivät tarkoita, ettei virheitä olisi."
Voit myös ajaa “suorittaa sovelluksen paikallisesti testataksesi sen toiminnallisesti ja varmistaaksesi, että se toimii. Jos se ei toimi, niin ei ole tarvetta jatkaa tarkistamista ”, sanoo 8th Lightin ohjelmistokehittäjä Ryan Verner. Vaikka jotkut arvioijat eivät usko, että manuaalisen testauksen tulisi olla osa koodin tarkistusprosessia - osittain sen vuoksi, että se vie aikaa - Verner uskoo, että se on nopea tapa selvittää, pitäisikö sijoittaa enemmän aikaa tarkistamiseen, sekä strategian, joka auttaa vähentämään virheiden määrän kasvu.
4. Ole joukkuepelaaja
Kliisee saa uuden merkityksen koodin tarkistamisessa. "Ota aikaa tarkistamiseen, koska se on kaikkien kooditietokanta", sanoo "kollektiivisen omistajuuden" puolestapuhuja Verner. Sinun, tarkistajana, pitäisi pyrkiä suojelemaan virheiden määrää kasvamasta suuremmiksi tavoitteena antaa sinulle joukkue vähemmän työskentelee rivillä.
Pillai käyttää gifiä juhlimaan joukkuetoveriensa hyväksymiä ja sulautumisvalmiita PR: itä.
Samanaikaisesti The Musein tekninen johtaja Charles Luxton kannustaa arvioijaa ymmärtämään ja muistamaan joukkueen prioriteetit. Nopeasti lähestyvien määräaikojen ja erimielisyyksien vuoksi on joskus luotava tehtävälomake, joka varmistaa, että tulevaisuudessa tehdään parannuksia, ja kommentin lisääminen kyseiseen koodiin sillä välin on Band-Aid, jota tarvitset Pidä joukkueesi onnellinen.
Lopuksi, kysymällä itseltäsi, onko koodilla järkeä jollekin juuri liittyneenä joukkueeseen ja lukemassa sitä muutaman ensimmäisen viikon aikana, autat pitämään koodisi luettavana ja ymmärrettävänä.
5. Käytä oppimista ja tiedon jakamista
Tarkasteluprosessi antaa jokaiselle mukana olevalle paikalle mahdollisuuden saada enemmän tietoa koodiperustasta, kielistä, kehyksistä ja parhaista käytännöistä.
The Musein tekninen johtaja Matt Jeffery kehottaa arvioijaa "ymmärtämään muutokset arkkitehtonisesti. Yksi tapa on lukea tiedostonimiä, koska ne auttavat antamaan kontekstin. Esimerkiksi jos tarkastelet muutosta tiedonsiirtokerroksessa. tiedät, että et käsittele liiketoimintalogiikkaa tai käyttöliittymää. "
Voit jakaa dokumentaatiota PR-kommentilla GitHubissa.
Kun opit koodimuutoksista, sinulla on myös mahdollisuus jakaa tietoa. "Parasta on selittää mielipiteesi ja varmuuskopioida se dokumentoinnilla", Luxton sanoo. Antamasi linkit tukevaan näyttöön ja luotettaviin artikkeleihin auttavat tarkastajaa ja koodikirjoittajaa tutkimaan erilaisia lähestymistapoja lopullisen päätöksenteon yhteydessä, mutta parantavat myös ohjelmointitietonsa.
Pidä nämä vinkit mielessä, muista myös, että tarkistaminen on aika käyttää ihmisten taitoja. "Antakaa ihmisille hyöty epäilystä siitä, että he ajattelivat lähestymistapaansa ja tuovat esiin erilaisia mahdollisuuksia yrittäessään hajottaa puolustuskyvyn", Rudder sanoo. "Jätä kommentit koko ajan ja kääriä kommentin - tässä on hienoa, tässä on mitä voidaan parantaa, tässä mitä on muutettava ennen yhdistämistä."
Tällaisen lähestymistavan avulla suojaat koodikantasi tekniikan lainoilta, tietoturvauhilta ja virheiltä, ja rakennat myös ryhmääsi.
