Siniša Nimčević

Odmah na početku moram da kažem, ja moj odnos prema kodu izražavam u prozi, a i u poeziji. Prvo ću da vam ponudim prozu, a u zaključku sledi poezija. Dakle… Ako ste se zainteresovali za pisanje boljeg koda - čestitam. Ušli ste u možda top 20% svoje branše, budući da se većina programera trudi da napiše kod koji pod a) radi, i koji se pod b) sviđa njima. Poseban sprat u Danteovom čistilištu ide za ekipu čiji kod je pod c) “pametan” i zauzima minimalan broj linija. Ništa od ovoga nije bitno za čist kod, da se odmah razumemo, sem da kod naravno, pod a) radi, ali to možemo podrazumevati bez posebnih napomena.   Bez sumnje, odlučili ste da se uozbiljite i rekli ste sebi, “kako sam učio kad sam bio u školi”? Odgovor je naravno - putem knjiga i beleški. Dobro, sada korak dalje, izguglali ste koje su to knjige koje sOfTvErSki InŽeNjEr mora da pročita (jer kad se već cimate toliko oko svog koda postajete inženjer, a ne običan smrtnik programer). Stižemo do monumentalnog dela Roberta C. Martina “Čist kod”.   E sada, čist kod možemo shvatiti kao gomilu pravila koja se bave pisanjem koda koji je, čitak, lak za održavanje i izmenu i lak za testiranje (popularno nazivan “robustan”). Takođe ga možemo definisati i kao gomilu pravila koje stariji programeri koriste kao izgovor da peglaju pisanje mlađih programera koji su neretko bolji od njih, ali red se mora znati - čekaj mali, pa ne možeš tako - vidi na šta ti ovo liči. Ja ću pokušati da vam dam (taličan broj) 7 saveta za pisanje čistijeg koda, podrazumevajući da ste već pročitali samu knjigu i gomilu sažetaka koje programeri-piskarala poput mene izbacuju na nedeljnom nivou. Pa da uđemo u meso konačno:   Higijena je pola zdravlja. Udarite nekad enter. Ovo je čisto vizuelna primedba. Mnogo više vremena provodimo čitajući nego pišući kod, a enter prosečne logitech tastature podnosi oko 50 miliona udaraca. Pomozite bratu/sestri kolezi i vodite računa o vertikalnom ritmu. Dakle koristimo samo jedan enter, on odvaja logičke celine koda i (između ostalog) naglašava početak i kraj neke petlje. Razmišljajte o tome. Uvlake da ni ne spominjem, 4 spejsa / 2 taba, odlučite se kao ekipa i držite se toga.  Budite jasni kada komunicirate. Ne skraćujte imena funkcija i varijabli bez potrebe. Vraćam se na onih 50 miliona udaraca koje tipka trpi - zažmuriću ako umesto temporary napišeš tmp, pa čak i number može da bude num, ali koliko je kod lepši ako može jednostavno da se čita. Ti kada čitaš i interpretiraš skraćenicu, KOLIKO GOD ona bila česta, ti zaumuckuješ u procesu. Ukoliko misliš da je ime funkcije odnosno varijable predugačko, ili pokušavaš previše da uradiš na jednom mestu, ili se nisi dobro izrazio.  Manje je nekad više. Malo konkretnije kad smo već kod funkcija - preferirajte funkcije koje imaju MANJE argumenata. Kako god se okrene, ukoliko funkcija treba da primi mnoštvo argumenata, verovatno pokušava previše da uradi. Možda čak prima i neku “boolean” vrednost pa se koristi na više mesta, A TA BOOLEAN VREDNOST deli funkciju na tipa 2 dela, gde se jedan deo uopšte ne izvršava (buraz onda napiši drugu funkciju za taj drugi deo logike).  Priznaj da možeš pogrešiti. Pozabavi se greškama. U zavisnosti od dela arihtekture i jezika kojim se piše, stvari su drugačije, ali na kraju dana - moramo se ograditi od savršenog funkcionisanja aplikacije. Nekad nešto neće biti u bazi, nekad će promene u strukturi podataka vratiti neočekivani rezultat - tvoj kod mora biti DOVOLJNO ČIST da pravilno obradi greške, a ostane čitljiv.  Preispitaj svoje tvrdnje pre nego što ih postaviš kao činjenice. Oslonite kod na automatizovane testove. Neki bi možda rekli da pisanje testova nema toliko veze sa osnovnim kodom, ali neki ljudi stavljaju i ananas na picu. Poenta je da kod koji treba da bude testiran, teži da bude iscepkan u jasne celine, jer je baš takav kod lak za testiranje (a pisanje testova ne bi nikad trebalo da oduzima suviše vremena)  Suzdržite se suvišnih komentara. Ali stvarno. Ukoliko vaš kod zahteva komentar da bi bio jasan verovatno može biti bolje napisan. Umesto magičnih brojeva ubacite deskriptivnu konstantu, možda zalepite konstantu na neku isto tako deskriptivnu enumeraciju, preimenujte funkciju i - rešite se suvišnih komentara.  Znajte kad da prekršite pravila. Naravno, svaki programer u usponu će se prvo uhvatiti DRY i KISS pravila jer su po 3(4) slova, i lako se pamte i onda ispadneš pametan jer se “pozivaš na neki princip” da opravdaš svoj loš kod. Moj odgovor je, “copy/paste je iz raja izašao”. Tu sad ne propagiram regresiju u kameno doba i lenjost, ali želim da poentiram sa nečime što ne čujem dovoljno često. Nakon što se upoznaš sa pravilima, tek onda dobijaš “pravo” da ih kršiš. Čitljivost je ključna osobina koda, i principi iznešeni u teoriji čistog koda su definitivno dobra prilika da “stojimo na ramenima džinova” istorije kodiranja, ali takođe moramo shvatiti da postoji mnogo faktora iza softverskog projekta. Da se izrazim slikovito - neke bitke jednostavno ne vredi povesti, i neke stvari jednostavno ne možemo predvideti.  Da sumiram i sipnem onu poeziju koju sam obećao s početka. Baš ovaj poslednji savet je nešto što mi je možda najlepše kod programiranja. Većina programera piše kod koji se u nekom trenutku kompajlira i prevodi u mašinski jezik. Postoji mnogo praktičnih razloga zašto je tako, ali zastanimo na trenutak sa tom informacijom. Dakle ja pišem, da bi (budući ja) i neko drugi taj kod čitao. A ljudi kao ljudi, vole igre, vole zanimljivosti, vole da se izraze kao individue. Baš ta sitna odstupanja od pravila, kombinovana sa veštom ličnom interpretacijom principa nam daju taj prostor koji ja zovem “coyote time”.    Izraz “coyote time” dolazi iz industrije igara. Naime, developeri su shvatili da postoji poseban elemenat zabave kada naš Super Mario tip karaktera pretrči preko ivice (kao kojot u crtanom filmu) i trči po vazduhu. To dozvoljava da se odraz koji nije savršeno tempiran (i vrši se od “vazduha”, a ne od čvrstog tla), završi kao uspešan skok preko ogromne litice. Taj momenat nategnutosti pravila kreira uzbuđenje i popravlja iskustvo igre jer ne platimo za svaku malu grešku, već idemo dalje i iskustvo igre se nastavlja neometano.  Ovo se prenosi na programiranje gde imamo poseban momenat zadovoljstva - dobro poznajemo pravila, vešto “plešemo” unutar njih i povremeno iskoristimo naš “coyote time” ne bismo li nastavili razvoj neometano, preskočili preuranjenu optimizaciju i zapravo stigli do trenutka gde je naš najveći izazov. Odatle možemo sa mnogo “visočije” pozicije da sagledamo problem i pišemo optimizacije i testove u “pravom trenutku”.  I, konačno, da povežem ovo sa čistim kodom - pisanje čistog koda je sprovođenje teorije u praksu. Da bismo se izveštili u ovome moramo to da radimo dugo, a opet, da bismo radili nešto dugo, moramo barem malo da uživamo u tome. Uđite duboko u literaturu, rezonujte sa sobom ili drugim kolegama o svom kodu. Izolujte procese koji vas zamaraju, koji su suvišni - probajte da ih srušite i izgradite ponovo na nekom drugom principu ili na izuzetku koji ima smisla. Igrajte se i naučite da uživate u pisanju ČISTIJEG (pošto savršeno čist ne postoji) koda. 

