Vecas rūpnieciskās lietotnes refaktorēšana — kad tā ir pamatota un kā to veikt, neradot risku ražošanai?

Kāpēc šī tēma šodien ir svarīga

Vecas rūpnieciskas lietotnes refaktorēšana vairs nav koda estētikas vai uzturēšanas ērtuma jautājums. Šodien tas ir lēmums par ražošanas nepārtrauktību, izmaksu prognozējamību un sistēmas īpašnieka atbildības robežām. Daudzos uzņēmumos vadības lietotnes, operatoru rīki un komunikācijas slāņi gadiem ilgi ir attīstīti bez vienotas, saskaņotas arhitektūras, bieži balstoties uz iekārtām, bibliotēkām un integrācijas mehānismiem, kuru atbalsts ir ierobežots vai jau beidzies. Šādu situāciju kādu laiku vēl var pieņemt, bet tikai līdz brīdim, kad katra nākamā izmaiņa sāk izmaksāt vairāk nekā pati funkcionalitāte, ko tai vajadzētu nodrošināt. Tad jautājums vairs nav par to, vai veco lietotni vispār aiztikt, bet gan par to, vai organizācija joprojām kontrolē tās darbību ražošanas apstākļos.

Šīs tēmas nozīme izriet no tā, ka rūpnieciskajās sistēmās tehnoloģiskais parāds ļoti ātri pārvēršas operacionālā parādā. Ja lietotni ir grūti atjaunot, tā ir atkarīga no atsevišķiem cilvēkiem, tai nav uzticamu regresijas testu vai tās loģikā ir sajauktas ražošanas funkcijas ar drošības un diagnostikas funkcijām, tad jebkurš incidents izmaksās dārgāk nekā līdzīga problēma biroja sistēmā. Sekas nav tikai dīkstāve. Klāt nāk ekspluatācijas uzturēšanas personāla darba izmaksas, risks, ka laika spiediena apstākļos tiks izmantoti kļūdaini pagaidu risinājumi, grūtības pierādīt pienācīgu rūpību pēc izmaiņu veikšanas, kā arī sarežģījumi nošķirt, kas bija iepriekšējs defekts un kas jau ir projekta komandas iejaukšanās sekas. Vadītājam un produkta īpašniekam praktiskais kritērijs ir vienkāršs: ja turpmāku nelielu izmaiņu ieviešanas laiks un nenoteiktība pieaug straujāk nekā to biznesa vērtība, lietotne ir nonākusi stāvoklī, kurā lēmums par refaktorēšanu jāpieņem apzināti, nevis jāatliek līdz pirmajai kritiskajai avārijai.

Visvairāk kļūdu rodas tad, ja refaktorēšanu uztver kā modernizāciju “bez ietekmes uz procesu”, lai gan patiesībā tā maina veidu, kā sistēma pieņem lēmumus. Praksē pietiek ar šķietami nelielu iejaukšanos: komunikācijas komponenta nomaiņu, uzdevumu plānošanas pārbūvi, sensoru datu buferēšanas loģikas maiņu vai palaišanas secības sakārtošanu pēc restartēšanas. Uz papīra tā ir tehniska sakārtošana. Taču cehā tas var mainīt signāla došanas brīdi, bloķējumu atbrīvošanas secību, reakciju sakaru zuduma gadījumā vai lietotnes uzvedību pēc elektroapgādes pārtraukuma. Tieši šeit refaktorēšanas tēma pāriet praktiskā izmaiņu riska novērtēšanā: runa nav par to, vai kods ir “labāks”, bet gan par to, vai pēc izmaiņām mašīna, līnija vai darba vieta joprojām uzvedas paredzami normālos, traucējumu un atkārtotas palaišanas režīmos.

