Започнете модернизацията на остаряло приложение, като запишете защо то трябва да се промени, след което оценете кода и продукционната среда заедно. Стабилизирайте системата и обградете с тестове поведението, от което бизнесът зависи, преди да променяте структурата ѝ. С тази предпазна мрежа заменяйте системата част по част, премествайте данните обмислено и оставете пълното пренаписване за редките случаи, в които малко неща си струва да се запазят.
Назовете бизнес причината, преди да докоснете кода
Модернизацията е скъпа, затова започнете от причината. Честите причини са среда за изпълнение или рамка с изтекла поддръжка, промени, които отнемат седмици, защото всяко издание разваля нещо, система, която само един човек разбира, или платформа, която не може да поеме следващите нужди на бизнеса. Всяка причина сочи към различна първа стъпка.
Запишете причината заедно с показател, който можете да проверите по-късно, например колко често пускате издания, колко инцидента имате или колко време отнема на типична промяна да стигне до потребителите. Без него модернизацията се превръща в инженерен проект без край, който е трудно да защитите при следващия преглед на бюджета.
Оценете кода и продукционната среда, преди да решите каквото и да е
Оценката Ви казва какво всъщност имате. Нека е кратка и да завършва с писмен доклад и препоръчана първа стъпка. Четете кода, но четете и продукционната среда: дневници, инциденти, бавни заявки и начина, по който се правят изданията. Най-лошите проблеми често са около кода, а не в него.
- Версиите на средата за изпълнение, рамката и библиотеките и кои от тях вече не получават поправки за сигурност
- Кои части се променят най-често и кои се чупят най-често, според историята на версиите и дневника на инцидентите
- Покритието с тестове на пътищата, от които бизнесът зависи
- Как приложението се компилира, конфигурира и внедрява и кой може да го прави
- Моделът на данните, размерът му и кои други системи четат от същата база данни или пишат в нея
- Хората, които познават системата, и това, което само те знаят
Първо стабилизирайте продукционната среда, за да има работата стабилна основа
Ако системата се срива всяка седмица, модернизацията ще бъде прекъсвана всяка седмица. Първо поправете това, което причинява инциденти: добавете наблюдение и известия за критичните пътища, автоматизирайте компилирането и деплоя, за да са изданията повторяеми, и изнесете тайните и конфигурацията извън кода.
Тези стъпки се отплащат веднага и правят всяка следваща стъпка по-безопасна. Те показват и рано дали екипът може да променя системата, без да я разваля, което си струва да знаете, преди да се ангажирате с по-голям план.
Изградете предпазна мрежа от тестове около поведението, на което разчитате
Остарелият код обикновено има малко тестове, а документираното му поведение рядко съвпада с реалното. Преди да промените структурата, напишете характеризиращи тестове: тестове, които записват какво прави системата днес, включително странните ѝ гранични случаи, така че всяка промяна в поведението да се прояви като неуспешен тест.
Започнете от краищата, с тестове, които извикват приложението през неговия API или потребителски интерфейс и проверяват резултатите, защото те оцеляват при вътрешни промени. За изчисления и отчети пуснете реални входни данни през стария и новия код и сравнете резултатите. Добавяйте по-детайлни тестове към всяка част, докато я преработвате. Нашата статия за обновяването на критично приложение на Java 8 показва същата предпазна мрежа, приложена при обновяване на средата за изпълнение.
Заменяйте системата част по част, вместо да я пренаписвате
Пълното пренаписване изглежда чисто на хартия, но старата система продължава да работи и да се променя, докато новата я догонва, а всяко недокументирано поведение трябва да се открие наново по пътя. Затова пренаписванията толкова често отнемат повече от планираното, докато бизнесът чака.
Обичайната алтернатива е моделът strangler fig („удушаващата смокиня”). Поставете слой за маршрутизиране, например обратен прокси сървър или API шлюз, пред остарялото приложение. Изграждайте по една функционалност в новия код и пренасочвайте трафика за нея към него, щом се докаже. Старата система се свива, докато не може да бъде изключена, а бизнесът получава стойност на всяка стъпка.
Пренаписването все пак може да е правилното решение: когато кодовата база е малка и поведението ѝ е добре разбрано или когато платформата, на която работи, не може да се поддържа жива достатъчно дълго за постепенна замяна. Решавайте по писмени критерии, а не от раздразнение.
Третирайте данните като отделна миграция
Кодът може да се заменя на части; данните се разделят по-трудно. Докато старият и новият код споделят една база данни, всяка промяна в схемата трябва да се координира. Решете рано коя система е източникът на истината за всеки вид данни и избягвайте две системи да записват един и същ запис без правило кой запис печели.
Когато една функционалност се премести, премествайте или синхронизирайте данните ѝ обмислено: скриптове за миграция, тествани върху копие на продукционната среда, или непрекъсната синхронизация, докато двете системи работят. Планирайте как ще съгласувате двете, например с ежедневни преброявания и контролни суми, и запазете възможността да превключите обратно, докато числата не съвпаднат.
Подредете работата по риск и стойност и покажете напредък рано
Подредете работата така, че всяка стъпка или да намалява риска, или да дава нещо, което бизнесът може да види. Често срещана последователност е стабилизиране и автоматизация, добавяне на тестове, обновяване на средата за изпълнение и след това извличане на функционалностите, които се променят най-често. Частите, които са стабилни и рядко се пипат, могат да почакат, понякога безкрайно.
Поддържайте плана кратък и го преглеждайте след всяка стъпка, защото наученото ще промени реда. Нашите инженери са работили по този начин по критични системи. Чрез Sopra Steria те ръководиха миграция от Java 8 към 16 на критично приложение за дневна търговия с газ, а като част от екипа на облачната програма на Crédit Agricole оценявахме всяко приложение, което мигрирахме, за да решим дали да го обновим, или да го изградим наново. Ако искате оценка на собствената си система или екип, който да изпълни плана, SDK Enterprises прави и двете по един договор.
Основното накратко
- Запишете бизнес причината за модернизацията, заедно с показател, който можете да проверите по-късно.
- Оценете кода и продукционната среда заедно, преди да избирате между обновяване, постепенна замяна и пренаписване.
- Стабилизирайте продукционната среда и обградете критичното поведение с характеризиращи тестове, преди да променяте структурата.
- Заменяйте системата част по част зад слой за маршрутизиране, освен ако пренаписването не е явно по-малко и по-безопасно.
- Планирайте собствеността върху данните, синхронизацията и съгласуването като отделна миграция.
Въпроси и отговори
Да пренапишем ли остарялото си приложение от нулата?
Обикновено не. Пренаписването се състезава със система, която продължава да се променя, и трябва да открие наново поведение, което никой не е документирал. Заменяйте постепенно, освен ако кодовата база не е малка и добре разбрана или обвързана с платформа, която не може да продължи да работи.
Колко време отнема модернизацията на остаряло приложение?
Зависи от размера на системата, покритието ѝ с тестове, доколко са заплетени данните ѝ и колко трябва да се промени. Кратката оценка Ви дава реалистичен план и първа стъпка, достатъчно малка, за да я завършите и измерите, вместо една дата за цялото усилие.
Можем ли да продължим да пускаме нови функции, докато модернизираме?
Да, и трябва. Постепенната замяна позволява на екипа да доставя функции в новия код, докато старата система продължава да работи. Договорете каква част от времето на екипа отива за модернизацията, за да не я погълне незабелязано работата по функциите.