Kort fortalt – vi tok over en applikasjon med monolittisk arkitektur, og med den arvet vi teknisk gjeld som skapte problemer i hvert steg av utviklingen. Dette er en ganske vanlig situasjon og et velkjent tema i IT-verdenen, men jeg tenkte å skrive noen ord om hvordan vi gikk frem, uten å ha mye erfaring med slike prosjekter.
Et prosjekt som er over et dusin år gammelt, som fortsatt husker WinForms og alle versjoner av MVC, det utdaterte .NET Framework, Knockoutjs eller jQuery-biblioteket. Nysgjerrig? Jeg inviterer deg til å lese videre, hvor jeg tar deg, kjære leser, med på et eventyr som du har vært, er eller vil være en del av (hvis du har valgt denne spennende veien som programmerer, selvfølgelig). For å spare deg tid vil jeg spesifisere punktene jeg ønsker å gå nærmere inn på:
1.Brownfield-prosjekt – eller hvorfor det etter min mening er bedre å starte med denne typen prosjekt.
2. Akillessenen i en legacy-applikasjon. Faktisk vil det være flere av dem.
3. Inkrementell refaktorering – altså hvordan gjennomføre en revolusjon i arkitekturen, samtidig som risikoen for feil reduseres.
1. Brownfield-prosjekt
I det første punktet ønsker jeg å berøre ett aspekt som ofte undervurderes i denne typen prosjekter – nemlig historiske data. I motsetning til de etterlengtede og drømte greenfield-prosjektene, har vi her fordelen av å ha informasjon om hvordan brukerne benytter applikasjonen vår. Dette gir oss en stor mengde kunnskap som vi kan bruke til å gjenoppbygge og optimalisere prosessene i systemet. Den andre fordelen er at en applikasjon som er «varmet opp» i produksjon er et modent produkt som har blitt utviklet sammen med forretningen i mange år. Forretningskunnskap, eller forretningskrav, er ikke alltid klare i starten av utviklingen av en applikasjon eller ny funksjonalitet. Avhengig av typen prosjekt må vi velge riktig tilnærming. I vårt tilfelle hadde vi en god start fordi vi hadde historisk informasjon som hjalp oss med å få applikasjonen på riktig spor. For unge team er dette en flott mulighet til å lære grunnleggende programmering og kunsten å samle inn og behandle data. Kunnskap om konkrete use cases gjør det enklere å ta arkitektoniske beslutninger. Kanskje det kommer en ny anledning til å skrive noen ord om den andre typen prosjekter – greenfield-prosjekter og Lean Startup-tilnærmingen.
2. Akillessenen.
Applikasjonen vår hadde flere utilgivelige svakheter når det gjaldt bred programvareutvikling og moderne cloud native-trender. En av dem var den allestedsnærværende og allvitende bruken av session og cache. Mitt råd? Hvis du ser en implementert session og et API som kommuniserer med frontend, og du ikke kan gjøre noe med det: Løp! Halvt spøk, halvt alvor. Cache og session skapte mange problemer for oss og førte ofte til behov for dyp debugging. Det finnes også fordeler – vi lærte hvordan vi skulle debugge og ble veldig godt kjent med miljøet vårt – Rider. Hvordan komme seg ut av en slik situasjon uten å låse seg inne i kjelleren i flere år for å skrive applikasjonen på nytt? Vår tilnærming var å systematisk persistere «sessions» til databasen. På slutten av denne delen vil jeg anbefale å investere i å utvide kunnskapen din om Design-driven development, og spesielt temaet bounded contexts. Vår legacy inkluderte to applikasjoner som, fra et forretningsperspektiv, hadde lite eller ingenting med hverandre å gjøre. En slik sammenslåing av to applikasjoner i én løsning viser enten utviklernes latskap, mangel på kompetanse eller korte tidsfrister. Oppsummert – hvis du ønsker å levere programvare av høy kvalitet, trenger du tid til å gjøre det.
3. Inkrementell refaktorering.
Personlig er jeg ikke en tilhenger av å skrive applikasjoner på nytt fra bunnen av. I vårt tilfelle var det umulig på grunn av at applikasjonen var i bruk og vi hadde begrensede ressurser. På den andre siden tror jeg på smidig programmering, som gjør det mulig å levere noe som gir verdi til forretningen på relativt kort tid. Vi startet med å analysere systemet og kalle den tekniske gjelden ved navn. Vi estimerte at det i et pessimistisk scenario ville ta oss omtrent ett år å få applikasjonen på rett spor. For meg var det «no go». Inspirert av boken Lean Startup bestemte vi oss for å lage MVP av de funksjonene som brukes mest av brukerne. På 3 måneder leverte vi en SPA-applikasjon skrevet i React. Selvfølgelig måtte vi pådra oss teknisk gjeld, som inkluderte suboptimale spørringer (N+1-problemet), bruk av et «anti-corruption layer» og noen ekstra «work-arounds». Bevisste på gjelden vi hadde, betalte vi den systematisk ned i hver eneste iterasjon.
Vår reise er ennå ikke over, men vi beveger oss konsekvent mot målet. Kort sagt, men jeg håper jeg har inspirert deg, kjære leser, til ikke å miste motivasjonen dersom du arver en applikasjon som viser seg å være en «Big ball of mud». Hvordan du tilnærmer deg denne typen prosjekter vil vitne om din modenhet som programmerer.
Piotr Czyż
@_piotr
