Ako ste tek skočili na ovu stranicu, možda prije svega da pročitate prethodne dijelove i to:

• Softverski obrt/zanatstvo
• Softver zanatlija II
• Softver zanatlija III – Demistifikacija agilnosti
• Softver zanatlija IV – Softverski obrt
• Softver zanatlija V – Stav softverskog obrta
• Softver zanatlija VI – Između hrabrosti i ludila – profesionalizam
• Softver zanatlija VII – S vana kalajli unutra belajli

Tehničkoj praksi svakako trebaju i podrške iz drugih područja, kao što su metodologije upravljanjem. Ona najznačajnija u razvoju softvera je svakako agilna. Kao što smo već spominjali, agilnih metoda ima mnogo, ali sve one imaju neke zajedničke osnove zbog kojih ih i nazivamo agilnim. Agilnost, ili okretnost, prilagodljivost, vitkost kako tima tako i firme postiže se i kroz kombinacije raznih aktivnosti kao što su:

• Vizualizacija rada koji je u toku
• Pravovremeno postavljanje prioriteta i planiranje
• Fokusiranje na dostavu malih, minimalnih ali funkcionalnih i s stvarnom vrijednošću za klijenta dijelova proizovda
• Pozadinske liste zadataka iz kojih se zadaci uzimaju s vremena na vrijeme da bi se na njima radilo, tzv. Backlog
• Brze, brifing sastanke snogu, tzv. Stand-up
• Dijagrame napredaka, tzv. Burn-down charts
• Korisničke priče
• Kriteriji prihvatljivosti
• Scenariji
• Definicija gotovog
• Timovi s višestrukim sposobnostima, tzv. Cross-functional teams
• Redovne prezentacije urađenog

Iako su sve ove stvari itekako važne u razvoju softvera, ali i u drugim industrijskim granama pogotovo, to se u ovom poglavlju Sandro ipak ne bavi njima, nego onim drugim, tehničkim praksama.

Loš kôd je poput raka, teško se prepoznaje u ranim fazama i još teže liječi kada se konačno otkrije. U zavisnosti kada je otkriven život se može neko izvjesno vrijeme produžiti, ali smrt je neizbježna.

Iako postoje velika preklapanja između Agilnog pristupa i Softverskog obrta, Softverski obrt ipak nadopunjuje Agilni pristup fokusirajući se upravo na tehničke prakse i pružajući brzu i kratku povratnu spregu o kvaliteti kôda. Tehničke prakse pomažu da se osigura izgradnja na ispravan način.

Sve firme širom svijeta koje se bave razvojem softvera imaju gotovo iste probleme. Probleme oko rokova isporuke, menadžmenta koji ne funkciniše, birokratije, nedostatak timskog ili višetimskog rada. Ono što bi se moglo nazvati, uobičajeni problemi. Svaka od tih firmi traži neko čarobno rješenje. Zbog toga su gotovo sve firme u svijetu prihvatile neki od Agilnih pristupa. Mnoge su također zažalile zbog toga, jer su imale stav da će Agilni pristup riješiti njihove probleme sam od sebe, bez njihovog aktivnog učešća u promjenama kako razmišljanja, tako i djelovanja.

Zato, kada god se priča o nekom modelu ili pristupu razvoja softvera, odnosno menadžmenta, pa i tehničkih praksi uvijek se u početku nailazi na otpor. Otpor koji bi se mogao svesti u 10tak gotovo istih rečenica širom svijeta u svim firmama koje se bave razvojem softvera. A neke od njih su:

• Ijh, ne znaš ti kako to kod nas hoda!
• Naš šef to nikada ne bi dozvolio!
• Morao bi ti doći da vidiš kako mi radimo, sve bi ti se samo kazalo!

Historija ekstremnog programiranja (Extream Programming – XP)

