Objektno oblikovanje – što je sad pak to ?

Ako ste zbunjeni sintagmom „objektno oblikovanje“ te ste pomislili da se radi o nekoj novoj formi apstraktne umjetnost – relax :-). Nema tu nikakve „umjetnosti“ već se radi o hrvatskoj inačici svakom developeru dobro poznatog termina object design.

O objektnom dizajnu će se na ovom blogu još puno pričati, a za ovaj post je bitno da je to (i) naziv predmeta koji ću predavati u prvom semestru diplomskog (M.Sc.) dijela studija koji na FERu starta u mjesecu rujnu. Kako su mi se počeli javljati studenti s upitima „o čemu se tu radi“, a službena verzija opisa predmeta koja je nastala prije jedno tri godine kad se slagao curriculum za FER-2 studij (po Bolonji) je pomalo outdated (preciznije, u međuvremeno je značajno dorađena), mislim da nije zgorega malo detaljnije opisati teme koje će se obrađivati na predavanjima, kako će organizacijski sve to izgledati, a i što će se očekivati od studenata koji upišu predmet :-).

Pa, za početak o organizaciji.

Predmet nosi za izborne predmete standardnih 5 ECTS bodova, ima opterećenje od 45 sati predavanja (ie. 3 sata predavanja tjedno) i „klasičnu bolonjsku“ organizaciju, što se najbolje vidi i po načinu, odnosno kompoziciji bodovanja za završnu ocjenu:

- blicevi 10 %

- domaće zadaće 15% bodova

- međuispit 20%

- završni ispit: 35%

- izrada seminarskog rada: 20%.

Ili, kako se to službeno po FERu kaže: „Kontinuirana provjera znanja“ :-). Naravno, to će i dalje nažalost/vjerojatno značiti pet šest (7-8!?) „kampanjskih sprinteva“ za studente, gdje će neki trajati dan-dva, a neki i cijeli tjedan, ali to valjda tako mora biti :-).

A što će se na predmetu raditi/učiti ?

U jednu rečenicu – kako primjeniti/iskoristiti tehnike objektno (orijentiranog) dizajna s ciljem što efikasnijeg razvoja informacijskih sustava!

Naravno, ovakav opis je vrlo širok i potrebno ga je malo suziti i preciznije definirati jerbo na FERu već ima predmeta, čak bih rekao i podosta :-), koji su posvećeni „tehnikama za efikasniji razvoj informacijskih sustava“.

A specifičnost ovog predmeta, odnosno ono po čemu ga planiram napraviti ponešto različitim od postojećih, je sadržana u samom nazivu – OBJEKTNO oblikovanje. Ukratko bi se moglo reći - objects to the core.

Jer, ako ćemo pričati o načinima za savladavanje sve veće složenosti modernih softverskih sustava, što je u stvari vječiti izazov software developmenta, iz mog, sad već 20-godišnjeg iskustva s programiranjem proizlazi jedan nedvosmisleni zaključak – objektno-orijentirana paradigma is your best friend!

Apstrakcija i enkapsulacija u borbi sa složenošću softvera predstavljaju najjače (a često i jedine!) vojnike, i iako su u računarskoj znanosti oba principa otkrivena/identificirana poprilično davno (Parnasov princip „Information hidinga“ još tamo iz 70-tih!), tek je objektno-orijentirana paradigma apstrakciju i enkapsulaciju postavila kao „kamen temeljac“ razvoja softverskih sustava!

„Ma sve je to lipo Zvone, ali čuj, danas ti SVI programiraju po OOPu!?“

Da, ali ipak ne :-).

Jer, prepakiravanje proceduralnog programskog kôda u nekoliko klasa sa članskim varijablama i funkcijama NIJE OOP! Ili, da budem precizniji, takvim pristupom OOPu se neće dohvatiti puni potencijal koji objektno-orijentirani način razvoja softvera pruža!

Kako identificirati objekte (u stvari klase iz kojih se instanciraju), kako ih softverski modelirati i prilagodili „virtualnom svijetu“ objektnog modela, kako i na koji način ustanoviti kolaboraciju među tim objektim, kako ih uklopiti u arhitekturu cjelokupnog sustava … sve su to vrlo važna (da ne kažem krucijalna) pitanja koja daleko nadilaze „tehničke aspekte“ OOP-a (što je članska funkcija, što je članska varijabla, što je private/public, što je nasljeđivanje i slično …).

I to je područje objektnog dizajna kojim ćemo se baviti na ovom predmetu.

S obzirom da sâm objektni dizajn nije zatvorena (self-contained) tehnička disciplina, odnosno da egizstira primarno kao dio procesa razvoja softvera, na predavanjima će se određeno vrijeme posvetiti i stavljanju OO dizajna u kontekst tog procesa, s posebnim naglaskom na moderne tehnike agilnog razvoja softvera.

Početi ćemo s uvodnim predavanjem, s (radnim) nazivom „Software development is hard“, na kojem ćemo„urakljiti“ problem, odnosno identificirati faktore koji razvoj softvera čine teškim te raspraviti razloge koje OO paradigmu čine privlačnom.

Nakon toga ćemo u „pripremnom“ dijelu odraditi kratki (i ubrzani!) tehnički uvod u osnove OO programiranja, te vidjeti kako organizirati proces prikupljanja i analize zahtjeva (requirementsa) a da se taj proces prirodno uklopi u tehnike OO dizajna (use case is the keyword here!)

A po odrađivanju tog pripremnog dijela, ulećemo u bît predmeta – primjenu Domain-driven design tehnika za razvoj softvera. Da li je to tehnika, ili možda metodologija, ili „samo“ vještina je tema za detaljnu razradu, ali ono što je ključno je da je pri primjeni DDD-a fokus na što vjernijem preslikavanju domene problema (= ono što bi softver trebao riješiti) u objektni model koji će biti osnova za softversku realizaciju.