Labs lēmuma brieduma pārbaudījums ir noskaidrot, vai komanda spēj noteikt robežu starp lietotnes iekšējās struktūras maiņu un procesa vai drošības ziņā būtiskas funkcijas maiņu. Ja šo robežu nevar aprakstīt signālu, stāvokļu un pārejas nosacījumu līmenī, projekts ir riskants neatkarīgi no izpildītāja kvalitātes. Rūpnieciskajā vidē īpaši jutīgas ir situācijas, kurās lietotne piedalās palaišanas, apturēšanas, kļūdu atiestatīšanas, trauksmju apstiprināšanas secībā vai sadarbojas ar enerģijas atslēgšanas ķēdēm un bloķēšanas ierīcēm. Šajā brīdī rodas jautājums vairs ne tikai par programmatūras arhitektūru, bet arī par aizsardzību pret neparedzētu iedarbināšanu un par to, vai analīze aptver arī elektroinstalāciju, vadības loģiku un savstarpējās atkarības starp iekārtām. Tieši šajā vietā šķietami lokāla refaktorēšana pārstāj būt IT uzdevums un kļūst par tehnisku izmaiņu, kurai nepieciešama pilna lēmumu pieņemšanas disciplīna.

Atsauce uz normatīvajām prasībām kļūst nozīmīga tikai šajā posmā, jo standarti neaizstāj projektēšanas lēmumu, bet palīdz sakārtot tā tvērumu. Ja izmaiņas var ietekmēt palaišanas, apturēšanas, darbības atjaunošanas pēc traucējuma nosacījumus vai aizsardzības pasākumus, tās jāvērtē kā riska izmaiņas novērtējums, nevis kā parasta koda uzturēšana. Ja iejaukšanās skar loģiku, kas sadarbojas ar enerģijas atslēgšanu, bloķēšanas ierīcēm vai drošas piekļuves secību, dabiski atveras arī prasību joma attiecībā uz aizsardzību pret neparedzētu iedarbināšanu. No atbildības viedokļa vissvarīgākais tādēļ nav pats jautājums “vai refaktorēt”, bet gan tas, vai organizācija spēj pierādīt, ka tā zina izmaiņu robežas, tai ir procesa uzvedībā balstīti pieņemšanas kritēriji un tā prot atšķirt sistēmas sakārtošanu no modifikācijas, kurai nepieciešams pilns riska novērtējums un koordinācija ar instalācijas projektēšanu un testiem objektā.

Kur visbiežāk pieaug izmaksas vai risks

Lielākais izmaksu pieaugums, pārstrādājot vecu rūpniecisko lietotni, reti izriet no paša koda. Problēmas avots parasti ir nepareiza izmaiņu kvalifikācija: komanda tās uztver kā programmas struktūras sakārtošanu, lai gan patiesībā mainās sistēmas darbība laikā, darbību secība vai pārejas nosacījumi starp stāvokļiem. Ražošanas vidē šādai kļūdai ir tiešas sekas projektā. Grafiks vairs neatbilst faktiskajam darbu apjomam, testi tiek plānoti IT funkcionalitātei, nevis procesa norisei, bet atbildība par rezultātu izplūst starp ekspluatācijas uzturēšanu, automatizāciju un programmatūras piegādātāju. Praktisks kritērijs šeit ir vienkāršs: ja pēc izmaiņām atkārtoti jāapstiprina palaišanas, apturēšanas, darba atsākšanas pēc traucējuma secība vai reakcija uz signāliem no aizsardzības ķēdēm, tad tā vairs nav “droša refaktorizācija” organizatoriskā nozīmē, bet gan izmaiņas, kas var radīt risku ražošanai un prasīt citu apstiprināšanas kārtību. Aizsardzība pret neparedzētu iedarbināšanu saskaņā ar ISO 14118 šādās situācijās kļūst par dabisku atsauces punktu.

