Régi szoftver korszerűsítése teljes újraírás nélkül

Szinte minden befutott cégnek van egy: egy szoftver, amelyet mindenki csendben utál. Lassú, csúnya, a csapat fele ismer egy kerülőmegoldást a hibára, amelyet soha senki nem javított ki, és az egyetlen ember, aki értette, 2019-ben elment. Az ösztön mindig ugyanaz: égessük fel és építsünk újat. És ez az ösztön a legtöbbször pontosan az a mód, ahogyan jó cégek egy évet és egy kisebb vagyont veszítenek el a semmiért.

Elégszer láttam a nagy újraírást rosszul elsülni ahhoz, hogy reflexem legyen rá. Egy alapító megmutatja nyikorgó rendelési rendszerét vagy ősrégi ütemezőeszközét, felsóhajt, és valamilyen változatát mondja annak, hogy „egyszerűen le kell cserélnünk az egészet.” És talán egy nap valóban meg is teszik. De a teljes újraírás — kitépni a régi rendszert, párhuzamosan felépíteni egy vadonatúj, csillogót, majd átkapcsolni — a szoftver egyik legkockázatosabb lépése. Drága, sokkal tovább tart az ígértnél, és a teljes időtartam alatt vakon repül, abban bízva, hogy az új minden furcsa szélső esetet lefed, amelyet a régi tizenöt éven át csendben kezelt.

A jó hír, hogy a teljes újraírás szinte sosem az egyetlen lehetőség, és ritkán a legjobb. Van egy nyugodtabb módja a korszerűsítésnek — fokozatos, visszafordítható, és kíméletes a céghez, amelynek továbbra is pénzt kell keresnie, miközben Ön dolgozik. Ez egy útmutató ehhez az úthoz: hogyan ismeri fel, mit kell valóban megjavítani, hogyan cseréli ki a fájó részeket anélkül, hogy leállítaná az egész rendszert, és honnan tudja, mikor valóban a teljes újraírás a helyes döntés.

Miért olyan csábító — és olyan veszélyes — a nagy újraírás

A teljes újraírás csábító, mert tiszta lapot ígér. Nincs több legacy kupleráj, nincsenek kompromisszumok, friss kódbázis, modern eszközökkel jól felépítve. A táblán nyilvánvalónak tűnik. A valóságban azonban arra szerződik, hogy évek felhalmozott üzleti logikáját építse újra — nagy részét dokumentálatlanul, egy részét csak már távozott emberek fejében élve —, miközben ketyeg az óra és jönnek a számlák.

A mélyebb csapda a párhuzamos univerzum problémája. Azokban a hónapokban vagy években, amíg a csere felépül, két rendszere van: a régi, amelynek továbbra is működtetnie kell a céget, és az új, amely még nincs kész. Minden változtatást, amelyre a cégnek szüksége van, kétszer kell elvégezni, különben az új rendszer lemarad a valóságtól, mielőtt egyáltalán elindulna. A csapatok kiégnek, miközben mindkettőt életben tartják. És mivel senkinek sem szabad átváltania, amíg az új rendszer mindent nem tud, nincs korai siker, nincs visszajelzés, nincs bizonyíték, hogy működik — csak hosszú, szorongó várakozás egyetlen hatalmas, mindent vagy semmit indítási napra.

Van itt egy jól ismert szakmai népi bölcsesség, és kiérdemelt: a második rendszernek, a nagy újraírásnak, megvan az a szokása, hogy háromszor annyi ideig tart, mint becsülték, és kevesebb funkcióval érkezik, mint amit lecserél. A becslés nem azért hibás, mert az emberek hanyagok. Azért hibás, mert kezdetben senki sem láthatja az összes apró dolgot, amit a régi rendszer csendben jól csinál.

Mit jelent valójában a „legacy” (nem a kor a lényeg)

A legacy szót úgy dobálózzuk, mintha csak azt jelentené: régi. Nem azt jelenti. Rengeteg szoftver, amely egy évtizede fut, tökéletesen rendben van — unalmas, stabil, kifizetett, teszi a dolgát. A kor önmagában nem ok arra, hogy bármihez hozzányúljon. Az egész terület legdrágább hibája olyasmit korszerűsíteni, ami csendben működött, csak azért, mert elavultnak látszott.

A szoftver akkor érdemli ki a legacy címkét, amikor tevékenyen az útjába áll. Amikor nem tudja biztonságosan megváltoztatni, mert senki sem érti teljesen. Amikor nem tud csatlakozni az eszközökhöz, amelyektől most függ. Amikor egyetlen ember az egyetlen, aki életben tudja tartani. Amikor olyan lassú vagy törékeny, hogy a csapata egész kerülőmegoldás-folklórt épített köré. Ez az igazi meghatározás — nem az év, amikor megírták, hanem a költség, amelyet ma ró Önre, és a kockázat, amelyet a holnapba visz.

