Kahdessa edellisessä osassa sarjaa puhuimme ohjelmoijan uran ensimmäisistä askelista ja siitä, mitä todella kannattaa opetella uran alussa.
Nyt pääsemme hetkeen, jota melkein jokainen junior pelkää.
Ensimmäinen code review. Ensimmäiset kommentit koodiin. Ensimmäiset korjaukset.
Ja ensimmäinen ajatus: "Olinko todella kirjoittanut tämän koodin niin huonosti?"
Rauhoitu.
Me kaikki olemme joskus käyneet tämän läpi.
Code review ei ole koe
Tämä on ehkä suurin väärinkäsitys aloittelevien kehittäjien keskuudessa.
Monet juniorit ottavat kommentit koodaansa hyvin henkilökohtaisesti. Syntyy stressiä. Epävarmuutta. Joskus turhautumista.
Kuitenkin code reviewn tarkoitus ei ole todistaa kenellekään, että hän on tehnyt virheen. Päinvastoin. Se on yksi tärkeimmistä osista hyvän ohjelmiston kehitysprosessia.
Code reviewn avulla:
- vähennämme virheiden riskiä,
- parannamme koodin luettavuutta,
- opimme toisiltamme,
- pidämme projektin yhtenäisenä,
- välitämme tietoa tiimin jäsenten välillä.
Parhaat tiimit eivät kohdista code reviewta valvontana. Ne näkevät sen päivittäisenä kokemusten vaihdantana.
"Sinulla on 37 kommenttia"
Kuulostaa uhkaavalta? Aluksi niin.
Ensimmäinen pull request usein näyttää tältä:
- Kommentti.
- Korjaus.
- Vielä yksi kommentti.
- Seuraava korjaus.
Tunnin jälkeen tuntuu siltä, että koko koodi pitäisi heittää roskiin. Se on normaalia.
Muista vain yksi asia. Senior ei korjaa koodia näyttääkseen paremmuuttaan. Hän tekee sen, koska muutaman kuukauden kuluttua kirjoitat paljon parempaa koodia.
Ja juuri siitä on kysymys.
Hyvä senior ei sano vain "huono"
Parhaat kehittäjät, joiden kanssa olemme työskennelleet, selittivät aina:
- miksi jotain kannattaa tehdä toisin,
- mitä seurauksia nykyisellä ratkaisulla on,
- mitä vaihtoehtoja on,
- mikä ratkaisu on helpompi ylläpitää vuoden tai kahden päästä.
Iso ero.
Sillä voi sanoa: "Tämä on väärin."
Tai voi sanoa: "Tämä toimii, mutta jos kehitämme moduulia puolen vuoden päästä, sen ylläpito on paljon helpompaa tällaisessa rakenteessa."
Toisessa tapauksessa opit jotain paljon arvokkaampaa kuin pelkän korjauksen. Opit ajattelutavan.
Clean code ei tarkoita kaunista koodia
Tämä on toinen käsite, joka usein ymmärretään väärin.
Clean code ei tarkoita näyttävää koodia. Kyse ei ole tyhjien rivien määrästä. Ei funktion pituudesta. Ei edes tietyistä malleista.
Kyse on paljon yksinkertaisemmasta asiasta – koodin tulee olla luettavaa.
Jos puolen vuoden päästä avaat oman projektisi etkä muista, mitä olit ajatellut...
...todennäköisesti koodi ei ollut tarpeeksi luettavaa.
On sanonta: Kirjoitamme koodia ihmisille. Kääntäjä vain tarkistaa syntaksin.
Ja siinä on paljon totuutta.
Älä rakastu omaan koodiisi
Tämä on yksi tärkeimmistä opeista.
Koodi ei ole taideteos. Se ei ole maalaus. Se ei ole veistos.
Se on työkalu tietyn ongelman ratkaisemiseksi.
Jos joku ehdottaa parempaa ratkaisua...
...on syytä harkita sitä.
Ei siksi, että joku on auktoriteettiltaan suurempi. Siksi, että ehkä se todella on parempi.
Eniten oppivat kehittäjät, jotka osaavat sanoa: "Olet oikeassa. Tehdään se toisin."
"Minulla toimii"
No niin. Lopulta on pakko käsitellä sitä kuuluisaa lausetta. Jokaisella software housella on oma versionsa tästä vitsistä...
Kuvittele tilanne.
Testaaja löytää virheen.
Kehittäjä vastaa: "Minulla toimii."
Testaaja tarkistaa uudelleen. – Ei toimi.
Project manager katsoo. – Ei toimi.
Asiakaskin tarkistaa. – Ei toimi.
Mutta... tekijälle koodi toimii yhä.
Kuulostaako tutulta?
Useimmiten ongelma ei ole itse koodissa.
Syyjä voi olla monia:
- eri datan versio,
- eri ympäristö,
- välimuisti,
- konfiguraatio,
- oikeudet,
- selain,
- käyttöjärjestelmä,
- tapauksia, joita kukaan ei aiemmin ennakoinut.
Siksi ammattimainen kehittäjä ei lopeta analysointia lauseeseen: "Minulla toimii."
Hän kysyy seuraavan kysymyksen.
Miksi minulla toimii, mutta muualla ei?
Ja silloin alkaa oikea debuggaus.
"Se on vain pieni muutos"
Toinen lause, joka saa useimmat software houset hymyilemään hieman varovaisesti.
Asiakas sanoo: "Se on vain pieni korjaus."
Kehittäjä tietää jo, että hetken kuluttua hän avaa tiedoston, jota kukaan ei ole koskenut kuuteen vuoteen.
Ja se "pieni korjaus" saattaakin tarkoittaa muutosta viidessä moduulissa, kolmessa integraatiossa ja kahdessa tietokannassa.
Siksi kokeneet kehittäjät suhtautuvat hyvin varovaisesti sanaan "vain".
Alan tunnetuimmat lausahdukset
Jokaisella alalla on omat sanontansa. Myös kehittäjillä.
Monet niistä ovat varmasti tuttuja:
- "Minulla toimii."
- "Vain viisi minuuttia."
- "Tämä ei ole bugi. Tämä on feature."
- "Eihän minä muuttanut mitään."
- "Se kaatui tuotannossa."
- "Vielä yksi deploy."
- "Varmasti välimuisti."
- "Nopea korjaus ennen viikonloppua."
- "Tämän pitäisi toimia."
Ja ehkä vaarallisin: "Laitetaan tämä tuotantoon perjantaina klo 16:00."
Jos työskentelet IT:ssä...
...todennäköisesti hymähtelit juuri.
Kehittäjä ei työskentele yksin
Tämä aihe jätetään usein huomiotta. Todellisuudessa useimmat projektit ovat tiimityötä.
Kehittäjä tekee yhteistyötä:
- UX-designerien,
- UI-designerien,
- project managerien,
- testaajien,
- devopsien,
- ylläpitäjien,
- analyytikkojen,
- asiakkaiden kanssa.
Siksi yhtä tärkeää teknisen osaamisen kanssa ovat:
- viestintä,
- kuuntelutaito,
- tiedon jakaminen,
- vastuullisuus,
- toisen kunnioittaminen.
Paras koodi ei pelasta projektia, jos tiimi ei osaa tehdä yhteistyötä.
Sanasto
Code review
Prosessi, jossa muut kehittäjät tarkastavat koodin ennen sen käyttöönottoa. Tavoitteena on parantaa koodin laatua, löytää virheitä ja jakaa tietoa.
Pull request (PR)
Ehdotus muutosten viemisestä projektiin. Juuri tässä vaiheessa code review yleensä tapahtuu.
Clean code
Lähestymistapa koodin kirjoittamiseen, jonka tärkein tavoite on luettavuus, yksinkertaisuus ja ylläpidettävyys, ei niinkään käytettyjen suunnittelumallien määrä.
Debuggaus (debugging)
Prosessi, jossa etsitään ja korjataan sovelluksen virheiden syitä.
Välimuisti (cache)
Mekanismi, joka säilöö väliaikaisesti dataa sovelluksen suorituskyvyn parantamiseksi. Se voi myös aiheuttaa monia arvoituksellisia ongelmia testaamisen aikana.
Yhteenveto
Mitä pidempään työskentelemme kehittäjinä, sitä enemmän tulemme yhteen johtopäätökseen. Parhaat kehittäjät eivät ole niitä, jotka tekevät vähiten virheitä.
Parhaat kehittäjät osaavat:
- löytää ongelman syyn nopeammin,
- toteuttaa johtopäätöksiä,
- oppia muilta,
- ottaa vastaan rakentavaa kritiikkiä,
- jatkuvasti kehittää omaa osaamistaan.
Code review ei siis ole este. Se on yksi arvokkaimmista opetuksista, jonka voit saada urasi alussa.
Viimeisessä osassa sarjaamme keskustelemme siitä, millainen tie johtaa juniorista senioriksi. Selitämme, miksi senior-kehittäjä ei ole vain kymmenen vuoden kokemus, vaan henkilö, joka osaa kantaa vastuuta projektista, ajatella liiketoimintalähtöisesti ja auttaa muita tiimin jäseniä kehittymään.
