"Programinės įrangos kūrimui kasmet
išleidžiami milžiniški pinigai ir tokia sukurta intelektinė nuosavybė įmonių
balanse apskaitoma kaip nematerialus turtas. Deja, realybė dažnai negailestinga
- labai brangių specialistų sukurta sistema ima reikalauti vis didesnių
palaikymo biudžetų, kiekvienas naujas funkcionalumas reikalauja vis ilgesnių
terminų, o pardavimai skundžiasi, jog atsilieka nuo konkurentų. Balansinis
nematerialusis „turtas” paaiškėja besąs faktine juodąja skyle su nuolat
augančiomis aptarnavimo išlaidomis.
Negana to, programuotojai dėl
neaiškių priežasčių išeina iš darbo, o pasamdyti lygiaverčių specialistų
nebepavyksta. Tiek CTO, tiek HR paaiškina: nebegalime pasamdyti gerų
programuotojų, nes mūsų programinis kodas yra legacy.
Kas
yra tas legacy programinis kodas?
Programuotojų žargonu legacy
vadinamas beviltiškai pasenęs projektas, kuriam sunku pridėti naujo
funkcionalumo, taisyti defektus, atnaujinti komponentus ir, iš esmės, sunku
produktyviai dirbti. Dažnai vartojamas sinonimas yra „spagečių kodas”, t. y.
supainiota, sunkiai suvokiama, nebeatpinama raizgalynė. Legacy turi stipriai
neigiamą prasmę.
Tačiau kodėl vos prieš porą metų
pradėtas projektas, kuris dar kaip reikiant neišvydo saulės šviesos, jau
laikomas pasenusiu? Kodėl „moralinė senatvė“ ištiko produktą, kurį brangūs
specialistai kūrė naujausių technologijų pagrindu? Išoriškai mūsų produktas
atrodo neblogai, atlieka savo darbą ir netgi susilaukia klientų atsiliepimų, o
kažkoks nematomas puvinys įsimetęs į tūkstančius kodo eilučių, ir dar taip
sunkiai paveikė visą mūsų sistemą, jog menkiausio naujo patobulinimo tenka
laukti mėnesių mėnesius, ir visuomet pasipila erzinančios klaidos.
Trumpai atsakant į šį klausimą:
sąlyginai lengva įvertinti materialaus daikto kokybę (tiesiog
apžiūrėjus), o nematerialiam produktui reikalingas išsamus techninis auditas.
Skubėdami programuotojai „nukerta kampus”, t.y. sukuria norimą funkcionalumą
greituoju būdu, o neesminių defektų ima kauptis dešimtimis, šimtais ir galop
tūkstančiais. Tačiau išoriškai, neaudituojant paties programinio kodo, tokių
higieninių trūkumų pastebėti neįmanoma. Jų kumuliacinis efektas užsakovams
paaiškėja daug vėliau.
Ar programinis kodas yra trumpo
galiojimo produktas tiesiog iš prigimties? Jokiu būdu.
Nemažai programinių produktų,
sukurtų prieš keliolika ar net keliasdešimt metų, vis dar yra nepriekaištingos
kokybės - tiek funkcionalumo, tiek kodo kokybės požiūriu. Akivaizdu, jog
programuotojai skyrė daug pastangų veikiantį kodą paversti pridėtine verte.
Kaip
žinoti, ar turite programinio kodo higienos problemą?
Jeigu jūsų įmonė turi savo
individualią programinę įrangą, greičiausiai jis didele dalimi yra legacy.
Yra tam tikri simptomai, pagal kuriuos galima nuspėti vidinės kokybės
„sveikatos” lygį.
Visų pirma, paklauskite savo
programuotojų vieno skaičiaus - kodo aprėpties (angl. code coverage). Anot
Michael Feathers, visas kodas yra legacy ta apimtimi, kiek jis nėra
padengtas modulių testais (vidiniais kokybės testais). Kad ir kaip neįtikėtinai
tai skambėtų, visiškai šviežias, šiandien rašomas kodas išsyk virsta atgyvena,
jei tik jis neturi išsamių modulių testų. Jeigu jūsų programuotojai negali
atsakyti į šį klausimą, arba jei pateiktas skaičius mažesnis nei 60-80%,
programinis kodas tikrai turi problemų.
Antra, pasitelkite įrankius. Kodo
higienines problemas gali (ir turi) skaičiuoti statinės analizės įrankiai. Jie
gana apytiksliai pasako, kiek programuotojo dienų, mėnesių ar metų reikės
sutvarkyti programinį kodą iki standartinio kokybės lygio.
Na ir trečia, pasiklauskite savo
pardavėjų komandos - ar atsiradus naujiems verslo poreikiams, programinė įranga
sugeba pasikeisti? Pridėti papildomą ataskaitą, papildomą langelį, papildomą
mygtuką ar dar vieną integraciją negali trukti daugiau laiko nei praėjusį
kartą: lėtėjantis modifikacijos greitis byloja apie projektines-architektūrines
problemas.
Apibendrinus, ką matuojame, tą ir
gauname. Jeigu programuotojai neturi vidinės kokybės tikslų, tai jos bus tiek,
kiek profesinės ir asmeninės disciplinos turi kiekvienas inžinierius. Kuomet
projektų vadovas spaudžia greičiau kurti funkcionalumą, o ilgalaikius tikslus
ignoruoja - vidinės kokybės tikėtis neverta.
Problemos
mastas privačiame ir viešajame sektoriuose
Kalbant apie programinio kodo
kokybę, įdomu atsiminti valstybinio sektoriaus IT pirkimus. Valstybinės
institucijos (ne vien Lietuvoje) kasmet išleidžia įspūdingas sumas programinei
įrangai kurti, tačiau viešųjų pirkimų sąlygose dažniausiai nekalbama apie
kuriamo kodo vidinę kokybę. Brangios IT sistemos atlieka visas funkcijas,
aprašytas funkciniuose reikalavimuose, o ir funkcionalumo klaidos išgaudytos,
tačiau niekas nekreipė dėmesio vidinei kodo ir architektūros kokybei. Nauji
rangovai siūlys sistemą perrašyti iš naujo, arba labai brangias palaikymo
paslaugas.
Privataus sektoriaus bėdos, jokiu
būdu, nėra mažesnės. Jaunas verslas žūtbūt siekia išlikti ir įsitvirtinti, ir
apie ateities problemas tiesiog neturi laiko galvoti - higienai nebelieka nei
laiko, nei biudžeto. Tačiau net ir didelės, solidžios organizacijos susiduria
su tokia pačia problema, nes jos paprastai turi didelį, nuosavų IT sprendimų
portfelį ir aukštus ketvirtinius pelningumo tikslus, todėl, geriausiu atveju,
biudžetus gali skirti vien tik svarbiausiems, strateginiams produktams
tvarkyti.
Tarp
palaikymo ir perkūrimo
Įprastai, organizacijos tokiose
situacijose dažniausiai mato du pasirinkimus ir abu jie yra skaudūs.
Pirmasis sprendimas - „paliatyvinė
slauga”, t.y. projekto palaikymas bet kokia kaina. Be abejo, nekokybiškas kodas
reiškia, jog nebespėjame kurti būtino funkcionalumo, nesugebame kamšyti saugumo
skylių, prarandame klientus ir rinkos dalį. Taip pat, tampa sunku prisivilioti
programuotojų - palaikymo kainos ima griauti visus finansinius planus.
Antrasis būdas yra perrašyti visą
pasenusį sprendimą iš pagrindų. Tai yra įmanoma, tačiau labai brangu: toks
perrašymas reiškia didelius kaštus - dažniausiai nuo pusės iki dviejų metų
darbo. Perrašymas neišvengiamai reiškia verslo plėtros stagnaciją, nes naujų
funkcijų nebus iki naujosios versijos užbaigimo. Naujoji versija, greičiausiai,
nebeturės daugybės senojo (pamiršto) funkcionalumo, reikės brangaus duomenų ir
klientų migravimo. Deja, naujosios versijos kokybė nėra garantuota.
Inžinerine
prasme, trečiasis kelias - sudėtingiausias
Dar vieną sprendimo būdą galima
vaizdžiai prilyginti su važiuojančio automobilio remontu. Tai - tikslingas
laipsniškas sistemos modernizavimas.
Programinės įrangos modernizavimas -
sudėtinga IT inžinerijos sritis, kurios pradžia galime laikyti Martino Fowlerio
straipsnį, apžvelgusį tuo metu programuotojų bendruomenės sukauptą patirtį ir
modernizacijos receptus. Nuo M. Fowlerio straipsnio publikavimo, programinės
įrangos modernizavimo metodologija labai sparčiai vystėsi, atsirado gerųjų
praktikų, architektūrinių sprendimų ir specializuotų įrankių.
Trumpai tariant, reikalinga labai
nuodugni strategija, suderinanti verslo prioritetus su technologiniu vystymo
planu. Abi platformos - naujoji ir senoji - egzistuoja vienu metu, šalia viena
kitos, tik naujoji platforma iš pradžių turi labai mažą viso funkcionalumo
dalį. Iš senosios platformos funkcionalumas palaipsniui migruojamas į naująją
(kokybišką) platformą. Pareto principas teigia, jog 20% kodo slepia 80% visų
defektų (arba 80% jūsų klientų naudojasi vos 20% viso funkcionalumo), todėl
tinkamais įrankiais diagnozuojant „skausmo taškus” ir tinkamai tokias
problemines sritis prioretizuojant, naujoji platformos versija labai greitai
perima esmines senosios versijos funkcijas. Tai, jokiu būdu, nereiškia, jog
apsiribojame greitais daliniais sprendimais. Netgi priešingai - ilgainiui į
naują platformą persikels visiškai visas dabartinis funkcionalumas ir prisidės
visos naujosios funkcijos. Tiesiog naująja platforma galima bus naudotis labai
anksti, lygiagrečiai su senąja, nelaukiant pilno perrašymo užbaigimo - pagal
verslo poreikių ir technologinių reikalavimų konsensusą.
Jeigu senoji platforma labai
atsilikusi nuo modernių technologijų, vieno žingsnio migracija gali būti
neįmanoma - jums gali reikėti pereinamosios architektūros. Duomenų
sinchronizavimas, skirtingų platformų integracija ir tarpusavio suderinamumas,
esamo funkcionalumo skaidymas ir perkėlimas bei daugybė kitų techninių iššūkių
reikalauja aukštos kvalifikacijos programinės įrangos inžinierių, specifinių
įrankių ir profesionalių procesų. Tačiau deramai modernizuojant verslui
kritiškai svarbias sistemas, funkcionalumo vystymasis nesustoja, o kodo kokybė
visą laiką sparčiai gerėja. Verslas išvengia rizikų, susijusių su „paliatyvinės
slaugos” arba pilno perrašymo atvejais.
Iš mano patirties, slaptasis sėkmės
ingredientas modernizuojant dideles sistemas yra... personalo strategija.
Kiekvieno komandos nario asmeninės ambicijos, karjeros siekiai ir technologinės
preferencijos yra tokie pat svarbūs faktoriai, kaip ir tinkami įrankiai ar
procesai. Modernizacijos projektas yra rimta misija, kurios skirtinguose
etapuose reikalinga skirtinga komandos sudėtis.
Pranešimo spaudai autorius: twoday
padalinio Lietuvoje vadovas, sertifikuotas programinės įrangos architektas ir
sertifikuotas Java programuotojas Mantas Urbonas.
twoday yra apie 2700 ekspertų
vienijanti IT įmonė Šiaurės Europoje ir Lietuvoje, kuri teikia programinės
įrangos kūrimo, programinės įrangos modernizavimo, duomenų analitikos ir
dirbtinio intelekto sprendimus daugiau nei 8000 privataus ir viešojo sektoriaus
klientų."
Komentarų nėra:
Rašyti komentarą