Održavanje kvalitete programskog koda u Fleksbitu

CityCRM je jedan od naših glavnih pilot projekata. Projekt je narastao, oko 8 programera (što juniora što seniora) je radilo na projektu i kada smo započeli projekt, odmah smo definirali jako stroga pravila pisanja koda koje moraju naučiti svi juniori koji tek dođu na projekt.

Osim pravila, ekstremno nam je bitna konzistentnost iz jednostavnog razloga: kada neki drugi programer nastavlja nečiji posao, da se može odmah snaći i da zna u kojim datotekama se što nalazi.

Za primjer ću uzeti modul Kontakti:

  • URL do kontakata je /contacts
  • URL za uređivanje ili dodavanje je /contacts/aoe/:contactId? (aoe znači Add or Edit)
  • sve stvari vezane uz kontakte se nalazi unutar contacts direktorija
  • lista entiteta (u ovom slučaju kontakata) se nalazi uvijek unutar index.php stranice, a pripadajući kontroler je contacts.js dodavanje ili uređivanje se nalazi unutar aoe.contacts.js datoteke
  • detaljan pregled se nalazi unutar details.contacts.js

Postoji još 15-ak pravila samo uz organizaciju datoteka u projektu, a tu su i pravila samog pisanja koda:

  • JavaScript, bez obzira što ne moramo pisati točku-zarez, ona je obavezna
  • uvijek pisati funkcionalnu verziju petlji umjesto for, foreach, itd. (dakle, polje.forEach())
  • na vrhu kontrolera se moraju nalaziti sva svojstva klase
  • varijabla vm (view-model) uvijek mora pokazivati na this

Imamo još 30-ak pravila vezanih uz sami kod.

Kako održavamo ovakav kod stabilnim?

Često radimo code-review odnosno pregledavamo kod i komentiramo što bi se moglo poboljšati i ubrzati. TOP prioritet su sigurnosni propusti koji ne smiju proći kroz testiranje te iz tog razloga kod provjeravaju barem 2 iskusnija programera.

Ciklus se ponavlja dokle god ne dođemo do granice koja nam odgovara i onda idu završna testiranja. Do sada se pokazalo da juniori naprave sve pogreške koje mogu napraviti, ali i da se te greške više ne ponavljaju kroz neka 2 mjeseca i taj napredak programera nam je izuzetno bitan. Pokušavamo stvoriti svijest programerima da ono što trenutno pišu, su ozbiljne stvari i da će te stvari koristiti ljudi o kojima ovisi naše poslovanje i njihovo povjerenje.

Završno testiranje

Meni omiljeno ne-tehničko testiranje je da pronađemo prosječnog korisnika i damo mu novu verziju programa. Ako se ta osoba ne snalazi u programu, znači da nešto nismo napravili dobro i taj element koji je sporan ponovno prolazi ciklus naveden gore. Ovakve stvari također dolaze s iskustvom.

BitHound testiranje

Odlučili smo naš programski kod “provući” kroz profesionalne sustave poput BitHound koji rade statičku analizu koda i pronalaze moguće pogreške. Obzirom da znam da takvi alati “rade od muhe slona”, moje iskreno očekivanje je bilo oko 60%. Sustav je ocijenio naš kod kao 96/100 što je fantastičan rezultat i već smo počeli uređivati datoteke da možemo reći da imamo gotovo savršen sustav (naravno, pričamo o tehničkoj strani).

Što su bili problemi, zašto nemamo 100/100?

Pa… nedostajalo nam je nekoliko točki-zareza i trebali bi refaktorirati nekoliko metoda. To nam je bio TOP prioritet danas i već smo ih ispravili i nadogradili zastarjele pakete. Nova verzija sustava ide u produkciju nakon što prođu sva naša interna testiranja navedena gore.