Kada je Kent Bek (Kent Back) sada već davne 1996. godine predstavio i kombinovao skup praksi koje su podsticale XP kako prvi put u Krajhsler (Chrysler), a kasnije u Fordu s kolegom Don Velsom (Don Wells), pokazalo se da je takav pristup anomalija, jer je pristup totalno propao i menadžeri uopšte nisu bili zadovoljni. No, par godina kasnije, kada je onaj isti menadžment primijetio da se broj grešaka smanjio za trećinu, a kasnije ipak primjenom XP sveo na nulu, tu je XP dobio prvi zalet. Od prvog samita Agilnog pristupa 2001. godine XP se smatra agilnom metodologijom (iako je kako vidimo stariji od Agilnog pristupa).

Tokom transformacije u Agilni pristup, veoma mali broj kompanija se odluči također i za XP. Mogli bismo reći, pa očito je da su menadžerima menadžerske metode važnije od tehničkih.

I upravo je tu jedna od glavnih razlika između Softverskog obrta i Agilnog pristupa. Softversi obrt vraća fokus na tehničke metode, a jedna od njih je svakako XP.

Prakse i vrijednosti

Praksa je ono što se primjenjuje konkretno na projektu, dok su vrijednosti stvari od/prema kojima se živi.

U usvajanju bilo čega korisnikog i praktičnog mora se uvijek biti dosljedan, ići do kraja. Ne može se reći ja sam malo pedantan. Ili ja sam malo stručnjak. Ili je neko pedantan uvijek ili nije. Ili je neko stručnjak ili nije. Nema tu nikakve sredine. Ne može se reći ni ja sam pedantan samo ponekada. Niti se može biti stručnjak samo ponekada. Ili se stručnjak ili se nije stručnjak!

Upravo oko dosljednosti se i vidi koliko i kako neke firme napreduju, stagniraju ili propadaju, ali i čitavi narodi, nacije i države. I upravo tu bismo mogli povući paralelu.

Švabo vs mi

Ako se želi napraviti automobil, ne može se pristupiti proizvodnji olahko. Niti se može na prizvodnoj traci gledati kroz prste. Ustvari, može. Ali tada se kao gotov proizvod dobije Stojadin, a švabo dobije Mercedes, BMW, VW i mnoge mnoge druge, upravo bivajući dosljedan, principijelan. Ne popuštati ni milimetra dok se ne dobije perfekcija!

Menadžment će uvijek navlačiti vodu na svoj mlin. To je potpuno prirodno. Oni će reći kako bi bez njih sve propalo. Ali zapitajmo se šta bi bilo kada bi u jednom trenutku u svijetu svi menadžeri izumrli, a šta bi se dogodilo kada bi svi ljudi koji održavaju čistoću (bilo onu javnu, ulice, parkove, bilo onu u zatvorenim prostorijama, firmama, školama, bolnicama, …) izumrli u jednom trenutku?

Ne treba podcjenjivati ničiji posao, ničiji rad, ničiji trud, ali ga također ne treba ni precjenjivati. To što je neko sladunjav u govoru ili nosi kravatu, ne znači i da je sposoban, a još manje da je koristan timu, firmi ili užoj i široj (društvenoj) zajednici. Zbog toga uvijek treba težiti da se bude pravedan, prije svega. Voljeli nekoga, ne voljeli, pravda mora biti zadovoljena. Jedan od principa dosljednosti jeste pravednost.

Kada je u pitanju industrija, odnosno u ovom slučaju razvoj softvera, onda je za menadžere najvažnija metrika. Oni će u okviru menadžerskih metoda imati određene mehanizme da izmjere progres, ali kada je u pitanju usvajanje tehničkih praksi, da li su to tehnička lica sposobna učiniti? Kako predstaviti usvajanje tehničkih praksi i njihove koristi za sve, kako za tim, tako za klijenta, ali i cijelu firmu?

Dodavanje vrijednosti kroz praksu

