Modificați în siguranță un sistem existent
TerminatPăstrați contractele actuale când introduceți o modificare. Luați în calcul clienții vechi, datele și ordinea instalării în mediu.
Publicat de TaigaCum scriem
Verificați ce ați înțelesRedenumiți o coloană din baza de date și actualizați aplicația în aceeași lansare. Ce mai poate eșua?Faceți exercițiul
Ce veți învăța
- Identificați contractele pe care le poate afecta o modificare locală de cod.
- Explicați o modificare etapizată de extindere și restrângere.
- Deosebiți revenirea codului la o versiune anterioară de recuperarea datelor.
Identificați contractele din jurul modificării
Software-ul existent are apelanți, date stocate, sarcini programate și proceduri operaționale. Unele dependențe nu sunt vizibile în fișierul pe care doriți să îl editați. Un agent poate produce o modificare corectă local care încalcă unul dintre aceste contracte.
Înainte de implementare, identificați componentele care citesc și scriu datele afectate. Inspectați rutele, sarcinile de fundal, rapoartele și integrările externe. Verificați dacă alte echipe sau versiuni mai vechi ale clienților depind de comportamentul actual.
Cereți agentului să prezinte dovezile pentru această hartă. Un rezultat de căutare este un punct de plecare util. Însă apelurile dinamice și sistemele externe care folosesc datele pot necesita confirmarea dependenței de către un responsabil.
Faceți comportamentul actual observabil
Pentru un modul slab documentat, adăugați verificări concentrate pe comportamentul care trebuie să rămână stabil. Ele descriu contractul actual. Nu dovedesc că fiecare comportament existent este de dorit.
Dacă comportamentul actual contrazice o cerință, consemnați conflictul. Nu păstrați un defect de securitate doar pentru că un test l-a înregistrat. Obțineți decizia necesară pentru a deosebi comportamentul intenționat de un defect.
Folosiți date de test realiste, fără informații sensibile. Includeți forme vechi ale datelor și înregistrări incomplete acolo unde pot apărea. O schemă nouă testată doar cu date nou-create poate ascunde probleme de migrare.
Verificați tranziția dintre versiuni
Luați în considerare o redenumire fictivă din customer_name în display_name. Redenumirea imediată poate afecta o instanță veche a aplicației în timpul instalării noii versiuni. Actualizarea ambelor fișiere într-un singur pull request nu face instalarea atomică.
O abordare etapizată poate păstra compatibilitatea:
- Adăugați câmpul nou fără a-l elimina pe cel vechi.
- Definiți cum păstrează noile scrieri consecvența valorilor necesare.
- Completați retroactiv înregistrările existente printr-un proces care poate fi reluat.
- Verificați completitudinea și comportamentul componentelor care citesc datele.
- Mutați citirile pe câmpul nou.
- Eliminați câmpul vechi numai după ce nu mai există componente care îl folosesc.
Metoda exactă depinde de baza de date și de tiparele de scriere. Scrierile duble pot introduce inconsecvențe dacă una eșuează. Poate fi necesară o tranzacție de bază de date sau altă metodă explicită de sincronizare. Nu aplicați exemplul fără a verifica garanțiile sistemului.
Martin Fowler descrie această tranziție generală ca modificare paralelă, numită și expand-and-contract. Ideea principală este o tranziție compatibilă înainte de eliminare.
Planificați recuperarea separat de revenirea la o versiune anterioară
Revenirea codului restaurează o versiune anterioară a aplicației. Nu anulează automat o migrare de date. Versiunea veche poate să nu înțeleagă datele noi. O migrare distructivă poate elimina informații pe care revenirea codului nu le poate recupera.
Identificați acțiunea de recuperare pentru fiecare pas. O completare retroactivă proiectată să poată fi reluată poate fi continuată în siguranță. O transformare greșită poate necesita o corecție din datele sursă păstrate. O operațiune distructivă poate necesita o procedură verificată de restaurare.
Întrebați cine răspunde de decizia de recuperare și cât timp poate dura. Nu tratați „avem copii de siguranță” ca dovadă că recuperarea îndeplinește cerința serviciului.
Păstrați modificarea ușor de verificat
Separați curățarea fără legătură de modificarea funcțională. Includeți în pull request planul de compatibilitate, rezultatele verificării și condițiile de eliminare. Marcați punctul după care revenirea la versiunea anterioară necesită lucru suplimentar.
Un agent poate ajuta la inspectarea componentelor care folosesc datele și la pregătirea codului de migrare. Un responsabil trebuie totuși să accepte planul de tranziție și recuperare. Proiectarea finală este doar o parte a unei modificări sigure.
Faceți exercițiul
Alegeți o modificare mică de câmp sau API. Enumerați toate componentele care citesc și scriu, inclusiv sarcinile de fundal. Descrieți un prim pas aditiv, o verificare a tranziției și o condiție de eliminare. Identificați pasul care ar putea împiedica revenirea la versiunea anterioară.
Descărcați fișa de lucru (Markdown)Debifarea acestei opțiuni șterge tot progresul salvat în acest browser.
Progresul rămâne în acest browser. Fără cont, fără urmărire.