28.12.2021. ·
4 min

Back to basics: kako pisati kvalitetan kod?

Back to basics: kako pisati kvalitetan kod?

Sigurno znaš za ovu situaciju: napišeš kod, sve radi, nakon par meseci treba da se izmeni, čitaš kod, razmišljaš “Koja li je budala ovo pisala?”, pogledaš na Gitu i shvatiš da si sebi upravo dao/dala sjajan kompliment? Ni ja isto 😉

Pa da se vratimo na početak - šta su neka pravila dobrog koda i kako da izbegneš da i ti, a i ljudi koji preuzmu projekat od tebe, lupate glavom o sto, zid ili tastaturu?

Vodi računa o formatiranju, čitljivosti i indentaciji koda. Svaki IDE ima svoju prečicu koja lepo formatira kod, nauči je i koristi je.

Pre svega - bez nepotrebnog ponavljanja, moliću lepo. Ako se deo koda ponavlja, odvoji ga u posebnu metodu i zovi metodu.

Onda - nemoj da ti klase/ fajlovi imaju million linija koda. Odvoji sve lepo u klasice, modulčiće koji su logično povezani, ne mora sve da bude na jednom mestu i mnogo je lakše za čitanje. Ako moraš da skrolaš ko blesav da bi pročitao sav kod, refaktoriši odmah. 100-500 linija po fajlu je ok.

Nazivi promenljivih i metoda treba da budu logični i opisuju čemu promenljiva/metoda služi. Dakle - promenljive tipa variable, a, b, c, x ne treba da postoje u kodu, već da budu imenovane prema onome šta predstavljaju - ako je u pitanju stranica trougla - nazovi je stranicaTrouglaA, ako je u pitanju neto dohodak - nazovi ga netoDohodak. Ne budi lenj/a. Isto važi i za metode - bolje je da metoda/funkcija ima podugačko ime ali da na prvi pogled bude apsolutno jasno šta radi, nego da kratiš ime, a onda muke dok ukapiraš šta radi i zašto.

Koristi smislene module. Olakšaj refaktorizaciju, ali i učenje projekta time što će stvari da budu smisleno podeljene, da se logički povezane stvari nalaze logičnim redosledom.

Vodi računa o potencijalnim NPE. Razmišljanje o ovim stvarima unapred ume itekako da bude korisno kasnije - npr: ako porediš promenljivu sa konstantom, neka konstanta bude sa leve strane. Piši null check-ove, čak i kad pretpostavljaš da nikada neće biti null. Time se ograđuješ od Null Pointer Exceptiona.

Koristi Sonar. Ovo je alat koji te jednostavno tera da pišeš čistiji i kvalitetniji kod, hteo ti to ili ne. On radi statičku analizu koda umesto tebe, i prosto ti stvara dobre navike dok kodiraš.

Pišite komentare u kodu. Ukoliko je funkcija/metoda kompleksna, objasni šta radi i čemu služi. Ako ubacuješ neki “nelogičan” deo, objasni zašto je baš taj deo koda tu. Ukoliko je nešto urađeno prema funkcionalnom zahtevu, dodaj broj zahteva koji može da se pogleda kasnije i shvati zašto je nešto napisano tako kako je napisano. Olakšaj i sebi i drugima život.

Postman kolekcije. Ako praviš API, napravi i Postman kolekciju i sačuvaj primere poziva - tebi je to pet minuta posla, nekome ko radi posle tebe može da skrati puno vremena u istraživanju. Dakle, primer poziva koji je uspešan, par primera sa greškama, neki edge case za svaki slučaj - sve lepo spakuj u primere i sačuvaj kolekciju negde u zvaničnoj dokumentaciji. To takođe može da koristi i tvojim kolegama koji rade frontend. Takođe, Swagger može da bude dobra opcija za dokumentaciju API-ja.

Zvanični dokument projekta. Znam da developeri mrze dokumentaciju, ali novim developerima ovo može mnogo da znači - dokument koji ima u sebi objašnjenu arhitekturu, nabrojane važne stavke, podatke gde se nalazi dodatna dokumentacija (Postman kolekcija npr.), kako se podešava i pokreće projekat, uputstvo za deploy i dodatne stvari bi bilo lepo imati na svakom softverskom projektu. Ne mora da bude previše detaljan dokument, ali je važno imati najbitnije stvari na jednom mestu, pa makar to bio deo readme fajla.

Piši testove. Na ovu temu napisah čitav članak, pa ne bih da se ponavljam. Testovi su jednostavno dobra praksa i dodatna dokumentacija u kodu, i dobro je imati ih.

Pull request review. Iziskuje malo više vremena da kod dođe na konačnu destinaciju, ali dobra je praksa da bar dva para očiju pregleda kod, jer će drugi par možda primetiti nešto što prvi nije. Takođe, na taj način se dodatno forsira čišćenje koda, dobre prakse i izbegavaju se potencijalni bug-ovi.

Ima ovde još puno toga pametnog da se kaže - pa šta su neki tvoji saveti za čist kod i čistu savest?

Oceni tekst

17 osoba je glasalo, prosečna ocena: 5
Jovana Milosavljević Jovana Milosavljević

Sad sam senior developer, a nekada davno sam bila atraktivna plavuša koja se bavi marketingom :). I dalje se tešim da bar nisam oćelavela od čupanja kose od koda :) U slobodno vreme volim da čitam, pijem pivo, osvajam kafane i sanjam da ću kad porastem biti venture capitalist.

2 komentara

Milan Paunovic Milan Paunovic 28.12.2021.
0

U pravu si za sve sto ai napisala, ali.... uvek postoji ali...nemas dovoljno vremena da pises objasnjenja za kod koji je obiman...nemas dobro izrazavanje za pisanje dokumentacije jer se vrlo brzo rasplines...postoji neki ali zbog cega ne mozes da postujes sve prethodno navedeno....SoftDev..

Dejan Dejan 29.12.2021.
1

Kad programer nema vremena da napiše dokumentaciju, to nije programerski već organizacioni problem - nije mu dato dovoljno vremena da uradi sve što je potrebno. Dokumentacija može da se uvrsti u Definition of Done i da se za nju traži vreme, a na scrum masteru ili projektnom menadžeru je da se za to izbori.

Iz ove kategorije

Svi članci sa Bloga