Állítson fel diagnózist, mielőtt bármihez hozzányúl

Mielőtt egyetlen sort is újraírnának, őszinte térképre van szüksége arról, hol lakik valójában a fájdalom. Legtöbbször a rendszer, amelyet mindenki utál, 80%-ban rendben van. A baj néhány konkrét helyre összpontosul — egy lassú képernyő, egy törött integráció, egy munkafolyamat, amely kétszeres adatbevitelre kényszerít —, és ez a néhány hely termeli a panaszok szinte mindegyikét. Találja meg őket, és megtalálta az egész projektjét.

A megtalálás módja nem először egy technikai audit — hanem egy beszélgetés. Üljön le azokkal, akik nap mint nap használják a dolgot, és kérdezze meg, hol fáj. Hol várakoznak? Mit gépelnek be újra? Mit kerülnek el, mert fájdalmas? Hol vezetnek saját táblázatot, hogy megkerüljék a hivatalos rendszert? Ezek a kerülőmegoldások arany értékűek: mindegyik egy megjavítást érdemlő probléma pontos röntgenképe.

• A képernyők és lépések, amelyekre az emberek a legtöbbet panaszkodnak — nem elméletben, hanem a tényleges napi munkájukban.
• Minden hely, ahol az adatot kétszer gépelik be, mert két rendszer nem beszél egymással.
• Az integrációk, amelyek elromlottak, vagy sosem léteztek, és kézi másolásra-beillesztésre kényszerítenek az eszközök között.
• Bármi, amit csak egyetlen ember tud üzemeltetni vagy javítani — az egyedüli hibapontjai.
• A részek, amelyek valóban rendben vannak, hogy megvédhesse és békén hagyhassa őket.
• Amire a cégnek jövőre szüksége lesz, és amibe a jelenlegi rendszer egyszerűen nem tud belenőni.

Amikor ezt őszintén teszi, a projekt általában összezsugorodik. A tulajdonos, aki azzal jött be, hogy „cseréljünk le mindent”, azzal a felismeréssel távozik, hogy három dolgot kell megjavítania. Ez nem csalódás — megkönnyebbülés. Három javítható dolog olyan projekt, amelyet még ebben a negyedévben befejezhet. A teljes csere egy év, amelyet talán nem él túl.

A fojtogató megközelítés: cserélje le darabonként

Van egy minta a biztonságos elvégzésére, és kissé komor, de emlékezetes neve van: fojtogató megközelítés, a fojtogató fügefa nyomán — egy inda, amely egy fa köré nő, fokozatosan átveszi annak szerkezetét, míg végül az új növedék a saját lábán áll, és a régi törzs eltűnik. Szoftverre alkalmazva az ötlet csodálatosan gyakorlatias: nem egyetlen hősies cserével váltja le a régi rendszert. Köré növeszti az újat, darabonként, míg a régiből nem marad semmi, amire bárkinek szüksége volna.

A gyakorlatban így működik. Kiválaszt egy fájó darabot — mondjuk a számlázómodult, amelyet mindenki utál. Modern cserét épít csak arra a darabra. A számlázást az új modulra irányítja, miközben minden más változatlanul fut tovább a régi rendszeren. Egy ideig figyeli. Amikor szilárd, a régi rendszer ama része elcsendesedik, Ön pedig a következő darabra lép. A régi rendszer fokozatosan zsugorodik, mint egy gyertya, ahelyett hogy egy csapásra ledöntenék.

Ami ezt sokkal biztonságosabbá teszi egy újraírásnál, az, hogy minden lépés kicsi, élő és visszafordítható. Soha nem repül vakon. Minden új darab gyorsan valódi használatba kerül, így gyorsan kiderül, valóban működik-e. Ha valami elromlik, csak egy modult kockáztatott, nem az egész céget — és általában visszaválthat a régi útra, amíg megjavítja. Sikereket arat útközben, egyetlen rettegett indítás helyett a végén. És a cég végig, normálisan fut tovább.

Hogyan néz ki valójában a ritmus

1. 1
   Válassza a legfájóbb, legönállóbb darabot

   Nagy fájdalmat és tiszta éleket akar — egy modult, amely sokat fáj, és nincs benne ujja minden másban. Az az első célpontja.
2. 2
   Tegyen vékony réteget a régi rendszer elé

   Egy kis útválasztó réteg dönti el, mely kérések mennek a régi rendszerre, és melyek az új darabra. Ez az illesztés teszi lehetővé az összes többit.
3. 3
   Csak azt az egy darabot építse meg és indítsa el

   Cseréljen le egy modult, adja valódi kezekbe, és csak a munka azon szeletét irányítsa rá. Hetek, nem évek — a rendszer többi része pedig meg sem mozdult.
