Modernizavimo planas paruoštas, biudžetas preliminariai patvirtintas. Rangovas užduoda pirmą klausimą: „Kur sistemos dokumentacija?“. Paaiškėja, kad yra wiki, paskutinį kartą atnaujinta prieš penkerius metus, keli brėžiniai „kažkur tinkliniame diske“ ir kodas, kuris pats sau atstoja dokumentaciją. Sąmata išauga trečdaliu. Nes rangovas įkainoja ne darbą, o neapibrėžtumą.
Šis tekstas aprašo praktiką, kuri tą neapibrėžtumą nuima nuo stalo: prieš kam nors paliečiant senos aplikacijos kodą, atkuriamos žinios apie ją. Dar neseniai toks etapas reiškė savaites analitiko darbo ir mažai kas jo imdavosi. Šiandien DI didžiąją šios analizės dalį atlieka per darbo dienas. Ir tai keičia viso projekto eiliškumą.
Pirmiausia žemėlapis, paskui kodas
Sistemos modernizavimas be aktualios dokumentacijos primena pastato remontą be instaliacijų plano. Įmanoma, bet kiekvienas sienos ardymas yra loterija: gal už jos nieko nėra, o gal vamzdis, nuo kurio priklauso pusė aukšto. Aplikacijose tuo vamzdžiu būna integracija su duomenų saugykla, kurią prisiminė tik kodo autorius, arba naktinis eksportas, kuriuo tyliai naudojasi buhalterija.
Todėl protingas eiliškumas yra priešingas intuityviam. Pradedama ne nuo naujo kodo rašymo ir net ne nuo sąmatos. Pradedama nuo žemėlapio.
Ką DI ištraukia iš kodo, bazės ir žurnalų
Šiuolaikiniai analizės įrankiai moka perskaityti tris tiesos apie sistemą šaltinius: išeities kodą, duomenų bazės struktūrą ir produkcinės veiklos žurnalus. Juos sukryžminus gimsta sistemos žemėlapis, apimantis keturis sluoksnius.
Pirmasis sluoksnis yra moduliai: iš ko sistema susideda ir už ką atsako kiekvienas fragmentas, aprašyta kalba, suprantama ir ne IT žmonėms. Antrasis yra duomenų srautai: iš kur duomenys ateina, kas su jais vyksta pakeliui, kur jie nusėda. Trečiasis apima integracijas, tai yra visas vietas, kuriose aplikacija kalbasi su kitomis sistemomis: buhalterija, sandėliu, parduotuve, partneriais. Būtent jos dažniausiai lūžta keičiant sistemą.
Ketvirtasis sluoksnis mažiausiai akivaizdus: negyvas kodas. Žurnalų analizė parodo, kurios funkcijos nebuvo iškviestos metų metus ir į kurias lenteles niekas nerašo nuo 2019 metų. Senesnėse sistemose toks balastas dažnai sudaro nemažą visumos dalį. Kiekviena eilutė, kurios nereikia perkelti, yra reali projekto ekonomija.
Ką žemėlapis keičia sprendime „perrašyti ar modernizuoti“
Apie patį sprendimą rašėme atskirai, tekste apie keturis kriterijus: sprendimų karkasas. Sistemos žemėlapis šiems kriterijams duoda kietus duomenis. Be jo technologinė skola vertinama iš nuojautos, o rizika pagal anekdotus. Su juo juodu ant balto matyti: kurie moduliai neša verslo vertę, kurie negyvi, kur sėdi integracijos, didinančios kiekvieno pakeitimo riziką.
Rezultatai būna netikėti į abi puses. Kartais sistema, kurią „reikia perrašyti nuo nulio“, pasirodo trimis ketvirtadaliais sveika ir užtenka pakeisti du modulius. Kartais atvirkščiai: aplikacija atrodo nekaltai, o žemėlapis atskleidžia keliolika nedokumentuotų jungčių, dėl kurių dalinis modernizavimas tampa brangesnis už perrašymą. Abiem atvejais sprendimas priimamas remiantis duomenimis, ne emocijomis. O rangovas, gaunantis žemėlapį vietoj mįslės, įkainoja darbą, o ne riziką.
Mūsų nuomone, žemėlapio atkūrimas turėtų būti atskiras, pirmasis modernizavimo sutarties etapas su savo priėmimo aktu. Net jei po šio etapo nuspręsite, kad modernizavimą darys kas kitas arba nedarysite jo visai, dokumentacija lieka įmonėje ir dirba toliau.
Kaip patikrinti tai, ką sugeneravo DI
Automatiškai sugeneruota dokumentacija nėra orakulas. Ją reikia patikrinti. Veiksmingiausias metodas paprastas: peržiūra su žmogumi, kuris sistemą pažįsta geriausiai, dažnai vieninteliu tokiu įmonėje. Skirtumas nuo klasikinio požiūrio yra šio žmogaus vaidmuo. Neprašote jo surašyti žinių, ko niekas nemėgsta ir kas tęsiasi mėnesius. Prašote recenzuoti paruoštą aprašą, o nurodyti „čia sutampa, čia ne“ yra daug kartų greičiau nei rašyti nuo nulio.
Gera praktika yra pereiti kelis svarbiausius procesus nuo pradžios iki galo: užsakymą, sąskaitą, reklamaciją. Jei žemėlapis teisingai aprašo kritinius srautus ir atrankinai patikrintas detales, juo galima pasitikėti ir likusiose srityse. Tai įmanoma padaryti per dieną.
Ko DI neatkurs
Čia sąžininga išlyga: kodas sako, ką sistema daro, bet nesako, kam. Keista nuolaidos skaičiavimo išimtis gali būti klaida, o gali būti 2016 metų prekybinis susitarimas, vis dar galiojantis vienam dideliam klientui. To jokia kodo analizė neišspręs. Dešimtmečio senumo verslo intencijos atkuriamos interviu: trumpais pokalbiais su pardavimo, buhalterijos ir operacijų žmonėmis, vedamais jau su žemėlapiu rankoje. Žemėlapis pakiša, ko klausti, bet atsakymus turi žmogus.
Atskira tema yra ir aplikacijos aplinka: serveriai, tinklas, atsarginės kopijos. Apie šio sluoksnio dokumentavimą rašėme tekste apie infrastruktūros dokumentacijos auditą.
ESKOM AI žemėlapio sudarymo etapą vykdo specializuotų DI agentų komanda, prižiūrima patyrusių inžinierių: tipinės įmonės sistemos analizė trunka darbo dienas, o rezultatas yra dokumentacija, suprantama ir valdybai, ir techninei komandai. Jei po jos priimamas sprendimas modernizuoti, tolesni darbai vyksta automatizuotame programinės įrangos kūrimo procese su visa testų apimtimi — vienetų, integracinių, E2E, sąsajos, saugumo ir našumo.
Nuo ko pradėti pas save
Pasirinkite vieną sistemą: tą, kurios modernizavimą atidėliojate ilgiausiai arba kurios labiausiai bijote paliesti. Užsakykite jos žemėlapio atkūrimą kaip savarankišką, nedidelį etapą, prieš prašydami ko nors perstatymo sąmatos. Nemokamos konsultacijos metu patarsime, kaip tokį etapą suplanuoti ir ko po jo tikėtis.
Užsisakykite nemokamą konsultaciją per kontaktų formą →