#Легаси. Часть II - комментарий с хабра №1.3
Вы обвешиваете окошки счетчиками показов, и убираете то, в котором счетчик показывает «1», и вас вызывают на ковер к начальству, потому что этой функцией пользовался очень-очень иногда аналитик этого начальства для важного отчета, а сейчас отчет сделать нельзя, и начальство это очень расстраивает.
Вы сливаете два окошка в одно, и в хелпдеске начинают копиться возмущения: легаси делалось десятилетиями, и пользователи им пользуются теми же десятилетиями. Нет системы доставки документации и обучения пользователей, потому что функции добавляются по одной и в ответ на запрос. Нет простого способа обучить тысячи пользователей новому методу работы. Нет ни единого центра документации, ни списка изменений, ни способа уведомить пользователей о изменениях, ни культуры читать документацию и уведомления. И это важное легаси, критичное для бизнеса, в отличии от еще одного сайта-с-мессенжером, где если пользователь свалит, невелика беда.
Вы остаетесь наедине с огромной кучей кода, которая возможно, нужна вся. Ничего нельзя взять и выбросить. Нельзя взять и переписать, потому что для переписывания можно либо повторить всю эту логику на другом стеке (а смысл, если это не решит проблем с архитектурой), либо написать ТЗ на систему не по коду, а по логике верхнего уровня (привет, восстановление контекста через интервью с бывшим сотрудником, ушедшим на пенсию), и на основании него написать новую систему (а реверс ТЗ по зрелой системе — это минимум раза в два-три больше времени, чем кодирование этого ТЗ). И это реально инвестиционный проект, на который надо обосновать бюджет миллионов эдак в 100, звать интегратора с отделом разработки или поставщика похожего решения, который будет адаптировать свою систему под ваши требования. Силами того отдела, что разработал этого монстра, сделать такое невозможно, потому что скиллы нужны немного другие. И новую систему надо внедрить одномоментно и всеобъемлюще, потому что нельзя пользоваться двумя система одновременно.
Единственное, что может сделать отдел разработки — только аккуратно разбираться с каждой фичей, как с детонатором бомбы, обвешивая ее тестами, и потом аккуратно перенося в часть кода с правильной архитектурой. Но это занимает адовое количество времени, все равно вносит баги, и требует безумно большого скилла убеждения бизнеса, чем будет заниматься три года отдел разработки, что генерирует баги и не приносит прибыль, но вот через три года, возможно, снизит стоимость разработки новых фич.