Sigurno promijenite postojeći sistem

Utvrdite ugovore o ponašanju oko promjene

Postojeći softver ima kod koji ga poziva, pohranjene podatke, zakazane zadatke i operativne postupke. Neke zavisnosti nisu vidljive u fajlu koji želite urediti. Agent može proizvesti lokalno tačnu promjenu koja krši jedan od ovih ugovora o ponašanju.

Prije implementacije utvrdite komponente koje čitaju i pišu zahvaćene podatke. Pregledajte rute, pozadinske zadatke, izvještaje i vanjske integracije. Provjerite zavise li drugi timovi ili starije verzije klijentskog softvera od trenutnog ponašanja.

Zatražite da agent pokaže dokaze za ovaj pregled zavisnosti. Rezultat pretrage korisna je početna tačka, ali dinamički pozivi i vanjske komponente koje koriste podatke mogu zahtijevati potvrdu odgovorne osobe.

Učinite trenutno ponašanje vidljivim

Za slabo dokumentovan modul dodajte usmjerene provjere ponašanja koje mora ostati stabilno. Ove provjere opisuju trenutni ugovor o ponašanju. Ne potvrđuju da je svako postojeće ponašanje poželjno.

Ako je trenutno ponašanje u sukobu sa zahtjevom, zabilježite sukob. Nemojte sačuvati sigurnosnu grešku samo zato što je test zabilježio takvo ponašanje. Pribavite odluku potrebnu da razlikujete namjeravano ponašanje od greške.

Koristite realistične testne podatke bez osjetljivih informacija. Uključite stare strukture podataka i nepotpune zapise tamo gdje se mogu pojaviti. Nova shema podataka testirana samo s novonastalim podacima može sakriti probleme migracije.

Pregledajte prijelaz između verzija

Razmotrite izmišljeno preimenovanje iz customer_name u display_name. Neposredno preimenovanje može prekinuti rad stare instance aplikacije tokom raspoređivanja. Ažuriranje oba fajla u jednom zahtjevu za spajanje koda ne čini raspoređivanje atomskim.

Fazni pristup može sačuvati kompatibilnost:

1. Dodajte novo polje bez uklanjanja starog.
2. Odredite kako će nova pisanja održavati potrebne vrijednosti usklađenim.
3. Dopunite postojeće zapise postupkom koji se može ponovo pokrenuti.
4. Provjerite potpunost i ponašanje komponenti koje čitaju podatke.
5. Prebacite komponente koje čitaju podatke na novo polje.
6. Uklonite staro polje tek kada više nema komponenti koje ga koriste.

Tačna metoda zavisi od baze podataka i obrazaca pisanja. Dvostruko pisanje može izazvati nedosljednost ako jedno pisanje ne uspije. Može biti potrebna transakcija baze podataka ili druga izričita metoda sinhronizacije. Nemojte primijeniti ovaj primjer bez provjere garancija sistema.

Martin Fowler opisuje ovaj opći prijelaz kao paralelnu promjenu, poznatu i kao expand-and-contract. Ključna ideja je kompatibilan prijelaz prije uklanjanja.

Planirajte oporavak odvojeno od vraćanja koda

Vraćanje koda na prethodnu verziju vraća raniju verziju aplikacije. Ne poništava automatski migraciju podataka. Stara verzija možda ne razumije nove podatke. Destruktivna migracija može ukloniti informacije koje vraćanje koda ne može oporaviti.

Utvrdite radnju oporavka za svaki korak. Dopunu podataka koja se može ponovo pokrenuti možda je sigurno nastaviti. Pogrešna transformacija može zahtijevati ispravku iz sačuvanih izvornih podataka. Destruktivna operacija može zahtijevati provjeren postupak vraćanja podataka.

Pitajte ko je odgovoran za odluku o oporavku i koliko on može trajati. Izbjegavajte tretirati „imamo rezervne kopije“ kao dokaz da oporavak ispunjava zahtjev usluge.

Ograničite promjenu tako da se može pregledati

Odvojite nepovezano čišćenje od funkcionalne promjene. U zahtjevu za spajanje koda navedite plan kompatibilnosti, rezultate provjere i uslove uklanjanja. Označite tačku nakon koje vraćanje na prethodnu verziju zahtijeva dodatni rad.

Agent može pomoći u pregledu komponenti koje koriste podatke i pripremi migracijskog koda. Odgovorna osoba i dalje mora prihvatiti plan prijelaza i oporavka. Konačni dizajn samo je jedan dio sigurne promjene.