Что такое настоящий легаси-код? Мнение
Настоящее легаси — это тонны кода, оперирующие коэффициентами, про которые никто не помнит, откуда они взялись. Куски кода и системы на устаревших языках, которых вы не понимаете. Система, построенная на логике, которую вы не понимаете. Потоки данных, ходящих такими путями, которые вы не понимаете. Устаревшее железо в серверных, которое поддерживается контракторами с интеграторами, которые держат на складах это железо исключительно ради вас, потому что купить его уже лет десять как нельзя, но и нельзя поменять на новое, потому что на нем не заработает версия операционки и окружения.
Решения в коде, которые вы не понимаете. Просто потому, что за 10 лет поменялись принципы разработки, среды и средства разработки и доступные ресурсы, наконец. Форматы данных, затерянные в веках, пользовательский экcплорер для которых запускается исключительно на win98. Важная БД, которая работает под OS/2. Сделайте, блин, модельку этого сервиса за неделю.
Настоящее легаси — это когда у вас есть ветка кода, которая вроде бы не нужна, но трогать вам ее никто не даст, потому что нет критериев верификации работы системы после ее удаления. Никто просто не знает, в самом ли деле она не нужна. И проверить нельзя — на системе работает компания годами, и десяток трейсов в попытках понять, запускается ли она, вам ничего не дадут: вполне возможно, что она запускается по сочетанию високосного года и перехода на другую систему налогообложения, и вставлена туда после прошлого глюка, который стоил компании Х миллионов. Уберете сейчас — а через два года опять потеряете деньги. Один конкретный вопрос еще можно как-то решить, но их в коде зрелой системы тысячи, и они равномерно перемешаны с действительно ненужными кусками кода, которые мешают строить нормальную архитектуру.
Настоящее легаси — это реально тонны кода и тысячи окошек интерфейсов, которыми пользуются тысячи людей. Вы убираете одно окошко, и в конце месяца работа банка встает, потому что именно в нем раз в месяц смотрели статистику. Вы обвешиваете окошки счетчиками показов, и убираете то, в котором счетчик показывает «1», и вас вызывают на ковер к начальству, потому что этой функцией пользовался очень-очень иногда аналитик этого начальства для важного отчета, а сейчас отчет сделать нельзя, и начальство это очень расстраивает.
Вы сливаете два окошка в одно, и в хелпдеске начинают копиться возмущения: легаси делалось десятилетиями, и пользователи им пользуются теми же десятилетиями. Нет системы доставки документации и обучения пользователей, потому что функции добавляются по одной и в ответ на запрос. Нет простого способа обучить тысячи пользователей новому методу работы. Нет ни единого центра документации, ни списка изменений, ни способа уведомить пользователей о изменениях, ни культуры читать документацию и уведомления. И это важное легаси, критичное для бизнеса, в отличии от еще одного сайта-с-мессенжером, где, если пользователь свалит, невелика беда.
Вы остаетесь наедине с огромной кучей кода, которая возможно, нужна вся. Ничего нельзя взять и выбросить. Нельзя взять и переписать, потому что для переписывания можно либо повторить всю эту логику на другом стеке (а смысл, если это не решит проблем с архитектурой), либо написать ТЗ на систему не по коду, а по логике верхнего уровня (привет, восстановление контекста через интервью с бывшим сотрудником, ушедшим на пенсию), и на основании него написать новую систему (а реверс ТЗ по зрелой системе — это минимум раза в два-три больше времени, чем кодирование этого ТЗ). И это реально инвестиционный проект, на который надо обосновать бюджет миллионов эдак в 100, звать интегратора с отделом разработки или поставщика похожего решения, который будет адаптировать свою систему под ваши требования. Силами того отдела, что разработал этого монстра, сделать такое невозможно, потому что скиллы нужны немного другие. И новую систему надо внедрить одномоментно и всеобъемлюще, потому что нельзя пользоваться двумя системами одновременно.
Единственное, что может сделать отдел разработки — только аккуратно разбираться с каждой фичей, как с детонатором бомбы, обвешивая ее тестами, и потом аккуратно перенося в часть кода с правильной архитектурой. Но это занимает адовое количество времени, все равно вносит баги, и требует безумно большого скилла убеждения бизнеса, чем будет заниматься три года отдел разработки, что генерирует баги и не приносит прибыль, но вот через три года, возможно, снизит стоимость разработки новых фич.
Источник -- комментарий на хабре.
Автор -- @vvzvlad.