Svaki programer koji je zahvaćen “agilnim” načinom rada, a i svim njegovim derivatima koje srećemo u divljini, sigurno prisustvuje redovnim dnevnim sastancima. Takozvani “dejli” je uglavnom smešten negde u pre podne, i u zavisnosti od veštine “scrum mastera” ili neke odgovorne figure, ume različito da traje. (više)

 Šta je tehnički dug?  Tehnički dug je koncept u razvoju softvera koji obuhvata “dodatan” napor potreban za održavanja baze koda. Potreba za tim dodatnim naporom se javlja usled korištenja raznih “prečica” u razvijanju aplikacija koje možda zaobilaze “best-practice” pristupe i industrijske standarde, ali u tom trenutku daju brze rezultate. Dakle govorimo o neefikasnim rešenjima koja nisu pokrivena testovima i zahtevaju vrlo specifično okruženje da bi sve radilo kako smo zamislili.  (više)

Svaki mladi developer sanja o, sada već mitološkom scenariju gde radi/raducka za hiljadu evra mesečno. Odnosno, otkad je počela ova inflacija, verovatno je to sad dve hiljade evra. Međutim, isti taj mladi developer se dobro zapita o isplativosti kada vidi da neki kurs košta 100 dolara. Uf, da li mi se isplati toliko dati za kurs?   (više)