Otra tipiska izmaksu pieauguma joma ir projektēšanas lēmums, kas pieņemts bez pilnīga priekšstata par savstarpējām atkarībām. Vecas rūpnieciskās lietotnes bieži ir cieši saistītas ar kontroliera konfigurāciju, izpildmehānismiem, vizualizāciju, datu arhivēšanu un operatora procedūrām. Dokumentācijā tas izskatās kā viena sistēma, bet praksē tie ir slāņi, ko gadu gaitā attīstījušas dažādas komandas. Refaktorizācija, kuras mērķis ir uzlabot koda lasāmību vai atvieglot turpmāku uzturēšanu, var nemanāmi mainīt aizturu nozīmi, bloķēšanas nosacījumus, noklusējuma vērtības pēc restartēšanas vai komunikācijas kļūdas apstrādes veidu. Sekas ir ne tikai tehnisks labojums, bet arī dīkstāves izmaksas, papildu izmēģinājumi objektā un strīdi par to, vai defekts pastāvēja jau iepriekš vai tika ieviests ar izmaiņām. Tāpēc pirms lēmuma pieņemšanas ir vērts novērtēt nevis pašu modifikācijas apjomu, bet saskares punktu skaitu un kritiskumu: cik signālu, recepšu, darba režīmu un ekspluatācijas apiešanas risinājumu ir atkarīgi no koda fragmenta, ko paredzēts pārveidot. Jo vairāk šādu punktu, jo mazāk pamatota ir refaktorizācija “starp citu” cita uzdevuma ietvaros.

Praksē īpaši dārgi ir projekti, kuros komanda faktiskās prasības atklāj tikai palaišanas laikā. Tipisks piemērs ir secīgā moduļa pārbūve, kas pēc apraksta “dara to pašu, tikai tīrāk”. Tomēr pēc ieviešanas izrādās, ka iepriekšējā versija saturēja nedokumentētu darbību, kas kompensēja objekta nepilnības: īslaicīgu signāla uzturēšanu, toleranci pret novēlotu sensora signālu, specifisku trauksmes atiestatīšanas secību vai nosacījumu, no kura atkarīga servisa piekļuves iespēja. Kodā tas izskatījās pēc kļūdas vai tehniskā parāda, bet procesam tas bija stabilizācijas elements. Ja refaktorizācija šādus mehānismus noņem, neizprotot to funkciju, izmaksas parādās nekavējoties: pieaug iejaukšanos skaits pēc palaišanas, paildzinās pieņemšanas laiks un loģika jāatjauno zem uzņēmuma darbības spiediena. Tāpēc refaktorizācijas lietderība jāvērtē arī pēc iespējas atjaunot pašreizējās sistēmas uzvedību. Ja organizācijai nav notikumu reģistra, uzticamu darba režīmu aprakstu un testēšanas scenāriju, kas balstīti uz reālo procesu, tad vispirms jāizveido pamats novērtēšanai un tikai pēc tam jāpieņem lēmums par pārbūvi.

Šis jautājums tieši pāriet praktiskā izmaiņu riska novērtēšanā, ja modifikācija ietekmē aizsardzības funkcijas, drošas piekļuves secības, izpildmehānismu kustības vadību vai iekārtas uzvedību pēc barošanas zuduma un atjaunošanās. Šādā apjomā kļūdas izmaksas neaprobežojas tikai ar programmēšanas labojumiem, jo parādās arī atbildības jautājums par izmaiņu nodošanu ekspluatācijā. Ja lietotne sadarbojas ar hidrauliskām, pneimatiskām sistēmām vai risinājumiem, piemēram, divroku vadību, tad robeža starp refaktorizāciju un tehniskām izmaiņām kļūst vēl šaurāka un prasa pārbaudīt, vai nav pārkāpti aizsardzības pasākumu projektēšanas pieņēmumi. Tieši šeit ir pamatoti atsaukties uz strukturētām riska novērtēšanas metodēm saskaņā ar ISO 12100, tostarp pieeju, ko praksē izmanto uz ISO/TR 14121-2 pamata, bet hidraulisko sistēmu gadījumā arī uz projektēšanas prasībām, ko sistematizē LVS EN ISO 4413. Runa nav par formālismu formālisma pēc, bet par vienkāršu lēmuma principu: ja izmaiņas var ietekmēt procesa vai apkalpošanas drošību, tad to izmaksas jāskaita kopā ar validāciju, testiem objektā un atbildības režīmu, nevis tikai ar programmētāja darba laiku.