Kao što smo spomenuli prije (odnosno Sandro u ovom sedmom poglavlju knjige The Software Craftsman, koju postepeno čitamo i na osnovu koje ovu seriju članaka objavljujemo) mnogi programeri kada ih se pita zašto ne usvoje neke prakse imaju “opravdanja”. Međutim, postoji jako mnogo stvari koje programeri mogu da rade, bez odobrenja bilo kakvih od strane menadžmenta. To je u okviru njihove slobode izražavanja i načina kodiranja.

Ako se pogleda slika u nastavku, vidjeće se da stvari koje se nalaze u unutrašnjem, najmanjem krugu su okviru odgovornosti svakog programera i on ih može, treba, ili čak mora raditi i usvajati. To su stvari za koje mu ne treba nikakvo odobrenje.

Automatsko testiranje

Uz pomoć automatskog testiranja moguće je gotovo pa jednim klikom miša testirati cijeli sistem. Zato se valjda i zove automatsko. Bilo koja promjena u sistemu bilo kada i po pitanju bilo čega treba da bude potvrđena testom. Za to je najbolje da se ima automatski test, svakako. Ako se prisjetimo konstatacije od ranije vezano za poređenje softverskog kôda i raka, ovdje je dobro upravo to pokazati. U početcima, napraviti dijagnostiku i pokrivenost kôda testovima sigurno je da uzima vrijeme, ali također se rak može otkriti u veoma ranoj fazi ili možda čak spriječiti da se ikada pojavi, a što svakako povećava vijek trajanja softvera. O cijeni održavanja takvog softvera u životu valjda je suvišno i govoriti.

Testovima vođen razvoj (TDD)

Za početak da kažemo da je zabluda misliti kako se TDD odnosni samo na pisanje tzv. Unit tests. TDD podrazumijeva pisanje bilo koje vrste testova koji će voditi ka kvaliteti izrade softvera. Također, ako se pogleda praksa koju TDD zahtijeva uvidjeće se da je to vrsta dizajna, odnosno dizajnerske prakse. (Nešto više o dizajnu u članku: Arhitekte, budite više inžinjeri, a manje umjetnici)

TDD je vrsta dizajna zato što dok se piše kôd i kada se uvidi da je toliko složen da ga je teško testirati, to će se zasigurno pristupiti drugačijem dizajnu. Kôd će se razbiti u manje cjeline koje imaju jasnu svrhu i cilj, te će ih biti lakše testirati, ali i održavati.

No, ovdje treba voditi računa o tome šta i kako se testira. Nažalost, nije rijetka praksa kod korištenja TDD-a takva da programeri tako pišu testove da je i najmanji refaktoring veoma bolan.

Dobar TDD je bolji od bilo kakve dokumentacije iz perspektive jednog programera i daje veoma brze i kvalitetne povratne informacije, ali i vrijednost cijelom projektu. Ono što menadžeri od inžinjera traže, ustvari.

Neprekidna integracija

Neprekidna ili kontinuirana inregracija je uglavnom dio cjevovoda, tzv. pipeline. Odvija se u procesu dostave promjena na softveru kroz određenu infrastukturu (cjevovod). U toku tog procesa, ako se ima jedan dio za automatsko testiranje, on itekako može da pomogne kvaliteti softvera. Uz odgovarajuća ograničenja moguće je natjerati sve kolege programere da kôd pokriju testovima u odgovarajućem procentu, ali i to da će dostava u potunosti biti obustavljena dok se ne riješi problem kod testiranja ili izgradnje (compile&build).

Nekada menadžeri, ali i programeri ovaj argument koriste da u potpunosti izbace QA timove (Timovi za osiguranje kvalitete, ili poznatije kao timovi za testiranje), prisiljavajući programere da pišu više različitih vrsta testova koji će biti dio neprekidne integracije.

Programiranje u paru

Pregled kôda od strane kolega ili tzv Code Review je uobičajena praksa širom svijeta kako bi se osigurao kvalitet kôda, ali i poslovne logike, bez obzira na broj i vrstu testova. No, to je također i dobra praksa da bi se ostatak tima upoznao sa promjenama i razlozima njihove promjene.

