Риски, анализ текущей ситуации и стратегии работы с унаследованными системами

В 9 главе I раздела я описал один из вариантов того, как IT-проект может катиться к провалу из-за слабых технических специалистов и неподготовленных заказчиков. Результатом такого движения будут нарушенные сроки релиза, много плохого кода, негодующие пользователи и грустные инвесторы. После осознания того, что проект идёт к провалу, его отдают команде, которая берёт на себя миссию по спасению, переписыванию или «выпиливанию».

Сейчас я хочу рассмотреть более общий вариант работы со старыми или плохо работающими системами. Хочу дать ответ на вопрос, что делать, если вам досталась в работу legacy system? В этой главе я буду использовать термины legacy system[88] (унаследованная система) и legacy code[89] (унаследованный код).

Вообще, унаследованный – не значит плохой по умолчанию. Бывают унаследованные системы с отличной архитектурой и документацией. Но в этой главе термин унаследованный будет иметь негативную окраску. Я буду говорить о проектах с проблемами в архитектуре, плохим кодом, отсутствием тестов и документации. В этих системах бывает много чего «так исторически сложилось», «это лучше не трогать», использованы устаревшие фреймворки, подходы к разработке, языки программирования и СУБД.