Ukoliko ćete primjetiti da tehnika „find the nouns“ za identificiranje objekata uz pripadno vjerno preslikavanje objekata (entiteta) iz realnog svijeta u svijet virtualnih objekata i nije baš pripametna :-), ja ću se potpuno složiti s vama i reći da su stvari ipak značajno kompliciranije.

Kako definirati i u softveru realizirati model domene koji će što vjernije reprezentirati problem space (s primarnim ciljem olakšavanja komunikacije stakeholder – developer), a da taj model bude u skladu sa zahtjevima postavljenim na softver (odnosno da je u svojoj realizaciji primarno posvećen zadovoljavanju zahtjeva korisnika, a ne „vjernosti preslikavanja“ realni->virtualni svijet) je THE problem kojem ćemo se posvetiti na ovom predmetu.

Da ne bi sve bilo ovako apstraktno, kroz cijeli semestar ćemo u skladu s naučenim konceptima razvijati jedan case study (a sličnog formata će biti i seminarski rad koji će studenti trebati odraditi), a kao dodati bonus (iako to nije nikakav „bonus“ već conditio sine qua non –o čemu imam već DVA parcijalna posta ) ćemo se pozabaviti i tehnikama Test Driven Developmenta koje se prirodno slažu s DDD-om.

U tu priču će se lijepo uklopiti i Model-View-Controller (MVC) pattern koji je prirodni (čak i nužni!) suputnik i DDD-a i TDD-a, a reći ćemo ponešto i o Objektno-Relacijskom Mapiranju (triba negdje i spremit te podatke, jel’ tako ) – ukratko: forget ADO.NET, (N)Hibernate rulez !

„Lipo, Zvone, lipo, a reci ti nama ima li kakvih preduvjeta za uspješno savladavanje svih tih tema?“ – sad će se sigurno kogod javiti.

Ima, jasno da ima – i osnovni preduvjet je određeno iskustvo programiranja! Ako niste do sada odradili projekt s bar par tisuća linija programskog kôda (u bilo kojem programskom jeziku) i ako niste „na svojoj koži“ osjetili ubode složenosti softvera, onda će ova priča biti uvelika apstraktna. Ako ćeš se penjati na Mount Everest, onda je logično bar malo vježbati na onoj penjačkoj stijeni, prije nego se uputiš u Nepal :-).

Dakle, nije sve izgubljeno, ali ukoliko ste u takvoj situaciji, morate biti spremni na „dodatni angažman“

Pa vi vidite ima li tu za vas što zanimljivo, a naravno, svi komentari i pitanja su dobrodošli.

Samouki programer vs. FERovac!?

U prethodnom postu sam načeo temu „što može raditi prvostupnik FERa“ (B.Sc. titula) nakon završenog trogodišnjeg studija.

„Službena“ verzija je (citiram članak iz Mreže) da se od prvostupnika može očekivati „dobro znanje o području koje je birao godinama na faksu.“ i da se „za prvostupnika smatra da može voditi manje projekte, manju skupinu ljudi ili biti asistent glavnom projektantu“.

U svom stavu na kraju posta sam bio nedvosmislen:

… oni ne samo da neće biti za „voditelje malih projekata“, već mnogi od njih neće spadati niti u kategoriju „kvalificirani programer“ !!!

A kao osnovni razlog za takvu situaciju sam identificirao – premalo praktičnog rada!

Jer, make no mistake about it, do statusa kvalitetnog programera se dolazi ISKLJUČIVO PRAKSOM !!! (a posebno je „nezgodno“ s ovom profesijom što zahtijeva kontinuiranu praksu – zbog reinventing-a barem svakih desetak godina!)

Ovdje se otvara i posebno pitanje – da li „voditelj projekta“ mora biti dobar programer? Tom pitanju ću se detaljnije posvetiti u jednom od sljedećih postova :-), ali ukoliko pričamo o vođenju projekata kako se o tome govori u „službenoj“ verziji kvalifikacija prvostupnika, onda vjerujem da je svakome jasno da je biti „kvalificirani programer“ OSNOVNI PREDUVJET za obavljanje takvog posla! Jer, ako ćemo pravo, „voditelj malog tima“ ili „pomoćnik glavnom projektanu“ (ovo je naravno, totalno zastarjela Waterfall spika ;-)) se u engleskoj terminologiji kaže lead DEVELOPER :-)))).

A kakvi su po pitanju programerskih vještina FER-ovi bakalari (pardon, baccalareusi ?

Na to pitanje se može odgovoriti na dva načina. Jedna mogućnost je postaviti se u „apsolutističku“ (da ne kažem radikalnu poziciju i beskompromisno (pro)govoriti o tome kakve stvari jesu, kakve bi mogle biti, i, najvažnije, kakve bi TREBALE biti! A može se zauzeti i „opravdavajuću“ poziciju u kojoj će fokus biti na ono što je feasible (tzv. „umjetnost mogućeg“, gdje su Hrvati dali, a daju i dalje, značajne doprinose na svjetskoj razini – za čitalačke mazohiste, odličan uvod, iako poprilično težak za čitanje, u hrvatsku verziju maoizma i zrelog kardeljizma daje kolega ap s pollitika.com portala ;-))

Ja ću se na poziciji „umjetnosti mogućeg“ ipak zadržati vrlo kratko. Što je sasvim u skladu s mojim „političkim alter egom“ a to je ionako klasika u svim ostalim medijskim osvrtima na tu temu. Dovoljno je reći da s te pozicije studenti FER-a mogu biti relativno zadovoljni obrazovanjem koje dobivaju (uzimajući, naravno, value for money mjeru - pogotovo zato što money u najvećem dijelu daje ministarstvo!)

A s apsolutističko/radikalne pozicije, treba biti iskren i reći da stvari na FERu baš i nisu optimalne! Kolege studenti su u komentarima na prethodni post bili 100% u sridu i ukratko se to može reći ovako:

Završeni student FER-a (novi B.Sc., a i stari dipl.ing.) je kvalificirani programer JEDINO u slučaju da se tijekom studija potrudio SAMOSTALNIM radom dosegnuti taj status!

A ukoliko je tijekom studija na FERu dotični student odradio „samo“ ono što se od njega tražilo da bi položio/prošao xy predmeta (čak i ukoliko ih je pri tome polagao s dobrim ocjenama!), tada od „kvalificiranog programera“ tu nema niti k

I to je tako i nikako drugačije :-).