U karijeri svakog programera dođe trenutak (uglavnom je to ponedeljak ujutru), kada poželi da menja posao. Sa godinama to postane želja za menjanjem karijere, ali o programerima koji sanjaju o gazdinstvu, a nisu prekopali metar bašte, nekom drugom prilikom.  (više)

Mnogi programeri na početku karijere ne vole programiranje. Moram da primetim i da istaknem razliku između - “napisao sam nešto što radi (da dobijem platu na kraju meseca)” i “napisao sam dobar kod”. I ne samo na početku karijere, to ljude ume da prati i mnogo duže. Tu počinjem od sebe. Zamislite majstora koji pravi satove, i kada mu neko kaže da napravi još jedan sat, on se isfrustrira. Kada mu neko kaže da hoće baš ovakav ili baš onakav sat, on nađe izgovor zašto takvi kaiševi ili takve skazaljke nisu višu u modi. To su programeri ukratko.  (više)

Kada govorimo o spajanju komponenata neke aplikacije, dotičemo se vrlo rudimentarnog dela softverske arhitekture. Možda su negde gore "oblaci", redirekcije i redis keševi, ali u dnu svega je izvorni kod koji mi gledamo tokom održavanja i nadogradnje sistema. (više)

Ciklomatska kompleksnost je termin skovan od strane Thomas J. McCabe-a davne 1976. (u Fortran okruženju), da bi se opisao proces merenja “lakoće testiranja i održavanja” kontrolnog toka nekog modula. Njegov pristup je primena matematičkih modela kojima otkrivamo koliko je testova potrebno da se u potpunosti “pokrije” neki metod.  (više)

Tri najčešće primenjena formata rada za programere su freelance rad, klasičan rad u firmi i remote rad. U današnje vreme, sa pojavom co-working prostora u većim gradovima, a i sa dolaskom plandemije, sva 3 vida su dobila svoje hibridne verzije, ali ću ja pokušati da se držim standardnih definicija i pri svemu budem što objektivniji. Šta su dominantni vidovi rada, i koji je za vas najbolji? (više)