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

U poglavlju Softver zanatlija IV – Softverski obrt spomenuli smo Proglas softverskog obrta i odmah u prvoj rečenici se veli:

Ne samo softver koji radi
nego također i dobro iskovan softer. 

Što će reći, ne treba da nam kao profesionalcima, kao softver zanatlijama, vrhunskim stručnjacima cilj bude takav da je važno samo to da softver radi, a šta je unutra koga briga. Ili kao što bi rekla jedna narodna:

S vana kalajli, unutra belajli.

Hoće se reći, s vana izgleda kao neko odlično lijepo, dobro napucano auto – kalaja, a unutra Bože sačuvaj, što visi, to i otpada.

Svakako, teoretski idealno napisan kôd., sa testovima, sa nebrojeno mnogo provjera, refaktoringa, pročisćavanja i slično ne garantuje da će softver kao proizvod uspjeti. Jer ne zavisi uspjeh softverskog proizvoda samo od napisanog kôda i to da li softver funkcioniše ili ne. Zavisi i od poslovne strategije, snage konukrenata, partnerstva, tehničkih ograničenja, integracija, marketina i tako dalje. Ali, softverske stručnjake treba zanimati njihov dio i da njega odrade na najbolji mogući način u okrivirima ograničenja koja su uspostavljena, odnosno dogovorena. Tj, da se softverski stručnjaci odlično razumiju zahtjeve klijenata, menadžera, snagu konkurenata, a ne gledaju samo kako će napisati kôd i reći kako je njihov dio posla završen.

Neke firme, čak i dan danas, misle da će dobro izrađena dokumentacija sa svim dijagramima, pa čak i ponekim pseudo kôdom omogućiti nekim jefitnim programerima u trećim zemljama da izrade izvrstan softver za male pare. U takvim organizacijama menadžeri imaju pozicije baš kao u industrijskoj proizvodnji. Sve gledaju odozgo, imaju veće plate, bolje uslove, pitaju se za sve, a za sve što ne valja, krivi su oni ispod. Pa čak i mnoge firme koje su svoje poslovanje pretvorile manje više u neki od agilnih procesa imaju slične stavove. Zbog toga su ljudi okupljeni oko ideje softverskog zanatstva stvari postavili malko drugačije.

Baštovan i briga za vrt

Razvoj softvera više liči na baštovanstvo nego na građevinu.

Pragmatik programer (The Pragmatic Programmer)

Sandro nam daje jedan primjer i to baš iz knjige Pragmatični programer da je razvoj softvera poput baštovanstva. Nije to posao jednom napraviš, pokupiš skelu i ideš na postavljati skelu na drugi fakultet kao u onom vicu. To je posao do kraja života. Uvijek se ima šta obrađivati, kresati grane, brinuti o napadima raznih baja, zalijevati, … Kako se sve mijenja oko softvera (kako hardver tako i ostali softver uključujući OS) tako se i sam softver vremenom treba i mora prilagođavati novim uslovima. Softver se također mora dorađivati i s novim funkcionalostima, ali i doživotno otklanjati greške – jer sve što proizvede čovjek nikada ne može biti savršeno i potrebno je manje ili veće dorade.

Ovdje bismo mogli dodati još jedan primjer iz autoindustrije. Novo vozilo, tek sišlo s proizvodne trake možemo platiti 20k ili 200k KM, ali proizvođač zahtijeva da ako želite imati garancije i funkcionalno vozilo javljate se u redovan servis svake godine. Nerijetko u prvih 5 godina servisa vozila početne cijene 100k uloži se još najmanje 20k KM (Što je iznos ne tako lošeg novog malog gradskog vozila!). I to smo svi prihvatili. Znamo da to mora tako. Međutim kod razvoja softvera održavanje smatramo nepoštenim nametima. Često se za podršku softveru nakon razvoja i cijenu koja se definiše kaže da je zelenaška. Svakako, postoje strategije mnogih firmi da proizvedu takav softver da mogu ucjenjivati svoje klijente i korisnike, ali generalno, to nije pravilo niti takvih firmi ima mnogo oko nas.

Bašta koja se ne održava redovno itekako zaraste. Biljke mogu čak i propasti i neopodno je zasaditi potuno nove. Također, automobil koji se ne održava redovno vrlo brzo će da bude doveden u veoma nezavidnu situaciju iz koje je možda nemoguće i povratiti ga. Na takav način treba posmatrati i razvoj softvera.

Odnos kvalitete kôda i brzine izbacivanja nove funkcionalnosti

Kada se tek počne s razvojem softvera sve je novo. Nov i čist kôd, novi testovi, nove funkcionalnosti. Sve ide ralativno brzo čak i s osrednjim programerima. Međutim, ako tim sačinjavaju većinski osrednji programeri čist kôd iz dana u dan postaje sve prljaviji i zapetljaniji. Testovi više odjednom ne rade kao prije, a za nove funkcionalnosti sada treba mnogostruko više vremena nego prije. Jasno se vidi koliko je važno očuvanje čistog, nezavisnog kôda tokom razvoja softvera. Činiti neophodne refaktoringe kada god je to moguće kako bi se softver održao jednostavim i stabilnim što duže.

Ne smije se dozvoliti da se bude talac vlastitog softvera. Ako se ne bude održavao standard kôda, testova, kao i samih programera to će se neminovno dogoditi, a tada su svi na gubitku. Povećanje broja funkcionalnosti i pohlepa za većom i bržom zaradom ne smije zaslijepiti nikoga ako se razvija softver kao profesionalac. Jer, profesionalci tako ne rade. I ako zovnemo nekog lokalnog keramičara i ponudimo mu ogromne pare da nam nešto na brzinu sfušeri, on, ako je profesionalac, neće na to pristati nikada, ma koje pare da mu se nude. Takvi trebaju biti i softverski velemajstori.