Bar 30 (50!?) % studenata koji POLOŽE „osnovne“ programerske predmete na FERu - PIPI („Programiranje i programsko inženjerstvo“ – a u biti programiranje u C-u ;-)) i ASP („Algoritmi i strukture podataka“) - efektivno NE ZNA PROGRAMIRATI! Jest, ima tu na prvoj godini podosta i budućih energetičara, inženjera (tele)komunikacija, automatičara i elektroničara, ali podosta takvih završi i na računarski orijentiranim smjerovima!

„Pa kako su onda položili te predmete!!!“ – sad će vikati „idealisti“ :-)!

A lipo – ne moš’ njih 75 % bacit’ na ispitu :-)! Nije „pedagoški“, i uostalom, kakav si ti to onda profesor ;-).

Tu je važno i pitanje kako uopće provjeriti nečije programerske vještine!? Pismeni ispit (dobro, 2 međuispita i završni ispit s četiri-pet zadataka koji se rješavaju na papiru svakako daje nekakav uvid u programersko znanje studenta koji ga rješava, ali da bi slika bila potpuna, nužno je evaluirati i sposobnost praktične primjene tog znanja, a tu bi, bojim se, za FER rezultati bili porazni :-(.

Jer, čak i ukoliko student na ASPu recimo zna na pismenom ispitu riješiti jednostavan problem s binarnim stablima, staviti ga pred kompjuter i reći mu „give me running program“ u velikoj većini slučajeva će završiti fijaskom :-(.

Nekada smo imali Laboratorijske vježbe, gdje su studenti pod nadzorom asistenata barem malo dolazili u doticaj s praktičnim radom, ali Bolonja je, nažalost, labose poslala u ropotarnicu povijesti … Ne da su ti labosi bili nešto perfektno, odnosno rješenje svih problema o kojima pričam, daleko od toga, ali su bar prisiljavali studente na nešto praktičnog rada.

Sada imamo automatizirano ocjenjivanje domaćih zadaća koje studenti uploadaju na website i … kako da to kažem, piracy is rampant (a za ovo se nadam uskoro imati i „znanstvenu“ podlogu). I tako brucoši polože PIPI i ASP a da nikad nisu niti upalili neki C kompajler (a koliko je takvih u postotku, e procjenu tog broja bih volio čuti od kolega u komentarima ;-)). Kad se tako počne, ni nastavak ne može biti puno bolji.

A di je tu samouki programer iz naslova ? I kakve to veze ima s njim?

E pa ima, jer nedavno sam se našao u diskusiji s jednim kolegom koji je vehementno tvrdio da bi na poziciju programera/developera u svojoj firmi (mali developerski shop) uvijek PRIJE uzeo samoukog programera, nego nekog FER-ovca!!!

Hmmm …

Pitanje za žestoku diskusiju – koja se može presjeći u korijenu – treba uzeti onoga ko bolje zna raditi taj posao! Iliti, ko „više zna“. I gotova priča (btw. moj šef, inače dekan FER-a, je na to pitanje u spomenutom intervjuu u Mreži odgovorio otprilike isto – naravno, u puno ljepšem „pakiranju“). Ali pokušati uspostaviti bilo kakvu generalizaciju u ovom slučaju nužno vodi u flame-war i stoga ćemo to preskočiti.

Ipak, all is no lost u ovoj diskusiji jer pitanje se može postaviti i na drugačiji način! Ajmo probati ovako:

Ukoliko treba birati između B.Sc. inženjera FER-a, i samoukog programera koji je otprilike istu količinu vremena posvetio poboljšavanju svoje programerske vještine kroz praktični rad, koga uzeti ?

Heh … ni tu odgovor nije jednoznačan jer ima različitih FERovaca :-). Ali, ono što jest sigurno je da FER-ovac (ponovno, ukoliko pričamo o prosjeku!) po „momentalnoj iskoristivosti“ nije ni blizu samoukom programeru!

I to i ne može biti nikako drugačije :-).

Jer u tri godine koje je student FER-a potrošio na udaranje temelja svom inženjerskom obrazovanju naš samouki programer se mogao posvetiti glancanju svojih koderskih vještina i istraživanju C++a, Jave, PHP-a, AJAX-a, Railsa i svih ostalih hot/in tehnologija. Uz „gaženje“ matematikom, fizikom, energetikom (pa i elektronikom!) i ostalim stvarima koje, da budemo iskreni, sa Computer Science imaju malo ili nikako veze (naravno, ovo za matematiku ne vrijedi!), student FER-a je nužno in disadvantage!

„A jel ti to Zvone kažeš da bi svakome bilo pametnije okaniti se FER-a, uzeti par dobrih knjiga iz programiranja (ili ih naći na internetu) i SAM naučiti programirati?“

NOOOOOOOOOOOO

Da pojasnim stvar iz osobne perspektive – ja sam 90 % onoga što o kompjuterima znam, naučio sam :-). A kad kažem sam, onda pod time mislim ono što „naučiti nešto sam“ doista i znači – bez ičije pomoći, bez mentora, bez predavanja samo uz (često šturu) literaturu …

Gfa Basic (’90-te), pa C (’92), pa C++ (’95), pa Visual Basic (’99), pa C# (’02) … dva jezika koji ne spadaju u kategoriju „learned by myself“ su BASIC (’8 koji sam naučio na tečaju u Omladinskom domu u Zadru te FORTRAN (’94) koji je bio standard na predmetu „Programiranje“ na prvoj godini FER-a.

