Antipaterni — Loše prakse kojima kočimo softverske projekte

Pored toga što je dobro znati koji su dobri načini za pisanje softvera, odlično je biti svestan i praksi koje bi trebalo izbegavati.

Aleksa Vidović
06/04/2017
antipaterni

Grupa autora sa velikim iskustvom u izradi softvera pokušala je da kroz svoju knjigu Antipaterni (1998) definiše terminologiju vezanu za sve one loše stvari koje se često sreću u  softverskim projektima, a krivica su samih programera i njihovih menadžera. Ideja o antipaternima je postala donekle popularna i mnogi developeri su doprineli obogaćivanju kataloga antipaterna na osnovu svojih iskustava.

Antipaterni stoje nasuprot dizajn paterna i služe da nas podsete na loše navike kojima smo skolni u svom svakodnevnom radu. Najbolje se uči iz grešaka, a antipaterni definišu upravo to — pogrešne prakse u razvoju softvera.

Neki od njih se odnose na sam kod, a neki na upravljanje softverskim projektima.

Pasta kod

Lepo je bolje od ružnog.

Jednostavno je bolje od složenog.

Složeno je bolje od komplikovanog.

— Tim Peters, The Zen of Python

Ko ne voli italijansku kuhinju? Špagete i lazanje su super — sve dok se ne nađu u vašem kodu.

Špageti kod je izraz koji se koristi za kod koji je na neki način zamršen, a prva asocijacija na njega je zloglasna “goto” naredba. Izraz je nastao davno, još pre nastanka objektno orijentisanog programiranja i odnosio se na program čiji je tok nemoguće ispratiti bez čupanja kose.

Ravioli kod se odnosi na programe čija je struktura rasparčana u gomilu sitnih delova od kojih svaki ima minimalna zaduženja.  Hiljade malih klasa koje čine pronalaženje ključnih delova koda koji zaista rade nešto nemogućim.

Lazanje je termin koji koristimo za aplikaciju sa prevelikim brojem slojeva. Nepotrebni slojevi apstrakcije koji komplikuju stvari i čine praćenje toka programa komplikovanim, nepotrebno dodajući redundantnu funkcionalost aplikaciji sa svakim novim slojem.

Kopi-pejst programiranje

Kopirali smo kod sa Stack Overflow-a u main branch. Ono što se zatim dogodilo ostavilo je sve bez daha!

U redu je ne razumeti šta radi baš svaka linija koda u projektu. Ipak, nešto što bi se moglo nazvati smrtnim grehom programiranja jeste kopiranje tuđeg koda bez imalo razmišljanja o tome šta taj kod radi i kakve bi efekte mogao da ima na naš projekat.

Ovo je nažalost česta pojava, pogotovo među studentima koji imaju menadžerski pristu programiranju — “nije važno kako radi, važno je da radi”. Tako njihovi školski projekti postaju gomile kopi-pejstovanog koda sa interneta, a neki ovu naviku zadržavaju i u daljem toku svoje karijere.

Pored toga što može biti opasan po sam projekat, ovakav pristup ne stimuliše vaš razvoj kao developera i njime ne produbljujete svoje razumevanje materije kojom se bavite.

Zlatni čekić

Kada imaš čekić, sve izgleda kao ekser.

Preterano vezivanje za jedan alat — bilo emocionalno ili formalno — dovodi do ovog antipaterna. Odnosi se i na “loženje” na jednu tehnologiju.

Zlatni čekić najčešće se javlja u situacijama kada je razvojni tim koji je vešt u jednoj tehnologiji dobije projekat za koji bi optimalna bila neka druga tehnologija. Umesto da prošire svoje znanje i prilagode se situaciji, developeri odlučuju da se drže onoga što najbolje znaju.

Verujte mi ljudi, node je najjači. Hajde da ga koristimo za sve!

— Svaki junior ikada

Prerana optimizacija

Programeri traće ogromno vreme na razmišljanje i brigu o brzini nevažnih delova svojih programa, a ovi pokušaji efikasnosti u stvari imaju veoma negativne efekte po pitanju debagovanja i održavanja. Trebalo bi da zaboravimo na male optimizacije efikasnosti, recimo nekih 97% vremena: prerana optimizacija je koren sveg zla. Ipak, ne bismo smeli da propustimo tih kritičnih 3%.
— Donald Knuth

Iako MVP vašeg startapa još nije završen, odlučili ste da je pravo vreme za malo optimizacije. Sjajno!

Ubrzali ste svoj softver za 0.0037% i usput ga učini nemogućim za čitanje i održavanje od strane bilo koga drugog u vašem timu.

Bikeshedding

Zamislite grupu inženjera koji projektuju nuklearnu elektranu i troše nekoliko sati dnevno na žučnu raspravu o tome koje će boje biti stalak za bicikle (bike shed). Ovo je metafora kojom je slikovito prikazan Parkinsonov zakon trivijalnosti, ali je prihvaćena i u oblasti softverskog inženjerstva.

Koliko ste samo puta trošili vreme na rapravljanje o nebitnim pitanjima? Odredite prioritete i uštedite svoje vreme i živce.

Ovo je pogotovo primenjivo na startape, ne samo po pitanju softvera već i sa poslovne strane. Ukoliko lako odlutate i počnete da se bavite nevažnim stvarima, pokušajte da razvijete kulturu u kojoj ćete jedni drugima otvoreno skretati pažnju na ovu pojavu, kako biste kao tim ostali fokusirani na ono što je bitno.

Izmišljanje tople vode

Zajedno sa svojim timom krećete u novi poduhvat. Biće to još jedan uspešan projekat. Ovog puta bićete temeljni. Zato odlučujete da za početak sami napišete svoj tekst editor, kompajler, server, operativni sistem i sistem za verzionisanje koda, jer nema tog alata na ovom svetu koji može da zadovolji potrebe bogova programiranja kao što ste vi.

Šalu na stranu, ovaj antipatern se uglavnom pojavljuje u malo blažem obliku i vezan je ili za sujetu, ili za čistu neobaveštenost. Odnosi se na onu situaciju kada umesto jednog jednostavnog npm installa biramo da provedemo dva dana praveći svoj modul za neku funkcionalnost koja je verovatno trivijalna za naš projekat.

Kada umesto pretplate od 4$ mesečno na neki SaaS potrošimo dva meseca i gomilu kompanijskih resursa na pravljenje nečeg što je verovatno daleko inferiornije u odnosu na postojeća rešenja — pritom misleći da smo ispali pametni.

Za iscrpnu listu antipaterna posetite Katalog Antipaterna.

Aleksa Vidović

Objavio/la članak.

četvrtak, 6. April, 2017.

IT Industrija

🔥 Najčitanije

Nemanja

utorak, 18. April, 2017.

Pozdrav, vecina stvari iznetih u clanku jesu antipaterni, medjutim, lazanja kod ne mora nuzno biti antipatern. Postizanje slojevite arhitekture je pozeljno u kontekstu odrzavanja i prosirivosti softvera. Ovde je kljuc da se ne uvode bespotrebne apstrakcije koje uzrokuju povecanu kompleksnost. Dakle, "spagete kod" je uvek "spagete kod" i uvek je los, bilo da imamo 3 ili 300 spageta (naravno, 300 spageta drasticno povecava kompleksnost). "Lazanja kod" sa razumnom kolicinom raslojavanja je pozeljan i poboljsava kvalitet softvera u kontekstu odrzavanja i prosirivosti.