Mnogi programeri, čak i velemajstori, izbjegavaju pisanje testova, te čišćenje posojećeg kôda kroz manje ili veće refaktoringe. Ne rade to oni zato što žele pisati loš kôd, ali uvijek se nađe neko opravdanje. Nema se vremena. Nije to toliko sada važno i slično neke fraze. A o tome da nas neko pritišće da trebamo izbaciti novu funkcionalnost čim prije ne treba uopšte ni spominjati. No, pritisak je sastavni dio života jednog programera.

Sandro nam govori jednu veoma važnu stvar u ovom poglavlju koju ovdje želimo posebno naglasiti. To je programiranje vođeno pisanjem testova (TDD – Test Driven Development). I dan danas srećemo veoma iskusne programere širom svijeta, ali koji nisu upoznati s ovim konceptom kroz vlastiti rad. Čuli su za to, pokušali su nekada nešto, ali odustali. Svi oni koji su ozbiljno pristupili razvoju softvera kroz TDD, iznenađujuće veoma rijetko koriste uopšte Debugger. A da ne govorimo o tome da im je kôd, odnosno komad softvera na kom rade neuporedivo stabilniji i lakši za održavanje nego onih koji ne slijede princip TDD-a. Neko će se možda sada pitati, a šta to ima tako pametno u tom TDD-u? Ja sam pokušao/la, i ništa pametno nisam našao/la tu osim gubljenja vremena! Odgovor je mnogo jednostavniji nego što se očekuje. Kada se razvija softver uz pomoć TDD metodologije tada se sva poslovna logika piše u što je moguće manjim, kraćim, jasnijim metodama, funkcijama, strukturama i klasama. Toliko malim i jasnim da ih je moguće jasno i precizno testirati uz pomoć UnitTest-ova, Functional testova, Integration testova i ostalih vrsta testova o kojima ćemo pisati poseban članak, ako Bog da. Također, način “razbijanja” kôda u manje cjeline omogućava programeru da ne vrši apsolutno nepotrebno dupliciranje. Kada se kôd “razbije” on se može iznova i iznova koristiti na mnogo različitih mjesta u softveru, umjesto da se uvijek i iznova duplicira manja ili veća količina kôda u metodama, funkcijama, strukturama, klasama, …

Biti mudar nasuprot biti brz

Svaki klijent bez obzira o kom proizvodu se radi želi da mu se implementira neka nova funkcinalnost tako brzo, kao što brzo promijeni mišljenje. Naše je da im njihove želje ispunjavamo. Oni od nas očekuju to, a mi kao velemajstori u razvoju softvera želimo da opravdamo očekivanja. Obzirom da mi koristimo njihovo vrijeme i njihov novac u razvoju proizvoda, onda moramo pristupiti veoma mudro u svakoj mogućoj situaciji, umjesto što ćemo se truditi da izbacujemo nove funkcionalnosti sve brže i brže. Utrošićemo onoliko vremena koliko je potrebno da bismo imali stabilan softver, čist kôd, mnogo testova koji pokrivaju razne scenarije i sve ostalo što je potrebno da bismo bili profesionalci.

Timovi i pojedinci koji pristupe na takav, mudar način, donijeće mnoge koristi sebi sabima, ali i cijeloj firmi. Kasnije će u odnosu na druge firme i druge timove njihov softver da bude stabilniji, lakši za održavanje i proširenje, ali i s mnogo manje grešaka, na koje se neće trošiti ogromno vrijeme i novac. Svaki menadžer to želi, zar ne?

Promjena mišljenja i stava

Većina programera se itekako obraduje kada im se kaže da će raditi na nekoj novoj stvari. Sve iz početka. Friško, novo. Nove tehnologije. Novi jezik. Nove metode. Međutim, kada se spomene unaprjeđenje naslijeđenog kôda onda se svi nekako okahare. I to je u jednu ruku razumljivo. U svima nama čuči neko radoznalo dijete koje želi da otkriva nove stvari. U ovom poglavlju, Sandro nas vodi kroz njegovu životnu priču u kojoj nam naglašava između ostalog i to da će nam u životu vjerovatno biti veoma rijetke situacije kada ćemo, čak i promjenom firme, raditi na nečemu novom. Uvijek će tu biti neki naslijeđeni kôd, manji ili veći. Složeniji ili prostiji.

Veli, Sandro, umjesto što ćemo kukati, psovati, galamiti i nervirati se trebamo zauzeti novi stav. Promijeniti naš odnos spram onoga što trebamo uraditi i pokušavati svakim danom da popravimo u naslijeđenom kôdu ono što nevalja istovremeno razvijajući novi kôd s novim funkcionalnostima. U početku će biti mnogo frustracija zbog nerazumijevanja naslijeđenog (legacy) kôda, ali kasnije kada budemo napisali vlastite male cjeline kao i zamijenili stari kôd osjećaćemo se itekako ispunjeno i zadovoljno. To će nam pričinjavati nekada i veće zadovoljstvo nego da pišemo softver potpuno iz početka. Kao što rekosmo u početku može da bude dosadan i s puno frustracija, a kanije s mnogo radoznalosti na koje se troši previše vremena da se popravi baš sve jer je uzbudljivo. Važno je naći mjeru i biti u svakoj situaciji profesionalac.

Ako vam se nešto ne sviđa, promijenite ga. Ako ne možete promijeniti, onda promijenite način na koji razmišljate o tome.

Meri Engelbrajt (Mary Engelbereit)

Hits: 80