Kuidas süüa [monoliitset] elevanti?

„Pärandliku” tarkvarasüsteemi arengu juhtimine on keeruline probleem. Koodbaasi suurus, komponentide suur seotus ja aastate jooksul kogunenud tehniline võlg võivad olla tohutult suured. Sageli muudab automatiseeritud testide puudumine kõik tehnilised muudatused ettevõtte jaoks riskantseks ja potentsiaalselt kahjulikuks. Mõelge sellele, et kliendid ei saaks raamatukogu värskenduse tõttu tellimusi esitada.

Kuidas meeskonnad sellele ebamugavale olukorrale lähenevad? Kuidas koostada ohutu üleminekukava, kui neile tehakse ülesandeks ulatuslik refrakteerimis- või rändeharjutus? Kuidas nad alustavad ja edusamme mõõdavad?

Selles postituses tutvustame juhtumianalüüsi, mis näitab, et eesmärgi-küsimuse-mõõdiku meetodil põhinev andmepõhine protsess võib anda meeskonnale selgust ja enesekindlust. Pärast lähenemisviisi tutvustamist kirjeldame mõnda tööriista, mida kasutatakse andmete kogumiseks kogu protsessi vältel (enne migratsiooni ja selle ajal).

Juhtumiuuring

Aitasime hiljuti meeskonda, kes töötab välja B2B toote, millel on tüüpiline mitmetasandiline arhitektuur. Mitmed veebirakendused suhtlevad REST API-ga, mis on seotud äri- ja andmetele juurdepääsu teenustega. Tarkvara on umbes 7 aastat vana. Kuigi oleme töötanud palju suuremate, vanemate ja keerukate süsteemide kallal, on sellel rakendusel juba korralik suurus, kümnete lõpp-punktidega.

Pärast esialgset koodide ülevaatamist tuvastasime pärandsüsteemidele tavalised probleemid: haldamata ja aegunud sõltuvused, hävinud paketi- ja failistruktuur, automatiseeritud testimise puudumine, ehituse automatiseerimise puudumine.

Meid paluti teha ettepanek tehnilise rände strateegia kohta ja teha meeskonnaga koostööd selle rakendamiseks. Rände peamised äritegevuse ajendid olid hoolduskulud ja vananenud raamatukogude ja raamistikega seotud turvariskid.

Meie soovitus oli mitte jagada monoliitset rakendust mikroteenuste föderatsiooniks. Hajutatud mikroteenused oleksid täiendanud keerukust, ilma et sellest oleks reaalset kasu. Selle asemel soovitasime pärandmonoliidi ümber kujundada paremini juhitavaks ja jõulisemaks monoliidiks. Selle strateegia rakendamiseks kavandasime järkjärgulise protsessi:

  • Looge uue monoliidi skelett.
  • Tuvastage piiritletud kontekstid ja eraldage need ükshaaval.
  • Migratsiooni ajal suhtlevad kasutajad pärand- ja „värskete” teenustega.
  • Pärast migratsiooni on aegunud lõpp-punktid ja surnud kood kõrvaldatud.
  • Selle protsessi ohutuks rakendamiseks kirjutage automatiseeritud testid (rakendades BDD tehnikaid), et kirjeldada iga piiratud konteksti praegust käitumist. Need testid võimaldavad meil kinnitada, et vanade ja uute süsteemide käitumine on sama.

Ülaltoodud diagrammil näeme:

  • Päritud monoliit (1). Mõnda lõpp-punkti ja koodi enam ei kasutatud (kuid me ei teadnud, kui palju).
  • Erinevad kliendid (2), mis suhtlevad taustaprogrammiga.
  • Uus monoliit (3), mis on ehitatud puhtale konstruktsioonile, hallatavate sõltuvustega. Algselt ei sisalda see uus taustprogramm lõpp-punkti. Aja jooksul siirdatakse lõpp-punktid ja tugiteenused selle uue koodbaasi kaudu.
  • API-lüüsi (4), mille tutvustasime järkjärgulise migratsiooniprotsessi võimaldamiseks. Lüüs suunab HTTP-päringud vastavasse monoliiti. Migratsiooni alguses suunatakse kõik taotlused pärandsüsteemi. Lõpus saadetakse kõik taotlused uude süsteemi.
  • BDD-testi rakmed (5), mis on automatiseeritud testide komplekt, mis kirjeldab taustarakenduse kavandatud käitumist. Testid kirjutatakse protsessi alguses, et kirjeldada pärandmonoliidi käitumist. Ülemineku ajal, kuna lõpp-punktid ja liiklus viiakse uue süsteemi kohale, kasutatakse testi rakmeid, et kontrollida, kas süsteemi käitumist pole muudetud.
  • Süsteemi valideerimiseks läbi kasutajaliidese kihi luuakse ka otstestide (6) komplekt. Kui API kihi testid peavad olema kõikehõlmavad, rakendatakse väiksemat arvu otstesti (tavaliselt keskendutakse "õnnelikule teele").