Kā šai tēmai pieiet praksē

Praksē vecas rūpnieciskas lietojumprogrammas refaktorizācijas lietderību vērtē nevis pēc izmaiņu tehnoloģiskās pievilcības, bet pēc tā, vai vienlaikus iespējams samazināt ekspluatācijas risku un saglabāt kontroli pār ieviešanu. Vadītājam un produkta īpašniekam tas nozīmē vienkāršu skatpunkta maiņu: jautājums nav par to, vai kodu “ir vērts sakārtot”, bet gan par to, vai pašreizējais lietojumprogrammas stāvoklis reāli apgrūtina uzturēšanu, testēšanu, kļūdu novēršanu vai turpmāku izmaiņu ieviešanu atbilstoši prasībām. Ja atbilde ir apstiprinoša, refaktorizācijai ir jēga, taču tikai tādā apjomā, ko var nodalīt no ražošanas darba un novērtēt pēc izmērāmiem rezultātiem. Labs lēmuma kritērijs šeit ir divu izmaksu salīdzinājums: izmaksas, kas rodas, atstājot lietojumprogrammu pašreizējā stāvoklī, tostarp dīkstāves, diagnostikas laiks, atkarība no atsevišķiem cilvēkiem un kļūdainu izmaiņu risks, kā arī kontrolētas pārbūves izmaksas kopā ar testiem, validāciju un palaišanu. Bez šāda salīdzinājuma projekts parasti izslīd no kontroles, jo komanda finansē koda sakārtošanu no funkcionalitātei paredzētā budžeta, bet atbildība par sekām objektā paliek nenoteikta.

Tāpēc pirmajam lēmumam nevajadzētu būt “pārrakstām” vai “atstājam”, bet gan izmaiņu robežas noteikšanai. Nobriedušā pieejā daļu, kas attiecas tikai uz programmatūras struktūru, nodala no daļas, kas ietekmē procesa loģiku, palaišanas secības, apturēšanu, darba režīmus, komunikāciju ar piedziņām un sistēmas uzvedību pēc barošanas traucējumiem. Šim nošķīrumam ir tiešas izmaksu un organizatoriskas sekas. Izmaiņas, kas aprobežojas ar koda sakārtošanas slāni, var īstenot īsākā ciklā un ar mazāku ekspluatācijas uzturēšanas dienestu iesaisti. Izmaiņas, kas skar mašīnas vai līnijas uzvedību, jau prasa testu plānu objektā, servisa logu, atkāpšanās procedūru un nepārprotamu norādi, kurš apstiprina nodošanu ekspluatācijā. Turklāt ir vērts mērīt ne tikai programmēšanas darbu izpildes laiku, bet arī sistēmas atjaunošanas laiku pēc neveiksmīga mēģinājuma, regresijas testos iekļauto jomu skaitu un laiku, kas nepieciešams novirzes diagnostikai pēc palaišanas. Tie ir rādītāji, kas parāda, vai refaktorizācija patiešām samazina projekta risku, nevis tikai uzlabo izstrādes komandas darba komfortu.

