Tako kot na številnih drugih področjih se tudi pri razvoju programske opreme hudič pogosto skriva v podrobnostih. Medtem ko so algoritmi in uporabniški vmesniki pogosto v središču pozornosti, pa prave pogoje za odličen izdelek določajo podrobnosti, ki so ponavadi v ozadju. Ena od takšnih podrobnosti, ki se je že izkazala izjemno učinkovita pri razvijanju kode v podjetju Medius, so smernice Conventional Commons. Gre za preprost, a učinkovit način pisanja kode, ki ponuja strukturiran in pregleden vpogled v kodo oz. spremembe v kodi za razvijalce in končne uporabnike.

Kaj sploh so Conventional Commits?

Za tiste, ki jim tema kodiranja ni blizu, kratek povzetek. Ko razvijalcev naredi določene spremembe v kodi projekta, se te spremembe zapakirajo v paket, ki mu rečemo “commit”. Vsak commit vsebuje spremenjeno kodo in sporočilo, ki opisuje, kaj smo dosegli s spremembo. Ti commiti so nato poslani v repozitorij, kjer postanejo del celotnega projekta. Gre za podoben proces, kot če bi urejali deljen dokument na spleti, kjer je vsaka sprememba zabeležena.

Conventional Commits so smernice za pisanje takšnih sporočil v kodi. Ne gre za nekaj, kar smo si izmislili pri Mediusu, gre za javno dostopne specifikacije, ki postajajo vse bolj uporabljene pri mnogih odprtokodnih projektih. Format je zelo enostaven vendar učinkovit.

Anatomija Conventional Commita

Razumevanje smernic Conventional Commit postane še lažje, če si ogledamo vse komponente, ki sestavljajo commit sporočilo. Vsako sporočilo v tem okolju je strukturirano tako, da vsebuje določene elemente, ki kratko in jedrnato prenesejo informacijo o narejeni spremembi. Tako lahko seciramo conventional commit:

• Tip: To je osnova commit sporočila. Gre za kratek identifikator, ki signalizira vrsto spremembe, ki jo naredimo. Pogosti tipi so npr. fix, ki nakazuje na popravek napake v kodi ali feat, ki govori o novi funkcionalnosti.
• Izbirni obseg: Ta del nam ponudi kontekst, saj nakazuje na del kode, ki jo sprememba nagovarja. Čeprav je ta del izbirni, lahko zagotovi koristne informacije za razvijalce, ki želijo razumeti obseg naših sprememb. Primer: (UI) ali (backend)
• Opis: Tukaj gre za koncizno razlago sprememb. Ta naj bo kratka, vendar dovolj podrobna, da jo lahko na hitro razume vsak član ekipe. Primer: update login validation
• Izbirno besedilo: Za bolj zapletene rešitve v zapis vključimo še bolj podrobne spremembe. Te sledijo vrstici, ki vsebuje tip, obseg in opis, ločimo pa jo z prazno linijo. For more complex changes, a more detailed description can be provided in the body. Primer: Added two-factor authentication to improve security.
• Izbirno besedilo v nogi: V ta del vpišemo kakršnekoli “metapodatke” o commitu, ki smo ga dodali. Najpogosteje gre za reference na zahtevke ali zapiske o spremembah. Tudi ta del je ločen od glavnega besedila (oz. opisa, če besedilo ni uporabljeno) s prazno linijo. Primer: BREAKING CHANGE: alters config file

Ko vse to združimo, enostavno commit sporočilo izgleda nekako tako: fix(UI): correct button alignment

Bolj zapleteno sporočilo pa tako: feat(auth): introduce two-factor authentication

Added two-factor authentication to enhance security measures.

BREAKING CHANGE: Users will need to reauthenticate on all devices.

Z razumevanjem teh posameznih komponent smo opremljeni z zmožnostjo tako branja kot zapisonovanja učinkovitih conventional commit sporočil, kar nam pomaga pri tem, da je postopek razvijanja bolj transparenten in vključujoč za vse vpletene.

Zakaj sploh uporabljamo Conventional Commits?

Glavna prednost uporabe smernic Conventional Commit pri Mediusu je vidnost sprememb. Ko se koda povečuje in vanjo prispeva več različnih razvijaclev, postanejo razlaganje sprememb in razlogi za spremembami v kodi velik izziv. Smernice Conventional Commit pa nam služijo kot svetilnik v potencialnem kaosu, saj nam ponuja jasne razlage, ki nas peljejo čez spremembe.

Z usklajenostjo naših načinov dela na podlagi teh pravil smo ustvarili smernice, ki jih lahko bere vsak, tako izkušeni razvijalci kot novi člani ekipe in tudi naše stranke. Ta standardizirani pristop odpravi ugibanja, pospeši vodenje projekta in, kar je najpomembneje, nam omogoča, da svojo energijo usmerimo v to, v čemer smo najboljši - v izdelavo izjemnih programskih rešitev po meri.

Enostavno ustvarjanje različic

Semantično ustvarjanje različic je še en temelj sodobnega razvoja programske opreme. Vsaka različica programske opreme je označena s tremi številkami, na primer 2.4.1. Smernice Conventional Commits se lepo ujemajo s tem sistemom:

• Tip popravek je povezan z zadnjo številko, znano kot različica popravka. Popravek napake to številko poveča.
• Tip feat vpliva na srednjo številko ali minorno verzijo. Nove funkcionalnosti, ki ne porušijo obstoječe funkcionalnosti, bodo povzročile povečanje te številke.
• Bistvena sprememba, označena s klicajem, vpliva na prvo številko ali glavno različico.

Ta brezhibna integracija poenostavi postopek ustvarjanja različic ter ga naredi bolj predvidljivega in razumljivega za razvijalce in vzdrževalce projektov.

Vidik naročnika: Vpogled v ozadje

Čeprav so Conventional Commits nedvomno pomembno orodje za razvojne ekipe, ponujajo tudi nekaj, kar je enako pomembno za naše stranke: preglednost. Gre za samodejno ustvarjen seznam sprememb - podroben zapis sprememb od ene različice do druge. Ta seznam sprememb strankam omogoča enostaven povzetek, tako da natančno vedo, kaj so dobili v vsaki novi verziji. To je koristno tudi za končne uporabnike, saj imajo občutek, da so bolj na tekočem, zlasti pri aplikacijah in spletnih storitvah v zvezi s financami, zavarovanjem ali tistih, ki uporabljajo kakršne koli osebne podatke.

Spremembe pri Mediusu: Pred in po Conventional Commits

Naš pristop k ravnanju s kodo je bil, preden smo začeli uporabljati Conventional Commits, na kratko povedano, razdrobljen. Vsak razvijalec je imel svoj način dokumentiranja sprememb, kar je privedlo do številnih različnih formatov in nivojev podrobnosti. Nekatera sporočila so bila opisna in podrobna, druga pa bolj zapletena ali preveč poenostavljena. Zaradi te nedoslednosti je bilo težko prebirati zgodovino sprememb in hitro razumeti, za kaj je šlo pri posamezni spremembi.

Sprejetje smernic Conventional Commitsl je v podjetju Medius prineslo novo obdobje jasnosti in učinkovitosti. Po predstavitvi te ideje so naši vzdrževalci projektov prevzeli vodilno vlogo pri izvajanju smernic. Takojšnji učinek je bil opazen: sporočila o spremembah so postala bolj poenotena, zato jih je bilo lažje brati in razumeti. Vendar pa so bile koristi še večje kot le berljivost.

Ena najpomembnejših sprememb je bila izboljšana možnost neposrednega povezovanja sprememb z nalogami in opravili. S tem je postal naš razvojni delovni proces bolj sledljiv, kar omogoča boljše sledenje in večjo stopnjo odgovornosti. Sprejetje te prakse pomeni več kot le standardizacijo naših sporočil o spremembah, temveč tudi spodbujanje kulture pozornosti do podrobnosti. Danes lahko na našo zgodovino oddanih sporočil gledamo kot na dobro organiziran arhiv, v katerem ima vsak vnos jasen namen in prispeva k celotni zgodbi o razvoju projekta.

Nismo edini, ki priznavamo moč teh smernic. Ta postaja najboljša praksa v celotni industriji, k čemur nas je spodbudila njena razširjenost v večjih odprtokodnih projektih. V podjetju Medius se zavzemamo za njeno vsesplošno sprejetje, saj menimo, da bi njena jasnost in struktura morali biti splošna prednost v naboru orodij vsake razvojne ekipe.

In potrebovali smo le en “Pizza Day”!

Pot do uvedbe Conventional Commits v podjetju Medius ni bila samo strateška, ampak je bila tudi zabavna. Spremembo smo uvedli ob enem izmed naših priljubljenih pica dnevov. Če tega izraza še ne poznate, je pica dan (Pizza Day) namenjen druženju, izmenjavi znanja in seveda uživanju ob pici. V neformalnem in sproščenem vzdušju se lažje pogovarjamo o novih zamislih, izmenjujemo mnenja in celo rešujemo nekatere bolj zapletene probleme, s katerimi se srečujemo pri naših projektih.

Tako je na enem od teh dni spregovorilo nekaj članov ekipe, ki so eksperimentirali s Conventional Commits. Zamisel je bila predstavljena ne le kot niz smernic, temveč kot odgovor na vse večjo kompleksnost in raznolikost naše kode. Pogovarjali smo se o morebitnih prednostih, o tem, kako bi to poenostavilo naš razvojni proces, in predvsem o tem, kako enostavno bi bilo to uvesti.

Odziv je bil pozitiven in vzdrževalci projektov so se odločili, da začnejo te smernice uporabljati na svojih projektih. Tranzicija je bila tekoča, tudi zaradi sproščenega okolja, v katerem je bila zamisel predstavljena in obravnavana. Pica dan je omogočal odprte pogovore, takojšnje povratne informacije in hitro reševanje morebitnih pomislekov.

Lekcija je: Nikoli se ne nehajmo učiti

Večina naših razvijalcev je v svojem delovnem procesu že sprejela in uvedla Conventional Commits. Smo na zadnji stopnji zagotavljanja, da bodo smernice postale standard vseh naših projektov. Še posebej pa smo ponosni, da se je ta val sprememb začel ob odprtem dialogu in nekaj kosih pice!

V podjetju Medius vedno znova iščemo prakse, ki lahko izboljšajo naš pristop k razvoju programske opreme. Uvedba uporabe Conventional Commits ni bila le sprememba, temveč nadgradnja - preobrazba, zaradi katere so naši procesi bolj poenostavljeni, naša komunikacija pa bolj pregledna.