Sistema keista ne be priežasties

Prie komandos prisijungia naujas inžinierius ir susiduria su nepažįstama sistema. Architektūra atrodo pasenusi, o keli sprendimai visiškai neatitinka to, kaip jis tokią sistemą kurtų šiandien.

Paprastai netrunka atsirasti pasiūlymui viską pakeisti švaresniu sprendimu. Sistema per sudėtinga, jos ribos neteisingos, technologijos senos. Nauja architektūra būtų lengviau suprantama ir geriau pasiruošusi ateičiai.

Toks pasiūlymas dažniausiai pristatomas kaip techninis patobulinimas. Kartais taip ir yra. Tačiau kartais tikroji priežastis daug paprastesnė: perkurti sistemą patraukliau nei skirti laiko jai suprasti.

Naujas sprendimas visada atrodo švarus, nes dar nesusidūrė su realybe.

Santechnikas, norintis perstatyti jūsų butą

Įsivaizduokite, kad jūsų bute pradeda varvėti čiaupas. Iškviečiate santechniką ir tikitės, kad jis apžiūrės čiaupą, pakeis susidėvėjusią detalę ir paliks jį veikiantį.

Vietoje to santechnikas paaiškina, kad visa vamzdynų sistema pasenusi. Jis siūlo pakeisti visus vamzdžius, perkelti vonios kambarį, atverti kelias sienas ir sumontuoti modernius įrenginius, apie kuriuos neseniai mokėsi. Tuo pačiu vamzdyną būtų galima padalyti į kelias savarankiškai prižiūrimas dalis.

Daugumai mūsų tai būtų aiškus pavojaus signalas. Paklaustume, kaip varvantis čiaupas virto viso buto rekonstrukcija, suabejotume kaina bei nepatogumais ir tikriausiai išsikviestume kitą santechniką.

Programinės įrangos kūrime panašaus masto pasiūlymai vertinami visiškai rimtai. Vietinė problema tampa įrodymu, kad reikia perrašyti visą programą. Sudėtingas diegimas virsta platformos iniciatyva. Nepatogi riba tampa priežastimi skaidyti sistemą į paslaugas. Siūlomas sprendimas gerokai perauga pradinę problemą, tačiau organizacija vis tiek suburia darbo grupę jam nagrinėti.

Programinėje įrangoje rekonstrukcija atrodo pigi

Fizinės rekonstrukcijos kaina matoma iš karto: medžiagos, leidimai, išgriautos sienos ir kasdieniai nepatogumai. Programinė įranga sukuria pavojingą iliuziją, nes kodas neturi akivaizdžios medžiagų kainos. Gali pasirodyti, kad pakanka paskirti kelis inžinierius ir palaukti keletą mėnesių.

Tačiau programinės įrangos perrašymas neprasideda nuo nulio. Jis prasideda nuo daugybės metų elgsenos, kurią reikia iš naujo atrasti ir atkurti.

Tikroji kaina apima nedokumentuotas taisykles, duomenų migravimą, lygiagretų dviejų sistemų veikimą, integracijas, veiklos procedūras ir elgseną, nuo kurios tyliai priklauso klientai. Šios išlaidos išryškėja tada, kai naujoji sistema susiduria su ta pačia realybe, dėl kurios senoji tapo sudėtinga.

Esama sistema atrodo netvarkinga, nes visi jos kompromisai jau matomi. Siūloma sistema atrodo elegantiška, nes daugumos jos kompromisų dar niekas neatrado.

Veikianti programinė įranga nusipelno pagarbos

Programinės įrangos inžinieriai metų metus kartoja dvi frazes:

“If it works, don’t touch it.”

“Working software is good software.”

Nė viena iš jų nėra teisinga visais atvejais. Programinė įranga gali veikti, bet būti nesaugi, nepakeliamai brangi arba nebegalėti palaikyti tolesnių verslo poreikių. Atsisakyti bet kokio pakeitimo nėra inžinerinė disciplina – kartais tai tiesiog baimė.

Vis dėlto abi frazės perduoda svarbų perspėjimą. Veikianti programinė įranga jau susidūrė su tikrais klientais, duomenimis, gedimais, integracijomis ir organizaciniais apribojimais, kurių joks architektūros pasiūlymas negali iki galo atkartoti.

Tai nereiškia, kad jos negalima liesti. Tai reiškia, kad ji yra įrodymas.

Prieš atsisakydami veikiančios sistemos turime paaiškinti, ką laimėsime ir kuo rizikuosime. „Naujas sprendimas bus švaresnis“ nepakanka. Švara be konteksto dažnai tėra problemos nesupratimas.

Keistame kode gali slypėti pamirštos žinios

Daugelį metų veikiančios sistemos kaupia ne tik techninę skolą. Jos kaupia sprendimus.

Tikrinimo taisyklė gali egzistuoti todėl, kad išorinė sistema kadaise atsiuntė sugadintus duomenis. Besidubliuojanti darbo eiga gali atspindėti skirtingas sutarties sąlygas. Keistas laukas gali išlaikyti suderinamumą, o ne vietoje atrodanti riba – atspindėti atsakomybę už sistemos veikimą.