Kuidas me alustame?

Rändeprotsessi kirjeldamine jätab hulga lahtisi küsimusi. Kui palju aega vajab meeskond selle rakendamiseks? Ja kuidas saab meeskond protsessi jooksul edusamme mõõta ja eeldatavat valmimisaega üle vaadata?

Nendele küsimustele vastamine on väga oluline, et pakkuda juhtkonnale nähtavust ja meeskonnale selgust. Ilma selleta tunneks keegi treeningu alustamist ebamugavalt. See on asi, mida oleme mitu korda täheldanud: kui meeskonnad ei tea elevandi suurust, on neil väga raske hammustada.

Raamida probleem eesmärgi-küsimuse-mõõdikuga

Meeskonna abistamiseks kasutasime eesmärgi-küsimuse-mõõdiku meetodit. Sel konkreetsel juhul oli meil kaks eesmärki:

  • Rändele eelnenud olukorra hindamisel oli meie eesmärk hinnata üldist pingutust. Tulime välja 5 küsimust ja iga küsimuse jaoks määratlesime mõõdikute loendi.
Eesmärk Hinnake jõupingutusi suurema refraktsiooni tegemiseks
  Küsimus Kui suur on toode?
    Metric otstestsenaariumide arv
    Kasutajaliidese komponentide meetriline arv (rakendused, lehed, komponendid)
    REST-lõpp-punktide meetriline arv
    Meetriline arv püsivaid üksusi
    DB päringute metriline arv
    Metric lähtefailide arv
    Metriline arv tehingute ajalugu
    Lähtefailide vanuseline jaotus
  Küsimus Mis on rakenduse kõige olulisemad osad?
    REST-lõpp-punktide metriline järjestamine kasutamise järgi (logidest)
    Metric Stsenaariumide hinnanguline mõju ettevõttele
  Küsimus Kui oluline on refrakteerimine?
    Metric asendatavate raamatukogude / raamistike arv
    Metriline arv uuendatavaid raamatukogusid
    Meetriline delta libide praeguste ja sihtversioonide vahel
    Metric Modifitseeritavate lähtefailide arv
  Küsimus Kui turvaliselt saame refaktorit teha?
    Automatiseeritud testidega otstestsenaariumide meetriline protsent
    Meetriline protsent REST-i lõpp-punktidest koos automatiseeritud testidega
    Metric Code leviala
    Metric Aeg, mis on vajalik rakenduse käsitsi testimiseks
    Metric arendaja sentiment
  Küsimus Kui suurt osa koodist ikkagi kasutatakse?
    Kasutatavate stsenaariumide korral endiselt kasutatavate REST-lõpp-punktide protsendiline protsent
    Stsenaariumide läbimisel hõlmatud koodi meeter%
    Metric arendaja hinnang
  • Rände ajal oli meie eesmärk jälgida edusamme ja värskendada järelejäänud jõupingutusi. Tulime välja 2 küsimusega, mis olid jälle seotud konkreetsete mõõdikutega.
Reaktorite arendamise eesmärk
  Küsimus Kui palju me parandasime turvavõrku?
    Mõõdikute protsent otsast lõpuni koos automatiseeritud testidega + delta
    Meetriline protsent REST-i lõpp-punktidest koos automatiseeritud testidega + delta
    Metric Code leviala + delta
    Metric arendaja sentiment
  Küsimus Mitu "teenust" me kaevandasime ja rändasime üle?
    Meetriline protsent REST-i lõpp-punktidest (koos agregaatidega) migreerunud
    Metric Versioonist eemaldatud lähtefailide arv
    Metric Igal testimise automatiseerimisel kulutatud aeg
    Metric Ajakulu iga ekstraheerimise kohta

