Velika prepisivanja su spora, rizična i skupa. Davilica omogućava da staru aplikaciju postepeno zamenimo novom.
Postojeće aplikacije mogu biti bitne firmama iz niza razloga: donose novac, pružaju bitne usluge korisnicima, interni korisnici bez njih ne mogu da rade svoj posao itd. Kada se suočimo sa potrebom da ih prepišemo taj posao može biti prilično izazovan, jer imamo već izgrađene potrebe koje ne možemo tek tako da odabcimo.
Jedna opcija je da jednostavno napišemo novu verziju aplikacije i zamenimo staru u trenutku kada je sve spremno. Koliko god prosto zvučalo u osnovi, ovaj pristup je često jako skup, komplikovan i nepraktičan u praksi. Postojeće aplikacije umeju biti jako obimne jer su se godinam razvijale, a veliki deo tih mogućnosti mora da se prenese u novu. To može biti veliki posao, bez da i ulazimo u razvoj novih mogućnosti zbog kojih verovatno i pravimo novu verziju.
Sa tako velikim brojem mogućnosti dolazi i veliki rizik od pojave bagova i stabilnosti sistema, lansiranje novog rešenja može biti veliki tehnički izazov, prebacivanje korisnika može vući sa sobom veliki posao oko obuke i privremeni pad produktivnosti dok se naviknu na novi sistem, itd. Često se ovakvi projekti napuste, a u situacijama kada se završe često budu ”marševi smrti” sa ogromnim troškovima i negativnim posledicama na moral razvojnih timova.
Umesto da se ide na dug i skup razvoj novog rešenja koje će od jednom zameniti staro rešenje, možemo da smanjimo rizik tako što ćemo novo rešenje razvijati oko starog i postepeno menjati funkcije starog novim. Jedan dobro dokumentovan i čest način da se ovo izvede je davilica (strangler fig), koji je dobio ime po drvetu koje raste tako da postepeno uguši i zameni drvo domaćina. Počnimo odatle.
Poreklo imena
Ficus Aurea je jedna od više tipova fikusa “davilica” koje su razvile zanimljivu strategiju za preživljavanje. Za razliku od većine drveća, koja svoj život započinju iz tla, davilice svoj život počinju u krošnji drugog drveća. Tlo kišne šume nije najgostoljubivije mesto za mlado drveće, jer tu vlada oskudica svetlosti i puno biljaka je u konkurenciju za vodu i hranljive materije. Zato davilice ne kreću odatle, već iz krošnji.
Ptice i sisari pojedu plod davilice i kroz njihov izmet seme završi u šupljinama i na granama drugog drveća, gde proklija. Davilica u početku raste polako, pušta niz tankih korenih žila koje se ili spuštaju niz stablo drveta domaćina ili prosto vise sa njegovih grana. Kada te žile napokon dođu u kontakt sa tlom, davilica se ukoreni i kreće sa brzim rastom, obavijajući domaćina i nadmećući se sa njim sve dok mu ne uskrati svetlost i hranljive materije do te mere da drvo domaćin ugine.
Na mestu domaćina davilica nastavi da raste, kao pravo, samostalno drvo, nekad dosežiću visinu i do 30 metara. Često davilice u sredini svog stabla imaju šupljinu kao podsetnik gde je nekada stajalo drvo domaći.
Ficus aurea (Florida strangler fig) (fotograf: James St. John)
Davilica u praksi
Proces zamene stare aplikacije radimo u više koraka. U početku imamo samo staru aplikaciju. Prvi korak je da krenemo da pravimo novu aplikaciju i da razvijemo nešto što će korisnicima biti od koristi. To može biti unapređena verzija postojeće mogućnosti ili nova mogućnost koja je dosta tražena. Kada imamo neku zaokruženu celinu u novoj aplikaciji, između dve verzije aplikacija i korisnika postavljamo mehanizam za rutiranje koje će korisnicima usluživati staru aplikaciju za sve osim za nove funkcionalnosti:
Nakon što ovo rešimo i korisnicima pustimo kombinaciju stare i nove aplikacije, krećemo sa daljim razvojem nove aplikacije. Sa svakom novom stvari dodatom u novu aplikaciju ili dodajemo nove mogućnosti korisnicima ili možemo da izbacimo deo funkcionalnosti iz stare. Ovaj postupak ponavljamo sve dok nove aplikacija u poptunosti ne pokrije funkcionalnosti stare, kada možemo da uklonimo deo za rutiranje i obrišemo staru aplikaciju:
Prednosti i mane
Kao i svaki pristup u softverskom razvoju, davilica dolazi sa nizom prednosi, ali sa sobom nosi i niz mana. Prednosti i mane je najbolje gledati u odnosu na drugi pristup. Ono sa čime bih poredio pristup zamene u koracima je zamena cele aplikacije, gde staru aplikacija menjamo novom tek kada je nova gotova i spremna. Da je ”spremna” obično znači da su napravljene funkcionalnosti koje stara aplikacija ima, korisnici koriste i bez kojih ne mogu, plus nove mogućnosti koje želimo da imamo prvog dana nakon lansiranja.
Prednosti
Smanjen finansijski rizik. Finansijski rizik kod dugog prepisivanja je najprisutniji na dva fronta: trošak samog razvoja i trošak toga što kao firma ne koristimo nove mogućnosti zbog kojih smo verovatno i ušli u prepisivanje.
Davilica ne rešava prvi, jer prepisivanje i dalje košta, ali značajno smanjuje ovaj drugi, jer firma može da ima koristi od novih mogućnosti dosta ranije.
Manja šansa za veliku najezdu bagova. Što je veća aplikacija, to je veća i mogućnost da će nas u prvim danima nakon puštanja polaviti velika količina bagova. Koliko god da se trudili da isporučimo sistem bez problema, neke stvari se otkriju tek kada korisnici počnu da koriste aplikacija za svakodnevni posao i sa stvarnim podacima.
Davilica nije mehanizam za sprečavanje pojave bagova, ali posao ispravke raspoređuje kroz vreme. Kako se koja celina završi i pusti, tako se nađu i bagovi koji su promakli razvojnom timu u toj celini i poprave. Umesto jednog velikog cunamija, imamo niz manjih talasa.
Smanjen operativni rizik. Onog dana kada se pusti nova aplikacija, ona gotovo trenutno dođe pod “puno opterećenje” - tu su svi korisnici, sa svim svojim različitim scenarijima korišćenja i podacima. Operativni problemi mogu da se pojave kroz preopterećen sistem, gde će delovi instrastrukture da pokleknu pod optrećenjem ili neoptimizovanim rešenjem.
Davilica pomaže tako što se infrastrukturni problemi rešavaju postopeno. U početku nova aplikacija radi vrlo malo toga, tako da su i potrebe korisnika od nje male. Zbog toga rani problemi sa infrastrukturom nemaju veliki negativan efekat na korisnike i rad firme. Kako vreme prolazi i mogućnosti se dodaju, tako može da se poboljšava infrastruktura i operativne karakteristike nove aplikacije. Kada na kraju dođemo do potpune zamene stare aplikacije novom, veliki deo infrasturkturnih i stabilnosnih problema je davno rešen.
Lagano uvođenje korisnika u novi sistem. Prelazak sa starog na novi sistem može biti popriličan šok za korisnike i njihovu produktivnost, posebno ako se korisnički interfejs novog i starog sistema puno razlikuju. Ako dodamo tome moguće bagove i moguću nestabilnost ili sporost novog sistema u ranim fazama, celo lansiranje može biti poprilično frustrirajuće uz veliki pad produktivnosti.
Davilica rešava ovaj problem tako što korisnike lagano učimo novom sistemu. U početku imaju vrlo malo toga u novoj aplikaciji da nauče i koriste, a onda lagano uče nove stvari kako se one dodaju.
Mogućnost da se uz prepisivanje postojećih dodaju i nove mogućnosti. U prepisivanje stare aplikacije ulazimo iz mnogih razloga, a jedan od njih je da korisnicima pružimo nove mogućnosti. Kada se ide na puštenja tek kada je nova aplikacija spremna, korisnici za nove mogućnosti treba da čekaju tek kada je cela aplikacija gotova i puštena.
Davilica omogućava da se uz prepisivanje prave i nove mogućnosti jer je stara aplikacija uvek tu da pokrive stara scenarija. Pošto se međusobno nadopunjuju, sve vreme imamo funkcionalnosti starog sistema, plus nove mogućnosti dodate kroz novi sistem.
Manji rizik od otkazivanja prepisivanja. Kada na prepisivanje aplikacije gledamo van razvojnog tipa, kao korisnik, menadžer kome ta aplikacija treba ili investitor, mi celu stvar vidimo kao jedan veliki prioritet. Moramo da završimo prepisivanje da bismo mogli X. Prioritetizacija posla se tu dešava, ali isključivo u okviru razvoju tima, jer ostalima malo znači da li je tim uzeo da radi na ovome ili onome kada moraju da čekaju celu stvar da bude gotova.
U ovoj postavci imamo problem zato što ljudi spolja možda izgube strpljenje i zatraže da se napusti rad na prepisivanju i nove mogućnosti dodaju u staru aplikaciju. Ili jednostavno odustanu od njih skroz, na štetu firme koja bi od tih mogućnosti mogla imati korist.
Davilica menja postavku i omogućava da se uključi više ljudi u razgovor o tome šta je bitno, jer bitne stvari mogu imati pred sobom i pre nego što je celo prepisivanje gotovo. Što više ljudi je uključeno u razgovor i ima rane koristi od prepisivanja, manji je rizik da se taj projekat otkaže.
Mane
Dodatna kompleksnost. Puštanje dve aplikacije jedne pored druge, da rade u tandemu, dolazi sa nizom tehničkih izazova. Sam sloj za rutiranje zahteva između dva sistema i omogućavanje da podaci teku između njih može da predstavlja popriličan tehnički izazov.
Sav taj kod će biti u potpunosti odbačen kada nova aplikacija zameni staru i na firmi i timu je da proceni da li se to ulaganje isplati.
Lošije korisničko iskustvo. Rad sa dve različite verzije aplikacije u istom okruženju dolazi sa nizom kompromisa i padom korisničkog iskustva. Rešenje je neujednačeno i razlike u interfejsu i ponašanju mogu biti takve da zbunjuju korisnike. Za aplikacije koje firma koristi interno ovo verovatno nije problem, ali za aplikacije koje se takmiče na otvorenom tržištu neujednačeno korisničko iskustvo može biti jedna od stvari koja će korisnike prevagnuti na stranu konkurenta.
Nove mogućnosti mogu biti ograničene postojanjem starog sistema. U situaciji kada oba sistema koriste iste podatke, format u kome su ti podaci i pravila kako su ti podaci uređeni mogu da uslovljavaju šta nova aplikacija može, a šta ne može da radi sa njima.
Kada stvari tako stoje, nekada je potrebno izmeniti staru aplikaciju da bi podaci bili u obliku koji novoj aplikaciji trebaju za neke nove mogućnosti. To ili diže trošak razvoja ili dovodi tim u situaciju da te mogućnosti odlaže za trenutke kada stara aplikacija više ne bude u upotrebi. Ni prvi ni drugi pristup nisu idealni, već su kompromis sa kojim firma i tim treba da se suoče.
Arhitektura može značajno da uveća kompleksnost. Ukoliko imamo monolitnu aplikaciju, sloj za rutiranje i povezivanja podataka je tipično samo jedan. Ukoliko radimo sa više servisa, broj sistema za rutiranje i premošćavanje se povećava.
Ovolika kompleksnost može da bude uzrok problema i nestabilnosti. Praćenje svih izmena i staranje da sistem radi kako treba postaje posao sam za sebe, što ume da produži i poskupi projekat prepisivanja.
Komfor može da dovede do naduvavanja obima posla (scope creep). Jednom kada se namesti da rutiranje radi i korisnici se naviknu da koriste dva sistema, davilica počinje da pruža izvestan komfor. Više nema pritiska koji “sve ili ništa“ pristup nosi. Ovo samo po sebi nije loša stvar, ali može dovesti do toga da se dodaje puno novih mogućnosti na novoj strani aplikacije i sam proces zamene dva sistema odlaže.
Tim treba da se ima na umu razloge zašto je u celu stvar krenuo i da zna da im je i dalje jedan od glavnim ciljeva da staru aplikaciju izbaci iz igre.
Korak dalje
Gore je opisana davilica u svom najčešćem obliku, koji su ljudi iz industrije često koristili i za koji ima više studija slučaja. Ako odemo korak dalje, možemo naći još dosta različitih pristupa kako u koracima zameni staru aplikaciju novom, za koje ne možemo reći da su baš davilica, ali koji dele niz njenih osobina i mogu biti korisne u različitim okolnostima.
Na primer, možete napraviti dva frontenda iste aplikacije koja dele zajednički bekend i rutirati korisnike između te dve verzije u zavisnosti od toga koja funkcionalnost im treba. Nešto slično smo radili kada smo pravili ActiveCollab 8. Umesto da se korisnik automatski rutira između starih i novih delova aplikacije, oni sami odlučuju da nešto žele da urade u novoj verziji i odlaze u nju, a stara je tu da pokrije mogućnosti koje u novoj još uvek nisu dostupne.
Dijalog koji vodi korisnike iz stare u novu ActiveCollab verziju
U duhu prave biljke davilice, novu aplikaciju možete napraviti kao okvir koji će unutar sebe učitavati stvari iz stare aplikacije koje nemate završene (iframe npr). U tom slučaju nova aplikacija nosi nove funkcionalnosti i ujedno služi i za rutiranje korisnika na stare funkcionalnosti:
Obrnut pristup tome bi bilo da unutar stare aplikacije pravite elemente nove kao “ostrva” funkcionalnosti:
Ovaj pristup smo koristili pre nego što smo počeli da pravimo ActiveCollab 8. U početku smo unutar stare Angular 1.x aplikacije nove funkcionalnosti razvijali kao React komponente. Kada je rad na verziji 8 zvanično počeo, krenuli smo tako što smo napravili potpuno novu React aplikaciju i u nju preneli sve React komponente i funkcionalnosti koje smo već imali gotove.
Ukoliko vas ne zanima zamena cele aplikacije, već samo delova unutar postojeće, razmislite o grananju kroz apsotraciju. Na to se može gledati kao na jedanu od primena davilice, samo na puno nižem nivou:
Pre koda koji želimo da zamenimo dodamo sloj apstrakcije i onda deo obrade prebacimo sa stare na novu implementaciju, dok nova nije spremna da u potpunosti zameni staru. To rutiranje kasnije možemo izbaciti, kada se pokaže da je nova funkcionalnost stabilna, ali se može desiti da moramo i da ga zadržimo.
Nije redak slučaj kod aplikacija koje se dugo koriste da imate korisnike ili naloge kod kojih iz istorijskih razloga nešto treba da radi na stari način, dok kod novih korisnika nemate taj zahtev. Kod za rutiranje može da odluči da za stare korisnike uvek koristi staru implementaciju, a za nove novu prostom proverom da li taj korisnik ima stare podatke ili ne.
Zaključak
Davilica je poznat i dobro dokumentovan pristup prepisivanju važnih aplikacija na način da se smanji niz finasijskih, tehničkih i operativnih rizika, da se korisnicima pruže nove mogućnosti ranije, bez gubitka starih i da se isti lagano uvedu u novu aplikaciju.
Ovakav pristup je skoro pa idealan za interne aplikacije. Tu firme imaju puno veće šanse da naiđu na razumevanja kod korisnika dok su u opticaju dve verzije aplikacija, često sa različitim dizajnom, korisničkim iskustvom itd.
Ukoliko se softver nudi na tržištu i korisnici ga plaćaju, to razumevanje je puno manje i tu davilica može biti problematična. Jedna od njenih odlika je da pruža stabilnost i donekle komfor da se proces prepisivanja produži, što proizvodima koji su na tržištu može da bude medveđa usluga. Korisnicima se na tržištu nudi niz mogućnosti i mogu da se opredele da pređu na alat koji ima ujednačeno korisničko iskustvo, umesto našeg gde je iskustvo neujednačno jer rade sa dve verzije aplikacije.
Firma treba dobro da izvaže davilicu naspram pisanja potpuno nove aplikacije. Iako sa nizom rizika, čistiji pristup novoj verziji dugoročno može biti bolji po proizvod jer tim ima priliku da pravi proizvod kakav misli da je potreban korisnicima i tržištu, na način na koji misli da to treba da se uradi, umesto da svoje odluke od starta “venčava” sa starom verzijom i pravi niz kompromisa.
Iako nije idelno rešenje za sve prilike, davilica je pristup sa kojim je dobro biti upoznat jer može biti koristan za mnoge projekte. Smanjenje više tipova rizika koji često ugrožavaju napore oko prepisivanja aplikacija, kao i mogućnost da korisnicima ponudimo nove mogućnosti mnogo pre nego što je nova verzija gotova čine davilicu opcijom koju ne treba ignorisati kada se potegne pitanje prepisivanja bitnih aplikacija.
Reference
Blue Planet Biomes: Strangler fig
Martin Fowler: Strangler fig application
Paul Hammant: Strangler application (studija slučaja)
Microsoft Architecture Center: Strangler fig pattern
…