Ako ćete ovdje primjetiti da sam u usvajanju programskih jezika malo „usporio“ u zadnje vrijeme, i da bi bilo vrijeme za nove izazove – jest, u pravu ste – ali se već godinu dana odlučujem hoće li to biti Ruby, Python, JavaScript ili F# (a i PHP me nekako pinga u zadnje vrijeme ;-).

Dakle, može li se sam naučiti programirati ?

Apsolutno da! Uostalom, eno vam primjer Billa Gatesa :-).

Ali, ali, ali … Dvije stvari se ne smiju zanemariti! Prvo, ja osobno ne poznam puno ljudi koji vezano uz kompjutere imaju isti drajv kao i ja (je, ne znam puno ljudi, vjerojatno je u tome problem :-)). A da bi sve to naučili sami, treba vam drajva, ooo, itekako treba :-).

A drugo, onih 10 % znanja koje sam stekao na FERu NIJE ZANEMARIVO !!!

Daleko od toga! I tu dolazimo do jedne od ključnih komponenti razlike između samoukog programera i FER-ovca: FERovac ima širinu! Jer čak i ukoliko pričamo o prosječnom studentu FERa, znači onom koji nije dušom i srcem vezan za kompjutere već je više onako za „odraditi posao i dobiti diplomu pa onda što bude“, ta širina će prije ili kasnije biti od koristi.

Osnove UNIX-a (što se uči na Operacijskim sustavima), baze podataka, računarska grafika, osnove rada mreža, … sve to vješt programer treba znati. A najefikasniji način za sve to savladati je naučiti to na FERu (ok, priznam, ovo bi se moglo/trebalo kvalificirati, ali hej, pa moram vam baciti pokoju kost ;-).

Važno je dodati da diploma FERa svjedoči i o određenom stupnju sposobnosti, marljivosti i upornosti (iako se nedostatak bilo koje od te tri vrline može nadoknaditi značajnijim angažmanom u druge dvije ;-), a i usvajanje famoznog „inženjerskog pristupa“ nije za zanemariti (evo još jedne koske ;-).

Onda, kako ćemo razriješiti fajt između samoukog programera i FERovca?

Standardno … It all depends

Ukoliko naiđete na FERovca s odličnim ocjenama, a koji se tijekom studija nije samo „zabio u knjigu“ već je stečeno znanje nadopunjavao samostalnom primjenom u praksi (pa čak i ako je bilo „samo“ za svoj gušt, kao što najčešće i jest), u rukama vam je dobitni listić na lotu i takvoga potencijalnog zaposlenika nikako ne smijeti propustiti!

Ukoliko se pak radi o studentu FERa koji je „samo“ korektno odradio svoje obaveze na fakultetu, onda je priča malo drugačija i samouki programeri postaju kompetitivni. Naravno, ovdje je bitno i o kakvom se točno poslu radi, ali recimo to ovako: prosječnom završenom studentu FER-a, u situaciji kad se traži standardni developer (recimo, za web aplikacije), činjenica da ima diplomu FERa, ne predstavlja odlučujuću prednost i netko ko već ima tri-četiri godine iskustva rada u praksi s konkretnom/traženom tehnologijom je sasvim kompetitivan, dapače čak i više od toga :-).

Ovdje ima i jedan „tamni“ aspekt priče s današnjim studentima FER-a – niko ne bi šporkava ruke programiranjem! Svi bi odma bili neki voditelji, menadžeri i slične điđe miđe, uz plaću od 10.000 kuna, službeni auto, a i tajnicu, nek’ se nađe :-). Ali, to je tema za poseban post…

Za zaključak ove priče je dovoljno reći da osobno poznajem developere koji nikada nisu završili fakultet (većina ih je probala pa nisu uspjeli, a neki nisu čak ni probali!) a ipak su VRHUNSKI programeri

Ukratko, nema jednostavnih rješenja - jedini spas vam je dobar candidate screening process …

Što da radi prvostupnik (iliti bakalar :-) s FER-a nakon stjecanja B.Sc. diplome?

Kritizira me vrend neki dan (dok smo gledali kako se na turskom primjeru potvrđuje ona engleska poslovica: „what goes around, comes around“ – Gary Linecker mi je također pao napamet ;-)) da se (pre)dugo nisam osvrnuo na „obrazovne“ teme na svom blogu :-).

Što reći nego: mea culpa!

I dodati da prije godišnjih odmora uvik ima dosta posla „za dovršiti“, što uz neke VRLO zanimljive poslove/projekte u perspektivi i angažman oko pokretanja blogerske udruge u Hrvata nadam se može poslužiti kao dovoljno dobro opravdanje.

A povod za ovaj post je članak u zadnjem broju Mreže u kojem Hrvoje Pelaić daje osvrt na „Bolonju u Hrvatskoj danas“ iz perspektive IT obrazovanja.

I da Vam pravo kažem – ČLANAK JE ODLIČAN !

Lijepo je opisano kako se Bolonja „provodi“ u Hrvatskoj (ili preciznije kako se fejka ;-). FER je za koliko toliko korektnu provedbu Bolonje pohvaljen točno onoliko koliko triba (ima doduše priča oko ASIIN certifikata, ali nećemo sad :-). Ukazano je na problem worker gap-a koji će se pojaviti na tržištu hrvatske IT snage zbog toga što će većina prvostupnika nastaviti obrazovanje još dvije godine na diplomskom (M.Sc.) studiju (što znači da će kadrovske službe hrvatskih IT firmi biti u još većim problemima !). I ispravno je ukazano na globalizacijske efekte koji će neminovno zahvatiti i Hrvatsku (s taman ispravnom dozom optimizma – i završetak članka mi se posebno sviđa ;-).

Naravno, kad bi u članku SVE bilo tako lijepo i točno, ne bi bilo potrebe za ovim postom :-). A kako je post tu, onda očigledno ima i nešto što mi je „zapelo za oko“.

