Egy örökölt alkalmazás modernizálását azzal kezdje, hogy leírja, miért kell változnia, majd együtt mérje fel a kódot és az éles működést. Stabilizálja a rendszert, és tegyen teszteket az üzlet számára fontos működés köré, mielőtt a szerkezetéhez nyúlna. Ezzel a biztonsági hálóval cserélje le a rendszert darabonként, az adatokat tudatosan migrálja, a teljes újraírást pedig tartsa meg arra a ritka esetre, amikor kevés dolog érdemes a megtartásra.
Nevezze meg az üzleti okot, mielőtt a kódhoz nyúl
A modernizáció drága, ezért az okkal kezdje. Gyakori okok: lejárt támogatású futtatókörnyezet vagy keretrendszer, hetekig tartó változtatások, mert minden kiadás elront valamit, egy rendszer, amelyet csak egyetlen ember ért, vagy egy platform, amely nem tudja kiszolgálni az üzlet következő igényeit. Minden ok más első lépésre mutat.
Az okot egy később ellenőrizhető mérőszámmal együtt írja le, például hogy milyen gyakran ad ki új verziót, hány incidense van, vagy mennyi idő alatt jut el egy tipikus változtatás a felhasználókhoz. Enélkül a modernizáció nyílt végű fejlesztési projektté válik, amelyet a következő költségvetési felülvizsgálaton nehéz megvédeni.
Mérje fel a kódot és az éles működést, mielőtt bármiről döntene
A felmérés megmutatja, mi van valójában a birtokában. Legyen rövid, és egy írásos jelentéssel, valamint egy javasolt első lépéssel záruljon. Olvassa a kódot, de olvassa az éles működést is: a naplókat, az incidenseket, a lassú lekérdezéseket és azt, ahogyan a kiadások történnek. A legsúlyosabb problémák gyakran nem a kódban, hanem körülötte vannak.
- Futtatókörnyezet-, keretrendszer- és könyvtárverziók, és hogy közülük melyek nem kapnak már biztonsági javításokat
- Mely részek változnak és mely részek romlanak el a leggyakrabban, a verziótörténet és az incidensnapló alapján
- Tesztlefedettség azokon az útvonalakon, amelyekre az üzlet támaszkodik
- Hogyan készül a build, hogyan konfigurálják és telepítik az alkalmazást, és ki tudja ezt elvégezni
- Az adatmodell, a mérete, és hogy mely más rendszerek olvassák vagy írják ugyanazt az adatbázist
- Az emberek, akik ismerik a rendszert, és amit csak ők tudnak
Először az éles működést stabilizálja, hogy a munkának szilárd alapja legyen
Ha a rendszer hetente leáll, a modernizáció is hetente megszakad. Először azt javítsa ki, ami az incidenseket okozza: vezessen be monitorozást és riasztásokat a kritikus útvonalakon, automatizálja a buildet és a telepítést, hogy a kiadások megismételhetők legyenek, és vigye ki a titkos adatokat és a konfigurációt a kódból.
Ezek a lépések azonnal megtérülnek, és minden későbbi lépést biztonságosabbá tesznek. Korán azt is megmutatják, képes-e a csapat úgy változtatni a rendszeren, hogy nem rontja el, és ezt érdemes tudni, mielőtt egy nagyobb terv mellett elköteleződne.
Építsen tesztekből biztonsági hálót a működés köré, amelyre támaszkodik
Az örökölt kódhoz általában kevés teszt tartozik, és a dokumentált működése ritkán egyezik a valódival. Mielőtt a szerkezetén változtatna, írjon karakterizációs teszteket: olyan teszteket, amelyek rögzítik, mit csinál ma a rendszer, a furcsa határeseteivel együtt, így a működés bármilyen változása sikertelen tesztként jelenik meg.
A széleken kezdje, olyan tesztekkel, amelyek az API-n vagy a felhasználói felületen keresztül hívják az alkalmazást, és az eredményeket ellenőrzik, mert ezek túlélik a belső változtatásokat. Számításoknál és riportoknál futtasson át valós bemeneteket a régi és az új kódon, és vesse össze a kimeneteket. Minden részhez finomabb szemcsézettségű teszteket adjon, ahogy refaktorálja. Egy kritikus Java 8-as alkalmazás frissítéséről szóló cikkünk ugyanezt a biztonsági hálót mutatja be egy futtatókörnyezet-frissítésnél.
Cserélje le a rendszert darabonként, ne írja újra
A teljes újraírás papíron tisztának tűnik, de a régi rendszer közben tovább fut és változik, amíg az új utoléri, és minden dokumentálatlan működést útközben újra fel kell fedezni. Ezért tart az újraírás olyan gyakran tovább a tervezettnél, miközben az üzlet vár.
A szokásos alternatíva a strangler fig (fojtófüge) minta. Tegyen egy útválasztó réteget, például egy reverse proxyt vagy egy API-átjárót az örökölt alkalmazás elé. Az új kódban egyszerre egy képességet építsen meg, és amint bizonyított, az adott képesség forgalmát irányítsa át rá. A régi rendszer addig zsugorodik, amíg ki nem lehet kapcsolni, az üzlet pedig minden lépésnél értéket kap.
Az újraírás ennek ellenére is lehet helyes döntés: ha a kódbázis kicsi, és a működése jól ismert, vagy ha az a platform, amelyen fut, nem tartható életben elég sokáig a fokozatos cseréhez. Írásos kritériumok alapján döntsön, ne a frusztráció alapján.
Kezelje az adatokat önálló migrációként
A kódot szeletekben lehet lecserélni; az adatokat nehezebb szétválasztani. Amíg az örökölt és az új kód egy adatbázison osztozik, minden sémaváltozást egyeztetni kell. Döntse el korán, melyik rendszer az igazság forrása az egyes adattípusokra, és kerülje, hogy két rendszer ugyanazt a rekordot írja anélkül, hogy szabály döntené el, melyik írás győz.
Amikor egy képesség átköltözik, az adatait tudatosan költöztesse vagy szinkronizálja: az éles adatok másolatán tesztelt migrációs szkriptekkel, vagy folyamatos szinkronizálással, amíg mindkét rendszer fut. Tervezze meg, hogyan egyezteti a kettőt, például napi darabszámokkal és ellenőrzőösszegekkel, és tartsa meg a visszaváltás lehetőségét, amíg a számok nem egyeznek.
A munkát kockázat és érték szerint ütemezze, és korán mutasson előrehaladást
Úgy rendezze a munkát, hogy minden lépés vagy csökkentse a kockázatot, vagy olyasmit adjon, amit az üzlet is lát. Gyakori sorrend: stabilizálás és automatizálás, tesztek hozzáadása, a futtatókörnyezet frissítése, majd a leggyakrabban változó képességek kiemelése. A stabil és ritkán érintett részek várhatnak, néha korlátlan ideig.
A terv legyen rövid, és minden lépés után vizsgálja felül, mert amit megtud, az megváltoztatja a sorrendet. Mérnökeink így dolgoztak kritikus rendszereken. A Sopra Steria révén ők vezették egy kritikus, földgáz napon belüli kereskedésére (day trading) szolgáló alkalmazás Java 8-ról 16-ra történő migrációját, a Crédit Agricole felhőprogramjának csapatában pedig minden általunk migrált alkalmazást felmértünk, hogy eldöntsük, frissítjük vagy újraépítjük. Ha saját rendszere felmérését szeretné, vagy egy csapatot a terv végrehajtásához, az SDK Enterprises mindkettőt vállalja egyetlen szerződés keretében.
A legfontosabbak
- Írja le a modernizáció üzleti okát egy később ellenőrizhető mérőszámmal együtt.
- Mérje fel együtt a kódot és az éles működést, mielőtt a frissítés, a fokozatos csere és az újraírás között választ.
- Stabilizálja az éles működést, és tegyen karakterizációs teszteket a kritikus működés köré, mielőtt a szerkezeten változtat.
- Cserélje le a rendszert darabonként egy útválasztó réteg mögött, hacsak egy újraírás nem egyértelműen kisebb és biztonságosabb.
- Az adatok gazdáját, szinkronizálását és egyeztetését önálló migrációként tervezze meg.
GYIK
Írjuk újra a nulláról az örökölt alkalmazásunkat?
Általában nem. Az újraírás egy folyamatosan változó rendszerrel versenyez, és újra fel kell fedeznie azt a működést, amelyet senki nem dokumentált. Cserélje le fokozatosan, hacsak a kódbázis nem kicsi és jól ismert, vagy nem egy olyan platformhoz kötött, amelyet nem lehet tovább működtetni.
Mennyi ideig tart egy örökölt alkalmazás modernizálása?
Ez a rendszer méretétől, a tesztlefedettségtől, az adatok összefonódottságától és attól függ, mennyinek kell megváltoznia. Egy rövid felmérés reális tervet ad és egy olyan első lépést, amely elég kicsi ahhoz, hogy be lehessen fejezni és mérni, ahelyett hogy egyetlen dátumot adna a teljes munkára.
Szállíthatunk új funkciókat a modernizáció alatt?
Igen, és érdemes is. A fokozatos csere lehetővé teszi, hogy a csapat az új kódban szállítson funkciókat, miközben az örökölt rendszer tovább fut. Egyezzenek meg abban, hogy a csapat idejének mekkora része megy a modernizációra, hogy a funkciófejlesztés ne nyelje el csendben.