Ovo pitanje se tiče prvenstveno mindseta odnosno načinu razmišljanja developera gde se prilikom faze izrade planiraju prateće aktivnosti i prakse koje će timu omogućiti optimalan tempo razvoja.
Optimalno nije uvek najbrže, nego se više bazira na celokupnom procesu izrade, gde će se na najbolji mogući način izraditi scalable aplikacija koja će odgovarati krajnjem korisniku.
Pisanje održivog koda dolazi sa iskustvom i velike su prednosti ako u timu postoje iskusnije kolege (seniori) koji će preneti svoje znanje na juniore i na najbrži način adaptirati kod.
Čist i održiv kod developerima je jako važan, jer u svakom momentu mogu pronaći gde se šta nalazi i čemu služi, pogotovu ako se posle dužeg vremena vrate na doradu nekog modula aplikacije ili debagovanje koda.
Dakle, zašto pisati održiv kod je pitanje koje zahteva širok odgovor, ali glavno zato na ovo pitanje je da se kompleksni softverski kod može lako menjati, održavati, debagovati, implementirati i na kraju, testirati.
Pisanje održivog koda možemo podeliti u segmente, korake ili principe koji su opšte prihvaćeni u globalnoj dev zajednici, a nekoliko najbitnijih principa su:
DRY ili don’t repeat yourself...
Ovo je najvažniji princip kodiranja koji bi trebalo što pre primenjivati prilikom pisanja koda. Za početnike je malo izazovno (al’ samo malo ne boj se), da odmah primene ovaj princip u kodiranju, ali kako vreme uloženo u učenje prolazi, sve će leći na svoje mesto. Lakše je održavati kod kad je smešten na jednom mestu, jer ako se kod duplira na više mesta, velika je verovatnoća da ćeš zaboraviti u nekoj kopiji da ga ispraviš, pa će greška i dalje postojati. Zamisli da imaš na 10 mesta iskopiran kod, a u međuvremenu otkriješ bag, pa na svih 10 mesta moraš da ’’peglaš’’ kod da otkloniš grešku. Zato je DRY glavni princip koji treba usvojiti što je pre moguće.
Dokumentacija - komentarisanje...
Uvek komentariši odnosno dokumentuj kod kako bi ostali developeri u timu znali šta određeni snippet koda (funkcija ili metoda) radi i čemu služi. Ovde bih dodao da ne ispisujes eseje i da prepričavaš timu sagu o svom kodu. Kratko (koliko je to moguće), jasno i precizno šta se dešava i to je to :).
Dodela opisnih imena funkcijama i varijablama...
Za mnoge developere možda i teži korak od programiranja, gde neki put može oduzeti više vremena u osmišljavanju preciznog imena funkcije ili varijable.
Neki znaju da definišu besmisleno ime za varijablu ( na primer int x = 5; ), a program će naravno raditi bez problema, ali zato kad sedneš za njegov kod da debaguješ ili izmeniš nešto, neće ti biti jasno šta je taj x.
Dakle, ne koristi skraćenice ili ih limitiraj na minimum. Ovo je samo primer šta može da se desi, ali većina developera izbegava ovaj vid imenovanja.
Pojednostavi kod ukoliko je to moguće...
Ovde mislim da ćeš napisati funkcionalnost neke celine u aplikaciji i to će fino raditi, ali pokušaj da pojednostaviš kod, kako bi manje linija bilo ispisano. Ovo naravno, ne znači po svaku cenu da smanjiš na minimum, jer u mnogim situacijama možeš da zakomplikuješ čitanje koda, pa drugom developeru neće biti jasno šta se tu dešava. Ovo će isto doći sa iskustvom i pisanje koda zavisiće od celokupnog iskustva tima.
Uvlačenje (identation)...
U nekim programskim jezicima identacija nije neophodna, ali ovo uvek i u svim jezicima moraš da koristiš jer znatno utiče na čitljivost koda. U pythonu recimo, identation je mandatory i ne može kod da radi bez toga, dok na primer u Javi možeš da poravnaš sve u jednoj vertikalnoj liniji i da se kolega čupa za kosu kad bude čitao tvoj kod. Mada ovde rizikuješ i da ti miš ili tastatura završe u nosu, pa izbegavaj ovakvo pisanje.
Redovno testiraj kod...
Zašto je ovo važno? Zato što je svaki programer došao u situaciju da na većim i dugoročnim projektima, dok ispravlja bagove ili dodaje nove funkcionalnosti, se pita gde li mu se taj kod koji treba ispraviti nalazi, da li je ova funkcija i dalje potrebna, šta ovo znači, čemu ovo služi i slično... Izgube se sati u pokušaju da se lociraju traženi segmenti koda, pogotovu ako dokumentacija ne postoji, a na suštinsko pitanje: ’’Kako mogu da budem siguran da ako ovo promenim, ništa drugo neće se pokvariti?’’, odgovor ćeš dobiti kroz test, koji je maintainable napisan, koji će proveriti da li si nešto brejknuo ili ne. Razmišljaćeš o kodu pre nego što počneš da ga pišeš, i testiranje je iz tog razloga (između ostalog), jako važna stavka.
Ako se kod automatski testira po celinama (unit), znatno će se povećati produktivnost na duže staze, jer će smanjiti sate u debagovanju, a što je važnije, smanjiće frustracije kod developera.
Prati konvenciju...
Ovo spada u istu grupu sa identation i documentation gde koristiš dosledan stil pisanja koda. U svakom timu postoji zajednički standard za jezik i moraš se prilagoditi takvom načinu rada, kako bi svima bilo jasno šta se u kodu dešava.
Praćenje jezičke sintakse i načina pisanja je uvek dobra ideja, jer će to pomoći novom kolegi koji se pridruži u tim.
Ovo bi bile neke početne smernice za pisanje održivog koda, iako ih ima još, svaki tim ima neke svoje ideje, navike i standarde kad se izrađuje aplikacija. U svakom slučaju, ako si nov u timu, vreme za prilagođavanje ti ne gine, ali ove smernice su generalno primenjive u većini timova.
2 komentara