Kai kurie iš šių sprendimų gali būti nebeaktualūs. Kiti galbūt niekada nebuvo geri. Tačiau vien perskaitę kodą ir pastebėję, kad patys būtume jį parašę kitaip, skirtumo nesužinosime.

Per daug tobulinimo pasiūlymų kiekvieną esamą apribojimą iš karto laiko klaida. Komanda pašalina nepatogias dalis jų neištyrusi, o vėliau sužino, kad būtent tas nepatogumas saugojo svarbią informaciją.

Brandžios sistemos nelaiko visų žinių viename dokumente. Jos išbarstytos kode, testuose, duomenyse, palaikymo procedūrose, klientų lūkesčiuose ir sistemą prižiūrinčių žmonių atmintyje.

Perrašydami tokią sistemą keičiame ne vien technologiją. Bandome perkelti organizacijos atmintį iš formos, kurios iki galo nesuprantame, į dar neišbandytą sprendimą.

Naujos pradžios patrauklumas

Priežiūrai reikia nuolankumo. Inžinierius turi įžengti į kitų žmonių sukurtą sistemą, pripažinti, kad daugelio sprendimų priežastys nėra akivaizdžios, ir pirmiausia skirti laiko mokymuisi.

Perrašymas siūlo patrauklesnį vaidmenį. Užuot tyrinėjęs esamą sistemą, inžinierius tampa naujosios architektu. Jo mėgstami modeliai tampa standartu, o jo vardas susiejamas su matomu pokyčiu.

Tai nereiškia, kad kiekvienas perrašymas yra sąmoningas pripažinimo siekis. Paskata subtilesnė: organizacijos daug garsiau švenčia paleidimus ir naujas platformas nei dar vienus stabilaus veikimo metus.

Priežiūros pakeitimas gali užkirsti kelią problemai, kurios niekas niekada nepastebės. Perrašymas sukuria diagramas, planus ir naujas repozitorijas. Vienas atrodo kaip smulki užduotis. Kitas – kaip pažanga.

Šis skirtumas veikia mūsų sprendimus. Asmeninis pasirinkimas tampa architektūros principu. Nepatogumas skaitant svetimą kodą tampa įrodymu, kad jo neįmanoma prižiūrėti. Noras dirbti su naujesne technologija pavirsta verslo argumentu apie būsimą mastelį.

Galiausiai mintis „aš taip nekurčiau“ tyliai virsta teiginiu „šios sistemos neturėtų būti“.

Kartais perkurti yra teisinga

Kai kurias sistemas reikia pakeisti. Perrašymas gali būti pagrįstas, kai sistema nebegali patenkinti svarbių poreikių, jos technologijos nebepalaikomos, saugumo rizikos negalima pašalinti saugiai arba prasmingi pakeitimai tapo nepagrįstai brangūs.

Skirtumas tas, kad pagrįstas perrašymas prasideda nuo įrodytos problemos, o ne estetinio nusivylimo. Jis paaiškina, kodėl laipsniško tobulinimo nepakanka, ir palygina visą pakeitimo kainą su tolesniu esamos sistemos vystymu.

Atsakingame pasiūlyme migravimas yra architektūros dalis. Jame numatyta, kaip judės duomenys ir integracijos, kaip bus lyginama elgsena ir kaip pokyčio metu veiks abi sistemos. Nebūtina išsaugoti kiekvieno istorinio sprendimo, tačiau prieš pašalinant svarbią elgseną reikia ją suprasti.

Perrašymas neturėtų būti pabėgimas nuo sudėtingumo. Tai turi būti apgalvotas atsakas į sudėtingumą, kurį suprantame pakankamai gerai, kad galėtume keisti.

Prieš patvirtinant rekonstrukciją

Dideliems kodo pertvarkymams ir perrašymams neužtenka pažadų apie švaresnį kodą bei greitesnį kūrimą. Prieš atveriant sienas komanda turi atsakyti:

• Kokią išmatuojamą problemą sprendžiame?
• Ar galime ją pagerinti palaipsniui?
• Kuriuos esamus apribojimus patikrinome, o kuriuos tik numanome?
• Kokią elgseną naujoji sistema privalo išsaugoti?
• Ar vertinimas apima migravimą, lygiagretų veikimą, veiklos žinių kaupimą ir senosios sistemos išjungimą?
• Ar vis dar palaikytume šį pasiūlymą, jei nuopelnai už jo įgyvendinimą atitektų kitam?

Paskutinis klausimas gali būti nepatogus. Jei dingus pripažinimui pasiūlymas tampa mažiau patrauklus, problema gali būti ne vien techninė.

Programinę įrangą reikia keisti tada, kai to reikalauja problema, o pakeisti visą sistemą – kai įrodymai rodo, kad tai geriau už tolesnį jos vystymą.

Tačiau nesupratimas nėra įrodymas, modernumas nėra verslo rezultatas, o ambicija nėra architektūros strategija.

Prieš perstatydami butą sutaisykite čiaupą – arba bent jau supraskite, kodėl vamzdžiai nutiesti būtent ten.