Sistem, ki še dela in se ga nihče noče dotakniti. Najprej preberemo kodo.
Star informacijski sistem redko kar odpove, le varno spreminjati ga ni več mogoče: razvijalec, ki ga je razumel, je odšel, ogrodja proizvajalec ne podpira več, vsak popravek pa nastane na slepo, ker regresije ne bi ujelo nič.
Kaj pomeni prenova informacijskega sistema
Sistemi, ki pridejo k nam, so si podobni: ostarela tehnologija, včasih različica ogrodja, za katero proizvajalec že leta ne izdaja popravkov, včasih sistem, ki ga je mogoče zgraditi le še na tistem enem računalniku, ki je zanj še nastavljen. Poslovna logika živi v shranjenih procedurah, v opravilu cron, za katero se nihče ne spomni, kdo ga je napisal, ali v glavi enega razvijalca. Testov ni, zato je vsaka sprememba stava, ne gotovost. Nič od tega ne pomeni, da je informacijski sistem slab. Marsikateri tak sistem vsak dan poganja pravo podjetje. Pomeni le, da je tvegano spreminjanje, ne delovanje.
Začnemo z branjem, ne s pisanjem na novo. Obstoječi sistem zaženemo, preberemo kodo, se pogovorimo s tistimi, ki ga še uporabljajo, in zapišemo, kaj dejansko počne, vključno s pravili, ki niso bila nikoli dokumentirana, ker so se avtorju takrat zdela samoumevna. Nato napišemo karakterizacijske teste, ki to obstoječe vedenje zaklenejo. Tako lahko trditev „nova različica še vedno dela to, kar je delala stara“ dokažemo in nam ni treba upati, da bo razliko ujelo testiranje pred izdajo. Šele potem se začne zamenjava, običajno po vzorcu strangler fig: novi sistem gradimo ob starem in promet selimo del za delom, na vsaki stopnji pa obstaja delujoča pot nazaj na prejšnje stanje, namesto ene same noči preklopa, ki ali uspe ali ne.
Pravo tveganje pri tem delu ni v očitnih 90 % sistema, temveč v pravilu, ki se sproži le ob enem točno določenem pogoju: izjema pri popustu, ki je bila v kodo zapisana zaradi pogodbe, potekle pred leti, in je nihče ni odstranil, ali pravilo zaokroževanja, ki obstaja zaradi ugotovitve davčnega nadzora izpred mnogih let. Prepis, narejen samo po specifikaciji, ponovi vidno vedenje, taka pravila pa izpusti. Na dan pridejo šele po zagonu, ko pokliče tista ena stranka, ki je bila od njih odvisna. Ker sistem najprej preberemo, jih ujamemo, dokler je popravek še poceni.
Kaj dobite
Pisni opis tega, kaj sistem dejansko počne
Vključno z nedokumentiranimi pravili, ki jih najdemo z branjem kode in zagonom sistema, ne s sklepanjem po specifikaciji, ki nikoli ni bila točna.
Karakterizacijski testi, ki zaklenejo obstoječe vedenje
Napisani pred prvo spremembo, da regresijo ujamejo testi, preden jo najde stranka.
Pot migracije s točko vrnitve na vsaki stopnji
Strangler fig ali preklop po fazah, izbran glede na to, ali si sistem lahko privošči izpad, ne pa ena sama izdaja, ki zamenja vse naenkrat.
Prenovljen sistem
Aktualno ogrodje, podprte odvisnosti in gradnja, ki uspe na več kot enem računalniku.
Testi, s katerimi so prihodnje spremembe varne
Stara različica jih običajno ni imela. Z njimi naslednja sprememba ni spet stava.
Migracija podatkov, kadar se menja tudi podatkovna shramba
Usklajena z migracijo kode. Kadar gre za samostojno delo, glejte migracijo podatkov.
Dokumentacija tega, kar nas je presenetilo
Da tisti, ki pride za nami, izjeme pri popustu ne odkriva znova na lastni koži.
Predana izvorna koda, cevovod za gradnjo in postopek namestitve
Ponovljivo brez nas.
Kdaj je prenova smiselna in kdaj ne
Kdaj je smiselna
- Sistem dela, a ga nihče od trenutno zaposlenih ne zna varno spremeniti, in vsak popravek je stava.
- Tehnologije proizvajalec ne podpira več, ali pa je edini računalnik, na katerem se sistem še da zgraditi, že sam po sebi enojna točka odpovedi.
- Poslovna pravila obstajajo samo v kodi ali v glavi enega človeka, njegov odhod pa je realno tveganje.
- Potrebujete funkcionalnost ali integracijo, ki je obstoječa arhitektura ne zmore, ne da bi nekaj pod njo napisali na novo.
- Zahteva glede skladnosti ali pogodba s stranko terja podprto tehnologijo, za katero še izhajajo popravki, vaša trenutna pa to ni.
Kdaj ne
- Sistem sam zase dela dobro, edina prava težava je, da se z njim ne more povezati noben drug sistem. To je integracija prek API, ki je običajno cenejša in jo je vredno poskusiti pred pisanjem na novo.
- Logika aplikacije je v redu, zamenjati je treba le mesto, kjer so shranjeni podatki. To je samostojna migracija podatkov.
- Sistem bi radi napisali na novo, ker je koda stara, ne zato, ker bi povzročala resnično težavo. Staro in delujoče ni pokvarjeno, proračun pa je bolje porabiti tam, kjer vas nekaj res stane.
- Sistema trenutno nihče sploh ne more zagnati: izvorna koda je izgubljena, okolje ne obstaja več in ni ničesar, kar bi lahko prebrali. To je bližje gradnji na novo kot prenovi, in to vam bomo povedali, namesto da bi vam zaračunali obratni inženiring nečesa, česar ni več.
Kako poteka
- 01
Preberemo, zaženemo in se pogovorimo s tistimi, ki sistem še uporabljajo
Preden predlagamo, kaj se spremeni, da načrt izhaja iz tega, kaj sistem dejansko počne.
- 02
Napišemo karakterizacijske teste
Po obstoječem vedenju, da je trditev „še vedno dela to, kar je delal“ dokazljiva in ne le predpostavljena.
- 03
Izberemo pot migracije
Strangler fig za sistem, ki si izpada ne sme privoščiti, preklop po fazah tam, kjer je vzdrževalno okno sprejemljivo.
- 04
Gradimo in selimo promet del za delom
S točko vrnitve na vsaki stopnji, namesto enega preklopa, ki ali uspe ali ne.
- 05
Predamo prenovljen sistem
Skupaj s testi in dokumentacijo tega, kar se je izkazalo za pomembno.
Vprašanja, ki jih slišimo
Ali pri prenovi informacijskega sistema vedno pišete vse na novo?
Ne, pisanje na novo je običajno napačna prva poteza. Večina teh projektov potrebuje popravek peščice konkretnih stvari in gradnjo, ki jo je mogoče zanesljivo ponoviti. Celoten prepis je zadnja možnost, ne privzeta izbira: zanj se odločimo, ko arhitektura sama ne zdrži spremembe, ki jo potrebujete.
Kaj pa, če dokumentacije sploh ni?
To je običajno in ni ovira. Kodo preberemo, jo zaženemo in sproti zapisujemo, kaj dejansko počne. Manjkajoča dokumentacija je razlog, da to delo sploh obstaja, ne razlog, da se ne bi moglo začeti.
Ali lahko novi sistem med prenovo teče ob starem?
Običajno da, to je vzorec strangler fig: zamenjavo gradimo ob izvirniku in promet selimo postopoma, ne z enim samim preklopom, zato na vsaki stopnji obstaja delujoča pot nazaj.
Ali boste pri tem posegali v naše podatke?
Samo če se v okviru prenove menja tudi podatkovna shramba. V tem primeru to načrtujemo in izvedemo kot ločen korak. Kako tako delo zastavimo, kadar je samostojen projekt, je opisano pri migraciji podatkov.
Newsletter
Novice iz delavnice
Zapisi o tem, kako načrtujemo, gradimo in dostavljamo programsko opremo. Brez kampanj, brez avtomatiziranih nizov sporočil, odjavite pa se lahko z enim klikom.
Imate sistem, ki se ga nihče noče dotakniti?
Povejte nam, kaj sistem počne in zakaj se vam zdi spreminjanje tvegano. Inženir prebere kodo, preden karkoli predlaga, in prvo, kar dobite nazaj, je to, kaj bi se pokvarilo, če bi se sistema kdo dotaknil.