Praktisks piemērs ir raksturīgs vecākām vadības lietojumprogrammām: kodā ir vairākkārt dublēti fragmenti, kas atbild par kustības bloķēšanu, trauksmju apstrādi un pārejām starp manuālo un automātisko režīmu. Komanda vēlas tos vienādot, jo pašreizējā struktūra apgrūtina attīstību un rada atšķirības starp darba vietām. Šādam lēmumam ir jēga tikai pēc pārbaudes, vai vienādošana nemainīs nosacījumus, kādos izpildmehānisms saņem atļauju kustībai, un vai pēc kontroliera restartēšanas neparādīsies cita stāvokļa atjaunošanas secība. Ja lietojumprogramma vada arī vārstus, piedziņas vai sistēmas ar uzkrātu enerģiju, tad pat šķietami “iekšēja” refaktorizācija var pāriet izmaiņu riska novērtēšanas jomā un prasīt aizsardzības pret neparedzētu iedarbināšanu saskaņā ar ISO 14118 analīzi. Šādā gadījumā saprātīga prakse ir veikt refaktorizāciju pa posmiem: vispirms atjaunot uzvedību testēšanas vidē, pēc tam nodalīt moduļus, nemainot loģiku, un pēc tam veikt pārbaudi objektā ar sagatavotu atkāpšanās scenāriju. Tas ierobežo operatīvo atbildību un ļauj pārtraukt ieviešanu, pirms problēma ietekmē ražošanu.

Tikai šajā posmā ir vajadzīga atsauce uz standartiem, jo standarti neaizstāj tehnisku lēmumu, bet palīdz sakārtot brīdi, kad izmaiņas vairs nav tikai programmēšanas darbs. Ja refaktorizācija ietekmē aizsardzības līdzekļus, drošas piekļuves nosacījumus, enerģijas atslēgšanu vai sistēmu uzvedību pēc apturēšanas un atkārtotas palaišanas, tā dabiski nonāk praktiskas izmaiņu riska novērtēšanas saskaņā ar ISO 12100 tvērumā, ko veic strukturēti, izmantojot arī pieeju, kas zināma no ISO/TR 14121-2. Ja parādās neparedzētas iedarbināšanas risks, jāpārbauda ne tikai pats kods, bet arī enerģijas atslēgšanas un atjaunošanas loģika, kas tieši ved uz jautājumiem, kuri saistīti ar ISO 14118. Savukārt, ja lietojumprogramma ir saistīta ar hidrauliku vai pneimatiku, novērtējumā nedrīkst ignorēt šo sistēmu projektēšanas pieņēmumus, jo kļūdaina vadības secība var izjaukt to drošu darbību neatkarīgi no pašas programmas pareizības; tad pamatoti kļūst arī atsaukties uz prasībām, kas sakārto hidraulisko sistēmu projektēšanu. Praksē tas nozīmē vienu: par refaktorizācijas apjomu lemj nevis risinājuma elegance, bet atbildības robeža par instalācijas drošu uzvedību pēc izmaiņām.

Kam pievērst uzmanību ieviešanas laikā

Vecas rūpnieciskas lietojumprogrammas refaktorizācijas ieviešana ir brīdis, kad pat pareizs arhitektūras lēmums var pārvērsties operatīvā problēmā. Visa pasākuma jēga beidzas tur, kur izmaiņas uzlabo kodu, bet pasliktina instalācijas darbības paredzamību vai paplašina komandas atbildību ārpus tā, kas ir identificēts un apstiprināts. Visbiežākā kļūda ir ieviešanu uztvert kā parastu jaunas versijas publicēšanu. Ražošanas vidē svarīgi ir ne tikai tas, vai lietojumprogramma darbojas, bet arī tas, vai pēc izmaiņām visi pārejas stāvokļi uzvedas identiski: palaišana pēc barošanas zuduma, komunikācijas restartēšana, recepšu atjaunošana, trauksmju, bloķējumu un manuālo režīmu apstrāde. Praktiskais kritērijs ir vienkāršs: ja komanda nespēj nepārprotami aprakstīt, kurai uzvedībai pēc ieviešanas jāpaliek nemainīgai, tas nozīmē, ka drošai palaišanai vēl nav izpildīti priekšnoteikumi.