Mõõdikute kaevandamine

Kui GQM-i struktuur oli paigas, pidime leidma viisi, kuidas koguda mõõdikuid automatiseeritud viisil. Koodimõõdikute eraldamiseks on meil tööriistad, kuid me ei hakka neid selles postituses arutama. Pigem keskendume järgmisele 2 kõrgema taseme mõõdikutele, mida on raskem koguda:

  • kasutustsenaariumides endiselt kasutatavate REST-lõpp-punktide protsent
  • hõlmatud koodi protsent stsenaariumite läbimisel

Andmete kogumiseks kavandasime süsteemi stsenaariumide registreerimiseks. Süsteem genereerib logifailid, mis seovad kõik stsenaariumid lõpp-punktide ja täidetud meetodite loendiga. Näiteks võime süsteemi kasutada stsenaariumi „Arve loomine” registreerimiseks. Süsteem genereerib metaandmed, mis seovad stsenaariumi 3 REST lõpp-punkti ja 12 meetodiga.

Süsteemi ülesehitamiseks lõime 3 peamist komponenti:

  • Me kasutasime uuritava testimise hõlbustamiseks avatud lähtekoodiga Chrome'i laiendit. See on lihtne viis stsenaariumi alguse ja lõpu registreerimiseks. Tooteomanik saab rakenduse täielikult läbi viia ja anda märku iga üksiku stsenaariumi algusest ja lõpust. See võib anda neile kirjeldavaid nimesid. Salvestamisseansi lõpus annab Chrome'i laiendus meile esimese sündmuste logi koos stsenaariumide ajaliste piiridega.
  • REST API-le saadetud HTTP-taotluste hõivamiseks kasutasime monoliidi ees lihtsat API-lüüsi. See puhverserver annab meile teise sündmuste logi, kus meil on ajatempel igale lõpp-punkti kutsumisele.
  • Lõpuks kasutatakse OpenCloverit rakenduskoodi seadistamiseks ja koodi katvuse mõõdikute genereerimiseks. See annab ajaliselt märgistatud metaandmete kolmanda väljundi.

Siin on kolme genereeritud logifaili lihtsustatud vaade (OpenClover salvestab andmed andmebaasi ja seansside salvestamise protsess on natuke rohkem seotud):

* Sündmuste logi 1 (kroomlaiend)
12:02:00 algus - arve klient
12:03:12 lõpp - arve klient
12:04:10 algus - printige igakuine aruanne
12:05:00 lõpp - printige igakuine aruanne
* Sündmuste logi 2 (API-lüüs)
12:02:04 POST / api / autent
12:02:30 GET / api / kliendid / 93
12:02:49 POST / api / ülesanded / sendInvoice
* Sündmuste logi 3 (OpenClover)
12:02:04 meetod com.acme.controllers.AuthController.login
12:02:04 meetod com.acme.services.AuthService.authenticate
...

Seejärel on neid faile üsna lihtne töödelda. Esimest kasutatakse stsenaariumide vaheliste ajaliste piiride tuvastamiseks. Seejärel kasutatakse neid piirkondi mõjutavate lõpp-punktide ja meetodikutsumiste eraldamiseks. Üks viis nende andmete hõlpsaks kasutamiseks on CSV-faili genereerimine ja seejärel andmete visualiseerimise tööriista nagu Tableau kasutamine.

Järeldus

Muidugi võtab taolise süsteemi seadistamine ja iga kasutusstsenaariumi registreerimine (funktsioonide loetelu koostamine) üsna palju aega.

Kuid kui see on tehtud, on meeskonnal midagi käegakatsutavat ja mõõdetavat koos töötada. Meeskonnal on konkreetne ja kvantitatiivne viis rände edenemise jälgimiseks. Pealegi tunnevad arendajad kiiresti aegunud lõpp-punktide ja surnud koodi hulka.

Nagu me varem ütlesime, peavad meeskonnad seda just väljakutsuva ja valdava ülesande kallale asumiseks. Kas tegemist on keeruka refrakteerimisega, tehnilise võla tagasimaksmise algatusega või automatiseeritud testimispraktika tutvustamise kampaaniaga, saab kasutada sama kõrgetasemelist lähenemisviisi.