Svi oni koji koriste praksu pregleda kôda znaju kako se znaju sukobiti sablje (da ne kažemo mišljenja) oko neke implementacije. Posebno u takvim slučajevima programiranje u paru je više nego odlična praksa. Umjesto beskonačnih prepiski, svađa i rasprava na platformama za pregled kôda, jednostavno se sjede skupa za jedan sto, jedan računar i stvar pokuša riješiti zajednički sad i odma.

Ovdje postoji zamka koje se treba čuvati, a to je da se često puta zna desiti da ljudi sa istim stavovima, mišljenjima i iskustvom sjede skupa i bespotrebno troše vrijeme jednog od njih. Stoga su dobre prakse da se vrši povremena rotacija, ako se već vrši praksa programiranja u paru kako u timu, tako u cijeloj firmi.

Vrijednost koju nosi sa sobom programiranje u paru je prije svega utrošeno vrijeme, a što je menadžerima itekako važno, kao i svakako kvalitet.

Refaktorisanje (Popravka i izgradnja dijelova nanovo)

Ako bi se izviđačko pravilo: “Uvijek ostavi kamp mnogo čistiji nego što si ga pronašao” primijenilo kod izgradnje softvera to bi značilo da kada god se vrši neka promjena u kôdu kod dodavanja nove funkcionalnosti ili otklanjanja grešaka, potrebno je barem malo doraditi i ostatak kôda, napisati ga ljepše, uz optimizacije koliko i kako se da. Posebno je dobro imati ovu praksu kada se vidi da je stari kôd na kom se radi veoma složen. Programeri baš takve kôdove izbjegavaju refaktorisati, ali oni vremenom postaju sve složeniji i složeniji i svakako potencijalna mjesta ogromnih glavobolja.

Ovim se postiže dvostruka korist. Jedna je da se softver stalno pobošljava iz promjene u promjenu, iz dana u dan, a druga je da će se izbjeći nešto čemu programeri veoma često pristupaju, a to je ponovna izgradnja cijelog softverskog komada – refaktoring svega. Naravno, ovo je nešto što menadžeri očekuju i mogu vrjednovati.

Odgovornost

Svi bismo trebali biti odgovorni za svoje vlastite odluke (a valjda i jesmo, da li na ovom ili budućem svijetu) i to ne samo za usvajanje određenih praksi, nego i za njihovo odbacivanje. To se u ovom slučaju ne odnosi samo na programere, nego i na rukovodioce. Ako se nakon prezentacije svake od navednih praksi i njihovih koristi za cijelu firmu kako kratkoročno tako i dugoročno programeri ili rukovodioci odluče da ih odbace, onda bi trebali i da prihvate to da mogu snositi posljedice svojih odluka. Ne bi bilo loše zapisati te odluke i nekada ih nabiti na nos onima koji su bili protiv, kako bi se znalo šta i kako postupiti u budućnosti.

Pragmatizam

Biti pragmatičan (odlučan, koristan, aktivan, poučan) je jedna od najboljih kvaliteta koju softverski velemajstor može imati.

Tehnologije, metode i prakse koje se danas koriste ne znači da će se koristiti i sutra ili za godinu, pet, deset. Te stvari se stalno mijenjaju. Ne bi se trebale slijediti određene prakse zato što je to neko rekao, nego zato što se treba biti pragmatičan. Uvijek treba tražiti nove načine za biti bolji, imati veću vrijednost, davati više, kako bismo sami sobom bili zadovoljni. Ali i da naši klijenti budu zadovoljni nama.

Dogmatsko razmišljanje često vodi u velike probleme i neki bi rekli da je veoma loše, uz navođenje jasnih argumenata. Zato uvijek treba propitivati. Dat nam je razum da pitamo, promišljamo i razmišljamo, uočavamo i zaključke donosimo. Ne trebamo biti niti oholi i ne prihvatati tuđe prakse i mišljenja također.

2

Hits: 60