Ieviešanas lēmuma posmā ir jānodala tehniski atgriezeniskas izmaiņas no tādām izmaiņām, kas pēc palaišanas izveido jaunu bāzes stāvokli un apgrūtina atgriešanos pie iepriekšējā risinājuma. Tam ir tieša ietekme uz izmaksām un grafiku. Refaktorēšana, kurai vienlaikus nepieciešama vadības ierīču, vizualizācijas, datu servera un saskarņu ar augstāka līmeņa sistēmām atjaunināšana, vairs nav atsevišķs programmēšanas uzdevums; tā kļūst par koordinētām izmaiņām ražošanā ar vairākiem atteices punktiem. Tāpēc pirms ieviešanas ir vērts noteikt pieņemšanas kritēriju, kas balstīts nevis uz deklarāciju “testi ir izturēti”, bet gan uz spēju kontrolēti atsaukt izmaiņas procesam pieņemamā laikā. Ja nav uzticamas atgriešanās procedūras, nav arī pamata apgalvot, ka risks ir pārvaldīts. Praksē ir lietderīgi mērīt nevis abstraktu “ieviešanas kvalitāti”, bet tādus rādītājus kā iepriekšējās versijas atjaunošanas laiks, no izmaiņām atkarīgo saskarņu skaits un to funkciju skaits, kuru pareizību var apstiprināt uzstādītajā sistēmā, neiejaucoties ražošanā.

Labs piemērs ir situācija, kad refaktorēšana sakārto izņēmumu apstrādi un kļūdu paziņojumus, bet vienlaikus maina inicializācijas secību pēc sistēmas restartēšanas. Testa stendā viss izskatās pareizi, jo ierīces ir pieejamas uzreiz un process nedarbojas slodzes apstākļos. Taču uzņēmumā tas pats kods var palaist secību citā brīdī nekā līdz šim, un tas var izraisīt sinhronizācijas zudumu ar piedziņām, nepareizu gatavības signālu interpretāciju vai materiāla partijas apstāšanos starpstāvoklī. Šāds incidents tehniskā nozīmē var arī nebūt avārija, tomēr tas rada dīkstāves, brāķa, atkārtotas palaišanas izmaksas un papildu atbildību par lēmumu atsākt darbu. Tieši šeit refaktorēšanas tēma pāriet praktiskā izmaiņu riska novērtēšanā: nevis tad, kad izmaiņas ir lielas, bet tad, kad to sekas vairs nevar ierobežot tikai ar programmatūras slāni.

Atbildības robeža kļūst vēl skaidrāka tur, kur lietojumprogramma ietekmē aizsargfunkcijas, kustības atļaušanas loģiku, atslogošanas secības, apturēšanu un atkārtotu palaišanu pēc traucējuma. Šādā gadījumā vairs nepietiek ar koda versiju salīdzināšanu vai integratora veiktu funkcionālo testu. Ir nepieciešams strukturēts izvērtējums par to, vai izmaiņas maina riska līmeni un vai tās nepārkāpj mašīnas vai iekārtas drošas darbības pieņēmumus. Tas ir dabisks brīdis pāriet uz riska novērtēšanu saskaņā ar ISO 12100 un praksēm, ko izmanto izmaiņu riska izvērtēšanā, bet sarežģītākos gadījumos noderīga var būt arī metodiskā pieeja, kas zināma no ISO/TR 14121-2. Ja lietojumprogramma vada hidrauliskās vai pneimatiskās sistēmas, papildus jāpārbauda, vai jaunā loģika nemaina drošas enerģijas vadības nosacījumus un kustību secību; tad nozīme ir arī šīm sistēmām piemērojamajām projektēšanas prasībām, ne tikai pašas programmas pareizībai. Projekta komandai tas nozīmē vienu: ieviešanu var uzskatīt par sagatavotu tikai tad, ja tehniskās, ekspluatācijas un atbilstības atbildības apjoms ir skaidri noteikts pirms palaišanas, nevis tikai pēc pirmā incidenta.