Naravno ima :-), a radi se o poslovima koje bi prvostupnici (dakle B.Sc. titula nakon tri godine studija) trebali raditi u gospodarstvu.

Kao što je lijepo u članku napisano, VEĆINA studenata koji uspješno dosegnu B.Sc. titulu (na FERu njih oko 300, od preko 1000 koliko ih je prije tri godine krenulo u „Bolonju“!) će nastaviti diplomski studij i to bi moglo stvoriti probleme u gospodarstvu ukoliko nastane gap između pritoka „starih“ dipl.ing. i „novih“ M.Sc. inženjera.

Ali, to će se nekako riješiti (ako ništa drugo povećati će se plaće ;-)) a ostaje pitanje što mogu raditi oni studenti koji NEĆE nastaviti diplomski dio studija (zadovoljiti će se da ostanu B.Sc.) ? S obzirom da se Ministarstvo obvezalo na 100%-tno subvencioniranje pohađanja diplomskog studija, barem ne probati odraditi M.Sc. je prilično blesava odluka :-), ali vjerujem da će biti i takvih (blesava = you are letting FREE MONEY pass you by ;-).

Dakle – što bi B.Sc. inženjeri mogli raditi nakon što završe studij?

Dati ću odmah i hint – čeka ih PUUUUNO učenja .

A evo što Hrvoje kaže u gore spomenutom članku:

„poslodavci od njega (prvostupnika, op.Z.R.) mogu očekivati nešto slabije opće znanje od nekadašnjeg diplimiranog inženjera, ali dobro znanje o području koje je birao godinama na faksu.“

„Što se tiče posla koje može obavljati, za prvostupnika se smatra da može voditi manje projekte, manju skupinu ljudi ili biti asistent glavnom projektantu. Drugim riječima, poslove srednje složenosti, slične onima koje sad rade inženjeri za razliku od diplomiranih inženjera“

Sorry, ali ipak ne

Ili, preciznije, ko misli da se netom diplomirani prvostupnik može staviti na takvo radno mjesto, taj će se grdo prevariti! Nakon (barem!) dvije godine praktičnog rada u IT firmi, tijekom kojih se dotični može/treba dokazati (i pritom puuuuno naučiti), možda, odnosno svakako DA. Ali, reći da FER OSPOSOBLJAVA svoje završene B.Sc. studente za obavljanje takvih zadataka je - kako da to „mekano“ kažem – TEŠKO PRETJERIVANJE :-)))) (Editor – baš „mekano“ Zvone, nema što ;-).

Ovdje je na mjestu jedan disklejmer – ovih 300 studenata što sada diplomira (evo, samo što nisu ) – koji god od njih da se odluči na „blesavu“ odluku da NE nastavlja studij – triba ga zgrabiti ! A ako je u najboljih 100, onda ga triba zgrabiti by all means neccessary !

To je ekipa koja je uspješno (i to prva!) prošla kroz „nepoznati teritorij“ na putu ka Bolonji i koji su često i u frenetičnom tempu (ponekad i u promjenjivom „okruženju“) odradili što se od njih tražilo! Star quality material :-). Ne da ih baš sad ODMAH možete baciti na poziciju voditelja projekta :-), ali dok kažeš keks (pogotovo ovi najbolji!) grabiti će naprid koracima od deset milja :-).

Alas, pametni kakvi jesu, većina njih će ipak (naravno!) nastaviti studij dalje

A njihov značaj (i reputacija ) je dodatno potencirana činjenicom da MEĐU NJIMA NEMA PONAVLJAČA !

„Čekaj Zvone, kakvi pobogu ponavljači – toga nema u Bolonji!?“

Ima, naravno da ima :-). To su oni studenti koji ne uspiju od prve dati predmet. A kako na FERu više NEMA ispitnih rokova, nema ni šanse za popravak nego se dogodine predmet mora odslušati ponovo (to je taj „kontinuirani rad“ – kroz cijeli semestar zadaće, kolokviji i na kraju jedan završni ispit ;-).

Stvar za ponavljače nije posve crna, jer, ovisno o preduvjetima, mogu upisivati predmete iz viših godina, tako da kiks na jednom ili dva predmeta ne „stopira“ studiranje, ali svejedno znači jednu godinu više studiranja. Što znači da će dogodine B.Sc. titulu steći oni iz druge generacije koji su sve odradili „iz prve“, ali i oni iz prve generacije koji su jednu godinu „kiksali“. A za dvije godine će se u završnom potu naći zajedno TRI generacije studenata. I tako (skoro pa ad infinitum …

Naravno, Ministarstvo sigurno ima postavljen neki limit, ali uz nedavnu odluku Fakulteta da se dopusti upisivanje istog predmeta PO TREĆI PUT (koja je kao „još samo ove godine“ prilično sam siguran da će biti i B.Sc. inženjera koji će cijelu stvar razvući na 5 godina (a poznavajući naš sustav i mentalitet, i oni „dugovječni(ji)“ će naći svoje mjesto

Zbog toga će se stvari u „ponudi na B.Sc. tržištu“ ponešto promijeniti u odnosu na ovu prvu generaciju (ovdje treba reći da vjerojatno ima i onih koji su zaključili da im je nametnuti tempo prebrz za kvalitetno usvajanje gradiva, pa su namjerno malo „usporili“ i dali sebi jednu godinu više). A kad sistem dođe u stacionarno stanje i kad 50 % (ma 75 %!) najboljih B.Sc. po defaultu ide na M.Sc. studij, a odozdola počnu pridolaziti oni uporni dugoprugaši, kvaliteta B.Sc. inženjera će početi (rapidno!?) opadati.

Zašto !? Odnosno, što im fali ?

U dvi (tri) riči - PRAKTIČNI RAD/ISKUSTVO !!!

Jer, oni ne samo da neće biti za „voditelje malih projekata“, već mnogi od njih neće spadati niti u kategoriju „kvalificirani programer“ !!!

Ovako oštra kvalifikacija svakako zahtijeva pojašnjenje, ali kako sam ovaj post već razdužio više nego što sam mislio, više o tome u sljedećem postu „Samouki programer vs. FERovac“ …

Malo o prethodnom postu …

Dok se priprema novi post o ulozi testiranja u razvoju softvera, bio bi red da se osvrnem i na komentare na prethodni. Jer, desetak zanimljivih komentara svakako zaslužuje osvrt, a kako je blog u smislu komunikacije dvosmjeran, mišljenja sam da je dobro „paziti i maziti“ kolege blogere koji se potrude sudjelovati u njenom inbound smjeru :-).

MasterMind (prvi komentator na ovom blogu !) je u svojim komentarima bila opširna i otvorila vrlo zanimljivu temu – osnovno informatičko obrazovanje! Kako djecu uvesti u čari programiranja je poprilično zanimljivo i važno pitanje. Koje će definitivno dobiti svoj post, a do tada možete (kao i ja) probati malo guglati (npr. „teaching kids programming“ mi je bio dobar starting point!). Jest da sinčina tek treba navršiti 5 godina, ali triba biti spreman (naravno, ako sinčina bude imati volje, a početni znaci su i više nego pozitivni – iako je za sada kompjuter = igra Formula One – vjerojatno zato što imamo i force-feedback volan ;-)).

Druga stvar na koju se osvrće MasterMind je posvemašnja neadekvatnost naših „učitelja“ informatike u osnovnim školama. I BITI ĆE SAMO GORE, ako se obrazovni framework radikalno ne popravi! Ali, to je tema za samostalan post koju će odraditi Zvone Radikalni ;-).

