Varno spremenite obstoječi sistem

Prepoznajte dogovore vmesnikov okoli spremembe

Obstoječa programska oprema ima klicatelje, shranjene podatke, načrtovana opravila in operativne postopke. Nekatere odvisnosti niso vidne v datoteki, ki jo želite urediti. Agent lahko ustvari lokalno pravilno spremembo, ki krši enega od teh dogovorov.

Pred izvedbo ugotovite, katere komponente berejo in zapisujejo prizadete podatke. Preglejte poti zahtev, opravila v ozadju, poročila in zunanje integracije. Preverite, ali so druge ekipe ali starejše različice odjemalcev odvisne od trenutnega delovanja.

Agent naj pokaže dokazila za ta pregled odvisnosti. Rezultat iskanja je uporabno izhodišče, vendar mora dinamične klice in zunanje uporabnike vmesnika morda potrditi odgovorna oseba.

Omogočite opazovanje trenutnega delovanja

Pri slabo dokumentiranem modulu dodajte osredotočena preverjanja delovanja, ki mora ostati nespremenjeno. Ta preverjanja opisujejo trenutni dogovor vmesnika. Ne dokazujejo, da je vse obstoječe delovanje zaželeno.

Če je trenutno delovanje v nasprotju z zahtevo, zabeležite neskladje. Varnostne napake ne ohranite zgolj zato, ker jo je test zajel. Pridobite odločitev, ki loči predvideno delovanje od napake.

Uporabite realistične testne podatke brez občutljivih informacij. Vključite stare oblike podatkov in nepopolne zapise, kjer se lahko pojavijo. Nova shema, preizkušena samo z na novo ustvarjenimi podatki, lahko skrije težave migracije.

Preglejte prehod med različicami

Oglejte si izmišljeno preimenovanje iz customer_name v display_name. Takojšnje preimenovanje lahko med namestitvijo pokvari delovanje starega primerka aplikacije. Posodobitev obeh datotek v enem pull requestu ne naredi namestitve atomarne.

Postopen pristop lahko ohrani združljivost:

1. Dodajte novo polje, ne da bi odstranili staro.
2. Določite, kako bodo nove operacije zapisovanja ohranjale skladnost zahtevanih vrednosti.
3. Obstoječe zapise dopolnite s postopkom, ki ga je mogoče ponovno zagnati.
4. Preverite popolnost podatkov in delovanje komponent, ki jih berejo.
5. Komponente, ki berejo podatke, preusmerite na novo polje.
6. Staro polje odstranite šele, ko ga nobena komponenta več ne uporablja.

Natančna metoda je odvisna od podatkovne zbirke in vzorcev pisanja. Pisanje v obe polji lahko povzroči neskladje, če ena od operacij zapisovanja ne uspe. Morda je potrebna transakcija podatkovne zbirke ali druga izrecna metoda sinhronizacije. Primera ne uporabite brez preverjanja zagotovil sistema.

Martin Fowler ta splošni prehod opisuje kot vzporedno spremembo, imenovano tudi expand-and-contract. Ključna zamisel je združljiv prehod pred odstranitvijo.

Obnovo načrtujte ločeno od povrnitve kode

Povrnitev kode vzpostavi prejšnjo različico aplikacije. Ne razveljavi samodejno migracije podatkov. Stara različica morda ne razume novih podatkov. Destruktivna migracija lahko odstrani informacije, ki jih povrnitev kode ne more obnoviti.

Za vsak korak določite dejanje obnove. Postopek dopolnitve podatkov, ki podpira ponovni zagon, je morda varno nadaljevati. Napačna pretvorba lahko zahteva popravek iz ohranjenih izvornih podatkov. Destruktivno dejanje lahko zahteva preverjen postopek obnove.

Določite, kdo je odgovoren za odločitev o obnovi in koliko časa lahko traja. Trditve »imamo varnostne kopije« ne obravnavajte kot dokazila, da obnova izpolnjuje zahteve storitve.

Ohranite možnost pregleda spremembe

Nepovezano čiščenje kode ločite od funkcionalne spremembe. V pull request vključite načrt združljivosti, rezultate preverjanj in pogoje za odstranitev. Označite točko, po kateri povrnitev na prejšnjo različico zahteva dodatno delo.

Agent lahko pomaga pregledati uporabnike vmesnika in pripraviti kodo za migracijo. Odgovorna oseba mora še vedno sprejeti načrt prehoda in obnove. Končna zasnova je samo en del varne spremembe.