4. 4
   Stabilizáljon, majd lépjen a következő darabra

   Amint az új modul megbízható, a régi rendszer megfelelő része nyugovóra tér. Ismételje a következő fájó darabbal, menet közben tanulva.
5. 5
   Vonja ki a régi rendszert, amikor üres

   Végül a legacy rendszer már semmit sem csinál, amire bárki támaszkodna. Csak akkor kapcsolja ki — csendben, dráma nélkül, mert minden fontos már átköltözött.

Figyelje meg, miben más ez az újraírástól: nincs egyetlen rettegett indítási nap. Nincs fenntartandó párhuzamos univerzum. Az új rendszer a harmadik héttől éles üzemben van, megkeresi a kenyerét és tanít Önnek dolgokat, ahelyett hogy egy laborban várna egy folyton csúszó indításra.

Néha le sem kell cserélnie

Mielőtt bármit lecserélne, érdemes megkérdezni, hogy a régi rendszert le kell-e cserélni, vagy csak meg kell szűnnie szigetnek lenni. Meglepően sok „új rendszerre van szükségünk” probléma valójában „a rendszereink nem beszélnek egymással” probléma. A régi szoftver jó a dolgában — csak egy silóban ül, és arra kényszeríti az embereket, hogy kézzel hordják be és ki az adatot.

Ezekben az esetekben a legolcsóbb, leggyorsabb megoldás nem egy új rendszer. Egy híd. A régi szoftvert egy kapcsolattal veszi körül — egy integrációval, amely lehetővé teszi, hogy automatikusan adatot cseréljen a többi eszközével —, és egy modern réteggel a tetején azokhoz a részekhez, amelyekhez az emberek valóban hozzányúlnak. Az elavult motor tovább zümmög odalent; a csapat tiszta felületet és a másolás-beillesztés végét kapja. Nem látványos, de gyakran a legnagyobb megtérülés euróban az egész erőfeszítésben.

Mikor valóban a teljes újraírás a helyes döntés

Ezt az egész útmutatót azzal töltöttem, hogy lebeszéljem a nagy újraírásról, így legyek tisztességes: néha valóban ez a válasz. Vannak annyira rohadt alapok, hogy semennyi foltozás, áthidalás vagy darabonkénti csere nem menti meg őket, és az ellenkezőjét állítani csak halogatja az elkerülhetetlent, miközben pénzt költ egy holttest aládúcolására.

Az őszinte jelek konkrétak. A technológia, amelyre a rendszer épül, halott vagy haldoklik — nincs támogatás, nincsenek biztonsági frissítések, nem maradt senki, aki dolgozni tudna rajta. A cég olyan alapvetően megváltozott, hogy a régi modell egyáltalán nem felel meg már a valóságnak. Vagy a rendszer annyira összegabalyodott, hogy még kis változtatások is rendre eltörnek nem összefüggő helyeken dolgokat, ami rendszerint azt jelenti, hogy eleve nincsenek tiszta illesztések egy fojtogató megközelítéshez. Amikor ebből kettő vagy három egyszerre igaz, a fokozatos munka megszűnik a biztonságosabb választás lenni.

És itt a csendes jutalma annak, ha előbb a fokozatos munkát végzi el, még ha végül mégis újraépít: mire odaér, sokkal jobban érti majd a rendszert, mint a kezdetekkor. Minden modul, amelyet lecserélt, tanított Önnek valamit, amit az eredeti szerzők soha le nem írtak. Egy ettől a tudástól tájékozott újraírás teljesen más, sokkal biztonságosabb jószág, mint az, amelyet az első nap optimizmusára indítanak.

A rész, amelyet senki sem említ: többnyire az emberekről szól

Íme valami, amit a technikai útmutatók kihagynak. A régi szoftver korszerűsítésének legnehezebb része rendszerint nem a kód — hanem az emberek, akik évek alatt alkalmazkodtak hozzá. Ismerik a furcsaságait. Izommemóriájuk van a fura gyorsbillentyűihez. Egy objektíve jobb új modul az első két hétben mégis rosszabbnak tűnhet, pusztán mert ismeretlen. Ha ezt figyelmen kívül hagyja, még egy tökéletes technikai migráció is megbukhat.

A fokozatos megközelítés itt is segít, szinte véletlenül. Mivel a változás egyszerre egy kis darabban érkezik, az emberek fokozatosan szívják magukba, ahelyett hogy egyetlen hétfő reggel kérnék tőlük az egész újratanulását. Vonja be korán a napi felhasználókat. Hagyja, hogy alakítsák a cserét, mielőtt elkészül. A csapat, amely segített megtervezni az új számlázóképernyőt, mellette fog kiállni; a csapat, amelynek a nyakába varrták, neheztelni fog rá, még ha azonos is. A korszerűsítés szoftverjelmezbe bújt változáskezelési projekt.

Gyakori kérdések