Javio se i BivšiStudent koji je ukazao na problem nekvalitetnog managementa IT projekata. I komentar mogu ocijeniti kao - U SRIDU MAJSTORE :-)! Kronični nedostatak mid-level menadžera u IT industriji je jedan od glavnih razloga zbog kojih IT industrija u Hrvatskoj ne može razviti puni potencijal (kako ja doživljavam tu poziciju, radi se o voditeljima odjela/projekata/timova – znači ljudi na razmeđu čisto tehničkog IT dijela i višeg managementa koji je, jel’te čisto menadžerski – a možda bi to u stvari bio low-level management!?). Što reći, nego da će i problem vođenja softverskih projekata također uskoro dobiti svoj zaseban post. I BivšiStudent je na pravom tragu kad spominje tehnike agilnog programiranja ;-).

CikaVelja je također bio opširan u svom komentaru, a sukus je:

ti se zahtjevi ne mogu predvidjeti, ali se može predvidjeti njihovo postojanje. I besmisleno je analizirati kakvi bi mogli biti (ako su predvidivi treba ih odmah i ukalkulirati), pa projekt treba napraviti tako da teži idealnom a realizirati ga najbolje moguće u danim okolnostima - što znači da je glavna stvar odredti što je realizirani projekt a što nije.

Iliti, od changing requirementsa se NE MOŽE pobjeći :-).

Upravo tako Veljko!

Comrade from the trenches (ali i „ideološki protivnik“ borgman se također javio. Dobrodošao!

A za kraj, i malo šuga, se javio puzz koji je sebi dao truda i napisao kratki osvrt na moj post. U kojem iznosi tezu da je naslov posta pomalo promašen jer „Zašto IT projekti kiksaju“ nije jedinstveno pitanje.

I puzz je apsolutno u pravu :-).

IT projekti mogu kiksati na sto različitih načina, i kao što puzz točno ukazuje, različite vrste softvera imaju i različite glavne faktore rizika. Ali, namjera prethodnog posta nije bila klasificirati SVE moguće razloge kiksanja IT projekata. Namjera je bila osvrnuti se ponajprije na metodološke probleme u razvoju softvera! Ne tehničke (je, IT projekti kiksaju zbog tehnologije), ne financijske (je, nedostatak šoldi ultimativno vodi u kiks), ne motivacijske (je, odlazak lead developera eksponencijalno povećava šanse za kiks), a ne ni human-resources-related (je, ako imaš loše developere, crno ti se piše).

Sve su to mogući razlozi/uzroci kiksanja IT projekata, ali, kao što rekoh, ta pitanja nisu bila u mom fokusu. Daleko od toga da su ona nevažna, ali that was not the point here! Jest da sam mogao i staviti malo bolji/precizniji (i duži!) naslov pa da sve u startu bude jasno, ali u terminima standardne blogovske navlakuše, mislim da i nisam previše zgriješio

Zašto IT projekti (pre)često kiksaju?

Razlog je vrlo jednostavan, i ukratko ga je briljantno sumirao Donald Knuth u predgovoru knjige Scotta Roseberga „Dreaming in Code“:

Software development is hard!

Teško, složeno, komplicirano … koji god hard-sinonim stavite kao pridjev uz razvoj softvera, dobro ste ga stavili. Izvještaji Standish grupe o uspješnosti IT projekata, iako u zadnje vrijeme pokazuju određen pozitivne pomake, ni u kojem slučaju nisu pleasent reading za bilo koga tko se sprema u takvu avanturu, a lista propalih softverskih projekata, čak i ako ćemo se ograničiti samo na one s preko 100.000.000 „uništa“ utučenih dolara, valjda jedva stane na list papira! (evo jednog popisa koji sam pronašao). Od aerodroma u Denveru do FBI-evog Virtual Case sistema … primjera koliko hoćeš.

Zašto je tome tako kad danas svaka šuša zna napraviti web site ili neku jednostavnu aplikaciju za vođenje kafića?

E, upravo je u tome problem! Ili, preciznije rečeno, jedan od problema. Moderna integrirana razvojna okruženja (IDE) naizgled doista omogućavaju vrlo jednostavnu izgradnju čak i složenijih aplikacija a ne bi bilo pretjerano reći da im je to i ultimate driving force!

