Big ball of mud, skraćeno: BBoM je zadnjih tjedana često spominjana tema na programerskim forumima i blogovima. Što je zapravo BBoM?
Postoje dvije definicije, jedna pozitivna, jedna negativna. Joel Moses, računalni znanstvenik kojem se pripisuje da je izmislio taj pojam rekao je:
APL (programski jezik, op.a.) je poput prekrasnog dijamanta - savršen, prekrasno simetričan. Ali ne možete mu ništa dodati. Ako na dijamant pokušate zalijepiti drugi dijamant, nećete dobiti jedan, veći dijamant. Lisp, s druge strane, je poput grude blata. Dodajte još i opet će izgledati kao gruda blata - izgledat će kao Lisp.
Jel Moses poriče da je to ikad izrekao, on tvrdi da je Lisp usporedio s vrećom graha jer se uvijek vraća u svoj izvorni oblik. Kako god bilo, pojam BBoM je tu i aktivno se koristi. Ova definicija bi bila pozitivna definicija jer je u kontekstu programskih jezika pozitivno ako vašem omiljenom programskom jeziku možet dodati konstrukte koji će vam olakšati rješavanje vašeg trenutnog problema a da ti konstrukti i daju osjećaj dobre integriranosti s ostatkom jezika.
Negativna definicija pojma je ona zbog koje se ovaj pojam danas sve češće spominje (prenosim na izvornom jeziku jer je teško kvalitetno prevesti bez da se izgubi značenje):
A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, spaghetti-code jungle. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated. The overall structure of the system may never have been well defined. If it was, it may have eroded beyond recognition. Programmers with a shred of architectural sensibility shun these quagmires. Only those who are unconcerned about architecture, and, perhaps, are comfortable with the inertia of the day-to-day chore of patching the holes in these failing dikes, are content to work on such systems. People who maintain such systems, are often seen wearing socks and sandals.
(Joseph Yoder, 1999.)
Na programerskim blogovima zadnjih dana počela se pojavljivati teorija da je ova pojava u današnjim uvjetima jednostavno neizbježna. Ako na početku nekog projekta i postoje pokušaji da se dizajn sustava planira unaprijed, da se sa promijenjenim zahtjevima planski refaktorira i da se održava kohezija, s vremenom ljudi popuste pred rokovima i raznim pritiscima i počnu primjenjivati trikove. Rezultat je sustav koji se može opisati kao: mala, mala dijamantna jezgra u sredini velike grude blata.
Po mojem iskustvu ovaj opis je potpuno točna slika trenutnog stanja u informatičkoj industriji. Do sad sam bio samo na jednom većem projektu gdje smo plan proveli do kraja i originalnu arhitekturu nismo pretvorili u nekakvo mutirano čudovište. Jedan od razloga je možda i taj što se originalni zahtjevi nisu mijenjali za vrijeme razvoja projekta, a nakon završetka se zbog političkih razloga proizvod nikad nije niti koristio pa nam klijent nikad nije davao zahtjeve za promjenama koje bi sigurno imao da je pokušao u praksi koristiti svoju novu igračku koju smo mu napravili.
Danas popularne agilne metodologije izrade softvera su možda uzrok da BBoM dizajn softvera nastaje u svojem izvornom obliku, bez da prolazi kroz ovaj proces degradacije od dijamanta ka grudi blata. Prisjetimo se, glavni princip Agile metodologija je "zadovoljiti klijenta brzom i kontinuiranom isporukom vrijednog softvera". Svi se slažemo da je ovo dobar koncept ali po mojem iskustvu pojmovi "vrijedan softver" i "kvalitetan softver" su samo riječi u tekstu ponude koja se dostavlja potencijalnom klijentu.
Tu svaka veza s tim pojmovima prestaje i preostaju dva glavna kriterija: da softver ispunjuje zadane zahtjeve i da je isporučen na vrijeme. Kako se dođe do tog rezultata ljude koji su prodali izradu projekta a i same klijente uopće ne zanima. Kvaliteta se dešava magično bez utroška vremena i jedina mjera utroška vremena je vrijeme koje je potrebno je da se fizički utipka sav tekst koda i korisničkih uputa. Softver se izjednačava s fizičkim proizvodom koji se sklapa na traci i pakira u kutije. I tu se zaboravlja da je i za fizički proizvod trebalo proći neko vrijeme za razvoj, izrade prototipa, testiranje… U informatičkoj industriji prvi prototip za koji se pokaže da ispunjava zadane kriterije automatski u očima managera postaje gotov proizvod kojeg samo još treba zapakirati.
Ideja iterativnog razvoja ovdje pada u vodu jer klijentu zapravo ne smijete pokazati vaš prototip sustava. U idealnom svijetu klijent bi trebao napraviti neko osnovno testiranje i vama se vratiti s komentarima poput: "da, ali mi smo zamislili da se ova funkcionalnost zapravo izvršava obrnutim redoslijedom" a ono što najčešće dobijete je: "da da, dobro, samo mi još ovdje promijeni boju i na ovom mjestu mi povećaj font". Znači, prototip kojeg ste zbrzali tek toliko da se drži skupa i da demonstrira vaš pristup rješavanju problema se krivo precipira kao skoro završen proizvod kojem treba još samo par kozmetičkih izmjena.
Možda sam u ovom opisu malo pretjerao ali često je osjećaj upravo ovakav. Volio bih znati postoji li netko u našoj industriji tko je radio ili radi na projektima gdje je kvaliteta prvi kriterij? Postoje li (posebno u Hrvatskoj) Agile timovi koji su imali vremena za kvalitetan refaktoring jednom kad su već isporučili npr. 80 posto sustava? Postoje li Agile timovi koji su radili proizvode koje sami kasnije održavaju?
Ispucao sam danas par svojih frustracija ali volio bih čuti i druga mišljenja o ovoj temi.
| Igor Rumiha nezavisni je konzultant koji se u svojoj IT karijeri od 2000. godine do danas bavio izradom sustava za mrežni nadzor, provisioning sustavima u ISP i mobile telekom okolinama i automatizacije testova na embedded platformama. U pauzama između tih poslova bavio se administracijom Oracle i MSSQL baza, billing sustava pa čak i izradom billing sustava. |
