Vanamoodsast süsteemist välja saamine

Kümne aastaga kasvanud koodibaas kannab endas palju otsuseid, mille tegemise põhjus on ammu ununenud. Iga muudatus algab uurimisest - mida see katki teha võib? - ja kuna automaatteste pole, testitakse muudatust tihti alles otse elaval saidil. Uue versiooni avaldamine on käsitsi ja võtab kaks tundi, ning igaüks, kes seda teinud on, teab selle pinget. Suurim oht pole kokkujooksmine, vaid see, et süsteem muutub liiga hirmutavaks, et seda puutuda - nii jäävad uued funktsioonid tegemata ja konkurendid lähevad mööda.

Mõte on lihtne: vana süsteemi ei lülitata välja enne, kui uus osa on valmis üle võtma. Alustame auditist - paneme kirja, mis on olemas, mis on kõige halvemas seisus ja mis tekitab kõige rohkem peavalu. Seejärel võtame ühe selgelt piiritletud osa, näiteks sisselogimise või tootekataloogi, ja ehitame selle korralikult uuesti, koos testidega. Liiklus suunatakse uuele versioonile järk-järgult, iga nädalaga veidi rohkem, kuni vana osa saab vaikselt välja lülitada. Äri töötab kogu aeg edasi.

Kogu töö vältel pole olnud ühtegi planeeritud seisakut ega ühtki riskantset üleminekuhetke. Versiooni avaldamine, mis võttis kaks tundi, kestab nüüd kaheksa minutit ja käib ise. Meeskond saab iga nädala lõpus uue osa elavale saidile panna ilma pikkade aruteludeta, kas see on ohutu - testid vastavad selle eest. Vähem aega kulub tulekustutamisele ja rohkem päris arendamisele.

Kõige raskem oli peidetud sõltuvuste leidmine - kümne aastaga tekkinud kaudsed seosed osade vahel, mida ükski dokument ei kajasta. Jälgisime, mis on tegelikult omavahel seotud, vaadates kuidas süsteem käitub ja milliseid päringuid teeb. Teine väljakutse oli inimlik: kui teste pole, tundub iga muudatus ohtlik, ja meeskond oli muutunud ettevaatlikuks. Esimesed nädalad läksid suuresti olemasolevate funktsioonide testide kirjutamisele - alles siis sai ümberehitus hoo sisse.