Definiraj par tablica u bazi, kreiraj konekciju, napravi Windows/Web formu, stavi SqlConnection/DataAdapter/DataReader/DataGrid, Ctrl+F5 i voila … gotovo (ovo je stvar iz Microsoftove perspektive, but you get the point :-).

I ja osobno mislim da je to prekrasno

Jer, kad se sjetim svojih početaka s Commodoreom VC-20 s 3 KB memorije (ali, imao sam „proširenje“ na cijelih 11 Kb!) i kako sam u čistom mašincu (čitaj, ukucavanjem mašinskih kodova u Basicu korištenjem DATA naredbe – nije bilo asemblera!) brljao po video memoriji „grafičke kartice“, na ovo što danas mladac od 13-14 godina može izvesti na PC-ju mogu samo reći – VAU :-).

Ali, ali, ali …

There is a dark side of the story here!

Koja izlazi na vidjelo iznošenjem jednostavne činjenice – nikad više kao u doba dok sam se „igrao“ s mojim Commodorcem neću toliko znati o tehnologiji koju koristim!!! (a doista je zanimljiva koincidencija da nešto slično tvrdi i Coding Horror CAR u svom postu , i btw. ja se s njim potpuno slažem da je car Dijkstra bio u krivu

Onog trenutka kad sam posve ovladao BASICom i mašincem za 6520 procesor (knjiga Dejana Ristanovića “Mašinac za 6520 i Z80″, jednog od careva davnašnjih „Računara“, mi i danas budi jedinstvene osjećaje ;-)), te kad sam nabavio specifikaciju za VC-20 (čitaj, popis i namjenu memorijskih lokacija – što bi danas rekli BIOS) svijet je bio moj.

Od tada pa danas, it was all downhill u borbi s složenošću sofvera!

Naravno, ovdje se mora reći da je to moja osobna percepcija/iskustvo i da sam svjestan da su ljudi dok sam se ja bakćao s video memorijom na VC-20 već gradili prilično složene IT sisteme (mainframe is the catch word here), ali vjerujem da će većini onih koji imaju bar 10-godišnje iskustvo u razvoju softvera biti jasno o čemu pričam. Tipična „aristotelovska“ priča – ne znam da li bih taj vremenski trenutak stavio u 40-te ili 50-te, ali prilično sam siguran da je davno bilo kad je netko mogao reći da „zna sve što se o kompjuterima ima znati“.

I, da se vratimo na ulogu modernih IDE sistema, u skrivanju te sve veće kompleksnosti IDE vendori su odradili vraški posao, a odrađuju ga i dalje (jel se ko sjeća Turbo Pascala, ili možda Visual Studia 6.0? – ma da sjećam, održavam još i danas ;-).

Ali, problem je što je ta složenost ipak „samo“ skrivena! Ona je i dalje tu, i pomalja svoju ružnu glavu svaki put kad u nekoj third-party biblioteci ili komponenti (ili samom IDE okruženju!) iskoči bug, ili kad ju koristite na način na koji developeri koji su je pisali nisu računali. Kako je danas svakome jasno da potpuni in-house razvoj nije kredibilna opcija (za iole složeniji IT sistem) situacija može biti/postati prilično pipava.

