U prvom dijelu ovog teksta smo vam donijeli 25 savjeta kako postati bolji programer, a u ovom donosimo ostatak vrijednih savjeta. Također, ako niste pročitali tekst o tome kojih 10 programskih jezika naučiti u 2019. godini, svakako vam savjetujemo da i to pročitate. No, pogledajmo koji su to savjeti koji će vas učiniti boljim programerom.
ČITLJIVOST KODA I ODRŽAVANJE
26. Korištenje interface-a često povećava mogućnost testiranja koda i njegovo ponovno korištenje (engl. reusability). Pogotovo u OOP svijetu. Uvijek koristite kompoziciju i interface-e.
27. Nemojte samo naučiti design patterne i koristiti ih samo da ih koristite. Kao da imate čekić i uokolo tražite čavle. Ako nemate jasan razlog za korištenje istoga, nemojte ga koristiti.
28. Uvijek preferirajte “plitku” hijerarhiju nego “duboku” (deep-nested). Duboki kod, odnosno deep-nested kod, je teže za održavati, lakše se potkradu greške, teže ga je ponovno koristiti … Koristite jasnu strukturu i arhitekturu i držite se nje.
29. “Reusable” code je važan i pomaže kod programiranja, ali ako sve pokušate napisati da bude fleksibilno i generički, gubite vrijeme bez veze. Takvu vrstu koda je često teško održavati, mijenjati i nastaju bugovi. Ponekad je sasvim u redu napisati specifičan kod koji radi samo jedan zadatak. Pa čak je i u redu hardkodirati nešto što se neće mijenjati.
30. Dok razvijate aplikaciju, koristite “print” naredbu. Stalno i uvijek. Mnogo je scenarija gdje vam neće pomoći ni sofisticirani debuggeri, ali još nismo nikada bili u situaciji niti smo koristili platformu/okruženje gdje nismo mogli ispisati podatke na ekran ili u datoteku. Svladajte umijeće debuggiranja s print naredbom dok se učite programirati, ali i kasnije kada imate iskustva.
31. Iako se čini da možda ovo nema veze s programiranjem, naučite bolje komunicirati. I pismeno i usmeno. Točno se vidi da dobri programeri znaju dobro opisati problem kojeg imaju i kako ga planiraju riješiti. Ako ne znate dobro komunicirati, nećete ni znati tražiti pomoć. Kao što je rekao Joel Spolsky (suosnivač Stack Overflowa): “The difference between a tolerable programmer and a great programmer is not how many programming languages they know, and it’s not whether they prefer Python or Java. It’s whether they can communicate their ideas. By persuading other people, they get leverage. By writing clear comments and technical specs, they let other programmers understand their code, which means other programmers can use and work with their code instead of rewriting it. Absent this, their code is worthless.”
32. Kao što je slučaj i s “normalnim” jezicima, nećete svladati u potpunosti programski jezik dok ne počnete razmišljati u tom jeziku i dok vam on ne postane “prirodan”. Popularna knjiga “Structure and Interpretation of Computer Programs” (Abelson, Sussman), je jedna od onih koja vam može pomoći u tome. Ne brinite se što su primjeri u knjizi napisani u programskom jeziku Scheme. To je optimalni jezik da naučite razmišljati o kodu i u kodu.
TEHNIČKI DUG, TESTIRANJE KODA I PROCESI
33. Donald Knuth, čovjek koji je napisao “programersku bibliju” – “The Art of Computer Programming” – je rekao: “Kada se dvoumite što napraviti, napravite brute force rješenje. Pokušati optimizirati nešto prerano je uzrok svog zla.”. Kada kaže “brute force” onda misli da napravite nešto da radi, smislite svoj algoritam da dobijete željeno ponašanje. A nakon toga krenite optimizirati dio po dio kako biste dobili bolji algoritam i bolju čitljivost. To je jedini način da naučite programirati i da razumijete kod koji ste napisali.
34. Tehnički dug je nešto s čime se susreće svaki programer. Naučite kada radite taj isti “tehnički dug” i kada ga “otplatiti” da se ne nakupi tijekom projekta. Nije problem u fazi razvoja napraviti nešto “poprijeko” kako biste napravili određenu funkcionalnost, ali kada projekt postane stabilan, učinite sve da počistite taj nered iza sebe i riješite se duga. Nakon toga prijeđite na sljedeću fazu projekta.
35. U kontekstu projekta, naučite koliko je testova dovoljno. Premalo testova ne znači ništa jer ne pokrivaju dovoljno projekt. Previše testova uzima previše resursa i vremena, te ćete se samo baviti testovima, a ne razvojem. Pišite testove, ali kada ih imate dovoljno – stanite. Radije se fokusirajte na kvalitetu testova, nego na kvantitetu. Pisanje testova usporava i proces razvoja, pa uzmite i to u obzir.
36. Predviđanje vremena za određeni task je teško. Zato su metodologije poput Scruma toliko popularne. Neka vam sprintevi budu maksimalno 2 tjedna dugački i tjerajte se do krajnjih granica u tom periodu. Manji periodi razvoja smanjuju rizik kod razvoja softvera, umjesto da ga povećaju. Klijent će konstantno dobivati nove verzije aplikacije i na vrijeme će moći reći da mu se nešto ne sviđa, da ima bugova i slično. Zaboravite na “waterfall” način razvoja.
37. Commit-ajte kod u malim “chunkovima” i pišite detaljne poruke prilikom istoga. To će pomoći drugim developerima da shvate što ste radili i gdje ste možda napravili bug u razvoju. Samo napišite kratki opis onoga što ste radili i zašto ste to radili. Nemojte commitati 50+ datoteka i samo napisati “bug fixes” ili nešto slično, što većina programera radi.
38. Mnogi programeri ne razmišljaju o sigurnosti kada pišu o kodu. Mnogi misle da će framework taj dio odraditi za njih. Ne budite kao “većina programera”.
39. Devedeset posto bugova ćete uloviti tijekom razvoja i najčešće ih vidite odmah čim isprobate ono što ste napravili. No, postoje slučajevi kada ćete onaj jedan ili dva buga loviti jako dugo i ponekad nisu vrijedni vremena. Ako radite u domeni gdje softver ne mora raditi 99.999 posto točno, ne brinite se stalno o “edge casevima” kad se ionako neće dogoditi ili će se dogoditi jako rijetko. Kad završite razvoj softvera i kada budete imali vremena, pozabavite se tim slučajevima.
“SOFT” VJEŠTINE I PRODUKTIVNOST
40. Veliki dio vremena tijekom radnog dana odvojite za programiranje i budite fokusirani na ono što radite. Ne želite da vam produktivno vrijeme ljudi kvare sa sastancima, email porukama, slack porukama i slično. Ugasite ono što vam trenutačno ne treba i posvetite se onome što morate napraviti. Ostalo može čekati.
41. Jasno komunicirajte s ostatkom tima što radite taj dan. Pričajte s njima o arhitekturi koju radite, o problemima s kojima se susrećete. Možda će netko od tima imati sličan problem ili je riješio isti pa će vam dati dobar savjet u kojem smjeru ići. Nema smisla se “praviti pametan” i raditi po svome kad možda nećete biti u pravu. U redu je priznati da ste trenutačno “zapeli” i da vam treba pomoć. Programiranje nije “one-man band” nego skupno rješavanje problema u određenoj domeni. Poželjno je i imati interni wiki za česte probleme s kojima se programeri susreću.
42. Nastavak na prošlu točku. Neka vas ne bude sram reći da nešto ne znate ili da ste zapeli. Mnogi problemi s kojima se programeri susreću su specifični, a opet, možda ih je netko već riješio. Nedostatak znanja nadomjestite svakodnevnim učenjem pa ćete i vi moći jednog dana pomoći onima s manje iskustva i znanja.
43. Nemojte se sramiti podijeliti nedovršen posao s kolegama. Bolje im je pokazati dio koda, nego cijeli jer ste možda u procesu pogriješili, pa će vam dati savjet kako da poboljšate kod kojeg trenutačno pišete.
44. Emocionalno se odmaknite od svog koda. Nađite kod na koji ste ponosni, te ga potom obrišite i ponovno napišite. Ovog puta na neki drugi način. Iskoristite “design patterne” koji vas možda zbunjuju. Naučite ih primijeniti i zašto rade kako rade. Ako je potrebno, ponovno obrišite napisano, te napišite isti kod u drugom jeziku, tehnologiji, frameworku. Vježbajte analitičke vještine tako. Ključno je da napisani kod ne smatrate nečim što je “uklesano u kamen” i više se ne može mijenjati kada ispravno radi. Može se, a svaki puta kada ga budete pisali, bit će bolji i bolji. Ako pogledate svoj stari kod i mislite da je dobar, to znači da niste dovoljno napredovali.
45. Googlanje je krucijalna stvar kod svakog developera. Zašto izmišljati “toplu vodu” ako je to već netko riješio prije vas. Pogledajte kako su drugi programeri nešto riješili, naučite nešto iz toga i primijenite naučeno. Uštedjet ćete sebi (i klijentu) mnogo vremena, a kasnije to isto vrijeme možete iskoristiti za nešto drugo.
46. Dobar programer zna kako napisati kod, odličan programer zna kako ga prepisati i ponovno iskoristiti kad mu zatreba.
47. Učite druge. Čak i ako niste expert u programiranju. Imate određeno znanje koje možete prenijeti na druge. Učenjem postajete bolji jer morate razumjeti ono što drugima prenosite. Samim time ćete postati i vrjedniji šefu u kompaniji jer podižete cijeli tim na novu razinu.
48. Nemojte se fokusirati da postanete “10x” programer. Pročitajte ovaj članak od Matt Asaya i Scott Hanselmana da vidite zašto.
49. Nećete i ne možete biti bolji programer kroz samo programiranje. Možete vi tehnički biti dobri koliko god želite, ali krucijalno je da naučite što korisnici žele i da naučite što više možete o korisnicima vašeg softvera. Naučite o domeni i industriji u kojoj se nalazite. Naučite nešto i o biznisu. Što više stvari znate i što vas više stvari zanima, to vaš rad postaje bolji i imate bolje ideje kako nešto isporučiti korisnicima i zašto im baš to treba.
50. Napravite greške, pitajte pitanja, nađite odgovor, izađite iz “zone komfora”. To je jedini način da svaki dan širite znanje i postajete sve bolji i bolji.
Piše: B.P.