Ipak, savladavanje složenosti nije nepremostiv problem, kao što cjelokupni dosadašnji razvoj ljudske civilizacije zorno ilustrira! Od Space Shuttlea do najnovijeg Airbusa (iako će netko ovdje sigurno primjetiti da su to dva odlična primjera kako složenost ljudi ipak nisu do kraja nadvladali grade se sve složeniji sustavi. Nažalost, softver je u tom fajtu sa složenošću suočen s jednim dodatnim problemom, od kojeg ne pate ostale inženjerske discipline s kojima se razvoj softvera često uspoređuje, a to je problem mijenjajućih zahtjeva (iliti na engleskom, a i bolje zvuči, changing requirements)!

Da bi posve shvatili s kakvim su calamityjem ovdje developeri softvera suočeni, povući ću paralelu s građevinom - područjem s kojim se izgradnja softvera često „analogizira“ (građevinari grade fizički, softveraši virtualno pa to valjda nekako „dođe na slično“).

Zamislite, na primjer, da Vas kao uspješnog poduzetnika i vlasnika građevinske firme, kontaktira naručitelj koji želi da mu sagradite fensi-šmensi neboder od 20 katova. Ništa lakše – nađe se arhitekt koji napravi turbo-gtx-injection dizajn, koriste se sve redom najmoderniji materijali, pazi se na energetsku efikasnost, naprave se nacrti i gradnja kreće. Sve se odvija po planu (dobro, ne baš, ali zadnjih dva mjeseca će se raditi i nedjeljom pa će se nekako stići), katovi se polako nizaju i svijet je u ružičastim bojama.

I onda jednog dana dolazi naručitelj i kaže:“Slušaj, znam da sam rekao da nam garaža neće trebati jer sam računao da ćemo iskoristiti ovo zemljište pored za parking, ali sad su se stvari promijenile i treba napraviti i garažu za par sto auta ispod nebodera“!

Što mislite, da li je ikad iti jedan građevinac dobio takav zahtjev od svog naručitelja?

Možda i jest, u nekoj specifičnoj situaciji and with lots of money to throw around, ali sam prilično siguran da bi reakcija svakog građevinca danas u Hrvatskoj bila ????????? Radi se naprosto o toliko očigledno glupoj ideji da vjerojatno nikome to ne bi palo napamet ni pitati!

Nažalost, kao što to vrlo dobro svaki developer zna, takvi zahtjevi su manje više normalna stvar prilikom razvoja softvera. (a izvrstan primjer klasičnog nerazumijevanja pogledajte ovdje).

„Ma to ti je samo dodati jedan gumbić na formu, ukucaš malo koda i to ti je to – ja ti to u dBaseu isprogramiram za jedno popodne“ (ovo je ako ste imali sreće pa za menadžera imali nekoga ko je u životu imao bar malo doticaja s programiranjem

Manje više svatko zna da građevina mora imati temelje i da jednom kad si svoj neboder „utemeljio“ i na tom temelju izgradio 10-ak katova, ići graditi garažu ako i nije nemoguće definitivno nije nešto na što bi se čovjek išao odlučiti laka srca.

A u softveru? Nema problema: „Pa to su sve samo neke điđe miđe po ekranu – nema tu tona i tona betona, čelika i zemlje za prevrnuti“. Na što je moj jedini komentar - što bi programeri dali da su stvari koje oni „prevrću“ prilikom udovoljavanja željama naručitelja tako jednostavne kao beton, čelik ili zemlja!

Jer, kako građevinac zna da nema smisla graditi garažu ispod već napola izgrađenog nebodera? Odgovor je jasan – građevinska statika je prilično uznapredovala znanost i prilično dobro će ukazati na sve probleme koje u izvođenju takvog poduhvata treba riješiti.

Zašto tako ne bi moglo i sa softverom?

E zato jer kod softvera ima na desetke, stotine i tisuće različitih „prijedloga za garažu“ koji se mogu smisliti, odnosno s kojima naručitelj može banuti pred developera! Stvar je još i gora zato jer je posve nerealno očekivati da se sve potencijalne „garaže“ unaprijed mogu identificirati (što bi Rumsfeld rekao, to su „unknown unknowns“ – btw. to je, barem po mom mišljenju jedan od najpodcjenjenijih komentara u povijesti – koliko je zbog toga ridikuliziranja čovjek proživio a rekao je briljantnu istinu, koja je istovremeno i očigledna na način na koji samo briljantne istine mogu biti očigledne ;-). A da ne spominjemo beskonačno šire mogućnosti INTERAKCIJE među različitim dijelovima softverskih sustava (u odnosu na klasičnu građevinu)!

Jer, kad se nešto (fizički) gradi tijek je manje više poznat – nosiva konstrukcija, pregrade, instalacije i na kraju unutrašnje uređenje, i, što je u ovoj priči još i važnije, svaki element se može proračunati i prilično dobro definirati kako interagira s ostalim dijelovima cjeline. Rezultat takvog procesa je da se u konačnici većina izgrađenih konstrukcija vrlo malo (ako i ikako!) razlikuje od nacrta po kojem su napravljeni!

A Vi mi pokažite softverski sistem za koji vrijedi to isto (a da nije napravljen za američko ministarstvo obrane

Waterfall način razvoja je prošlost, a svi oni projekti koji počnu „napraviti ćemo to i to (gdje je „to i to“ definirano u otprilike par rečenica!) za 2,3 ili 5 godina i to će koštati 10,50 ili 100 tisuća/milijuna kuna“ su naprosto osuđeni na neuspjeh (gdje razina neuspjeha može biti različita – od potpunog neuspjeha i odustajanja od projekta pa do različitih nivoa probijanja budžeta i time-framea za izvedbu projekta).

Razlog tome je vrlo jednostavan – ne postoji softverski developer/dizajner/arhitekt koji za sistem koji ima više od 10, 20 ili 50 tisuća linija programskog koda može unaprijed predvidjeti sve tehničke začkoljice/probleme koji će se pojaviti, i što je još važnije, naknadne zahtjeve naručitelja koji će iskrsnuti prilikom izgradnje sistema. Takvog jednostavno nema, a ko vam kaže da je on taj, ili laže ili nema pojma (a vi se odlučite koaj od te dvije opcije je „bolja“ ;-). Naravno, ovdje je bitno pripomenuti da gornja izjava vrijedi ukoliko imate „normalan“ budžet za razvoj svog softvera! Ako imate godišnje na raspolaganju 500 milijardi dolara koliko ima Pentagon, onda možete sebi priuštiti 10,20 ili 50 analitičara/dizajnera/arhitekata koji će doista detaljno proroštati problem!

Za sve nas ostale smrtnike ostaje činjenica da je promjena u zahtjevima naručitelja neminovna i osnovno pitanje kod razvoja svakog softvera je kako se prilagoditi toj činjenici. Lamentacije tipa „zašto se ti naručitelji konačno više ne odluče što žele“ su u biti kontraproduktivne i esencijalno pogrešne!

Pogrešne zato što upravo u mogućnosti promjene leži najveća snaga softvera kao takvog! Jer, bilo da do promjene dolazi zbog naknadne pameti naručitelja, bilo da do nje dolazi zbog promjene poslovnih prilika na tržištu i pojavljivanja nove business opportunity, promjena je „dobra“ zato što rezultira, odnosno može/treba rezultirati, poboljšanjem softvera i generiranjem većeg profita od njegove izrade.

Ono što softver u osnovi razlikuje od građevine je što pruža neograničene mogućnosti isprobavanja i testiranja! A kako testiranje može pomoći u savladavanju “promjenjive prirode” softvera, u jednom od sljedećih postova …

Za početak …

Eh, ovo mi je već treći početak, a kako su završila prva dva možete pogledati na http://cppbilder.blog.hr.

Ipak, mislim (nadam se da će biti po onoj treća sreća. Nakon dvogodišnjeg iskustva bloganja o politici i razno raznim stvarima (vidi http://zvoneradikal.blog.hr)  došlo je vrijeme da se uhvatim “pravog posla”. I da počnem pisati o stvarima kojima se bavim već 20 godina i u koje se stvarno “kužim” ;-).

Lekciju sam naučio u prethodna dva pokušaja tako da ovdje neće biti silnih najava o tome koje ću teme obrađivati, već ću samo reći da će naglasak biti na principima OO dizajna (s posebnim naglaskom na domain driven design tehnikama/principima), test driven development će se isto često spominjati, a što se tiče tehnologija, naglasak će biti na .NETu uz ponešto C++a, for the sake of good old times