Legacy что такое: Что такое легаси в коде — Журнал «Код»

Что такое легаси в коде — Журнал «Код»

Иногда программисты на вопрос, почему программа работает именно так, отвечают, что это «легаси» и исправить ничего нельзя. Разберёмся, что это значит, насколько это мешает разработке и что делают с легаси-кодом.

За что не любят программистов

Что такое легаси

С английского legacy переводится как «наследие». Легаси-код — это код, который перешёл «по наследству» от предыдущих разработчиков. Чаще всего это происходит так:

1. Команда делает продукт, внутри много разных возможностей.
2. Часть функций со временем оптимизируется, а часть остаётся неизменной в виде старого кода, потому что и так работает.
3. Некоторое время спустя в команде не остаётся тех, кто писал старый код.
4. Текущая команда не знает, почему старый код написан именно так.
5. В этих кусках сложно что-то поменять или разобраться, потому что всё остальное написано уже по-другому.
6. Этот старый код, который сложно поддерживать и сложно разбираться — это и есть легаси.

👉 Проще говоря, легаси — это код, про который говорят: «Это ещё Михалыч писал 8 лет назад для синхронизации с сервером, он работает, мы его не трогаем, потому что иначе всё сломается». При этом Михалыча в компании давно нет, документации тоже нет, и проще этот код не трогать совсем.

Так как легаси — это старый код, то обычно на него завязаны многие важные вещи в программе. Получается замкнутый круг: отказаться от легаси нельзя, потому что без него всё сломается, но и поддерживать его в рабочем состоянии тоже сложно, потому что никто не хочет разбираться в старом коде.

Откуда берётся легаси

Причин появления легаси может быть несколько:

• команда перешла на другой фреймворк, но части программы остались на старом;
• часть программы написана на старой версии языка;
• старая команда не задокументировала свой код;
• код написан в одном стиле, а команда давно перешла на другой стиль программирования.

Легаси — это не какое-то преступление, а часть жизни любой живой ИТ-компании. Рано или поздно у любого продукта появится легаси. И чем крупнее проект, тем больше его будет. Например, в исходном коде Windows 10 до сих пор остаются фрагменты кода, написанные ещё 20 лет назад для Windows 3.1.

Легаси — это плохо?

Легаси — это просто старый код, который нужно поддерживать наравне с новым. Если он работает — отлично, пусть живёт. Другое дело, что команде, например, было бы удобнее, чтобы код был написан не на старом фреймворке, а на новом, который знают все.

Получается, главный минус легаси-кода не в том, что он работает плохо, а в том, что его неудобно поддерживать.

Что значит «поддерживать старый код»?

Например, в старом коде для запроса к серверу идёт сначала адрес, а потом номер запроса. Спустя 10 лет требования сервера изменились, поэтому сначала должен идти запрос, а потом уже адрес. Значит, нужно изменить порядок полей в коде.

Если старый код понятен и хорошо задокументирован, на эту задачу уйдёт две минуты. Если это старые пыльные легаси-кишки, то это может стать задачей на час.

Что делать с легаси-кодом

Если легаси-код работает и не требует вмешательства и поддержки — то можно пока ничего не делать, пусть работает. Будет время — перепишем на новый фреймворк, а если нет, то и так пока поработает.

А если нужно срочное вмешательство — пахнет бедой. Зовите менеджеров. 

Текст:

Михаил Полянин

Редактор:

Максим Ильяхов

Художник:

Алексей Сухов

Корректор:

Ирина Михеева

Вёрстка:

Кирилл Климентьев

Соцсети:

Виталий Вебер

Риски, анализ проекта и стратегии работы

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

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

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

Что такое унаследованная система?

Какие признаки можно выделить для унаследованных систем:

• Реализованы на старых технологиях и платформах
• Используются устаревшие подходы к разработке, дизайну и архитектуре
• Нет модульных и интеграционных тестов. Может при текущем дизайне вообще нельзя написать модульные тесты?
• В систему трудно вносить изменения, она хрупкая, ломается в неожиданных местах, в целом может быть низкое качество кода
• Плохой нечитаемый код со множеством запахов, иногда непонятно почему он вообще работает
• Не автоматизированы рутинные операции, что периодически приводит к однотипным ошибкам и повышает bus-фактор.
• Нет документации по системе и инфрастуктуре

Возникает ощущение, что проект с такими характеристиками не будет радовать вас изо дня в день. Скорее станет вашей головной болью.

Как системы становятся унаследованными? Можно выделить несколько популярных сценариев:

1. Разработка началать много лет назад, за это время было реализовано много различной функциональности. Команды уже несколько раз полностью сменились. Разные части системы написаны в разном стиле. Такая система является большой ценностью для заказчика. Возможно система немного нестабильна, но для заказчика это не столь критично.
2. Система разрабатывалась недолго, но командой с низкой технической компетентностью. Код оброс техническими долгами, является очень хрупким. Система почти остановила свое развитие и ждет героя, который проведет правильный рефакторинг. Изменения в системе, как и в предыдущем пункте, будут осложнятся тем, что ее уже используют в работе.
3. Разработка первой версии оказалась неудачной (например, команда не справилась), система не была запущена. Теперь нужно сделать выводы из первого провала и реализовать всё как полагается.
4. Ваша текущая система, которая раньше была такой небольшой и понятной, превращается в ужасного монстра, который выходит из под контроля. Нужно сломить ситуацию и сделать ее управляемой.

Риски и ответственность

Какие риски могут вас ожидать:

• Унаследованные системы зачастую очень важны для заказчика. Этими системами уже пользуются, они уже приносят деньги, поэтому ошибки в коде могут очень дорого стоить.
• Если система уже была запущена, то пользователи научились с ней работать, обходить проблемы, которые она содержит. Например, вы наверняка слышали в магазинах: «Сейчас система зависла, надо подождать немного, потом перезагрузить компьютер, потом я проведу оплату еще раз. Ничего страшного так бывает». Ваша новая реализация может быть будет лучше, но не забывайте про переобучение пользователей
• Знания об истории развития унаследованной системы могут быть потеряны, поэтому вы рискуете забыть реализовать функциональность, которая была в старой системе
• Или просто сломать то, что уже работает
  Например, недавно мы рефакторили большую систему, она заливалась на несколько идентичных серверов для баланса нагрузки. Как оказалось, только на одном из них в файле конфигурации менялся параметр, чтобы один из сервисов запускался. Информации об этом нигде не было. Через месяц узнали случайно от разработчика из предыдущей команды.
• Из-за проблем в коде можно не сделать поставку новых функций к планируемой дате
• Обычно работа идет под давлением сроков и большого количества технических долгов, это грозит потерей мотивации в команде
• На некоторое время будет замедление разработки, т.к. вы будете входить в проект. Надо убедиться, что заказчик готов к этому

Допустим, взвесив все риски, вы согласились взяться за работу. В этот момент надо понять важную вещь. Для заказчика не будет разделения на «наш код» и «не наш код». Код теперь весь ваш, вы с ним работаете. Возникли неожиданные проблемы в неожиданном месте? Теперь это ваша проблема. Вы в этом не виноваты? Код был хрупким и поэтому всё сломалось? Для заказчика теперь вы отвественный за код, вам и решать все проблемы. Приготовьтесь к тому, что будете искать, отлаживать, профилировать унаследованную систему значительное время.

С точки зрения условий контракта я бы рекомендовал работать с унаследованными системами по T&M. Это частично снизит ваши риски. Работа по фиксированной цене и объему работы может быть опасна, т.к. унаследованные системы несут много сюрпризов. Есть риск сильно ошибиться, неправильно оценив объем работы.

Анализ унаследованной системы

Перед началом работы нужно понять, что уже реализовано и как это работает. Текущую функциональность надо изучить, измерить и описать, чтобы в дальнейшем были метрики и флаги, которые не дадут сделать хуже, чем было. По возможности нужно убрать любые потери, связанные с рутинными операциями.

Не всё перечисленное ниже удается сделать. Часть задач сам заказчик задвигает в низкоприоритетные и бесконечно откладывает.

Где находится исходный код?

Под контроль нужно взять изменения в исходном коде системы и всех подсистем. Я бы рекомендовал следить за всеми ветками во всех репозиториях, к которым удастся получить доступ. Это позволит избежать побочных эффектов работы предыдущей команды или её остатков, которые будут работать вместе с вами.

Если системы контроля версий нет (не смейтесь, это обычная ситуация), то её обязательно нужно завести в самом начале, еще до первых изменений в коде. Это позволит вам:

1. Контроллировать все изменения, которые будут поступать от вашей команды и возможно от остатков старой команды
2. Собрать все исходники системы и всех подсистем в одном месте

Где развернута система?

Скорее всего про инфрастуктуру системы будет известно немного. Вам необходимо будет провести аудит серверов, политик безопасности, настроек домена, настроек бэкапа и т.п. Это довольно тяжелая и кропотливая работа для системного администратора. О доступе к серверам я бы рекомендовал позаботиться заранее, т.к. возможно придется получать специальные разрешения, восстанавливать логины/пароли или искать «того единственного, который помнит пароль».

Если вам досталась актуальная документация инфрастуктуры, то это большая удача. В любом случае стоит ввести системного администратора в курс дела и дать ему задачу актуализировать документацию.

Какая версия сейчас работает?

Если системой уже начали пользоваться, то нужно понять, какая версия в данный момент залита на боевых серверах. Номер версии должен быть однозначно сопоставим с номером ревизии в системе контроля версий. Это вам пригодится при изучении работы системы, анализе её поведения, отладке и профилировании.

Обычная ситуация, что вам не могут сказать точно, какая версия сборок сейчас залита и где найти код именно той залитой версии. Тогда переходим к следующему шагу и настраиваем выпуск новых версий сами.

Как выпустить новую версию?

Выпуск новой версии системы и любой её части должен быть автоматизирован. В идеале, вам надо получить доступ к CI-серверу и убедиться, что выпуск новых версий делается одним нажатие кнопки.

Нередко в проектах нет CI. В этом случае нужно запланировать с заказчиком время и настроить CI. В выпуск версии вам стоит включить как минимум:

1. Сборку последних версий всех проектов в системе
2. Проставление номера текущей версии
3. Модификацию файлов конфигурации под окружение
4. Запуск автоматических тестов
5. Выпуск артефактов для заливки

Это минимальный набор шагов, который позволит убрать большинство рутинных ошибок и сэкономит время в будущем. Плюс, вы научитесь собирать новый для вас проект, что бывает не так просто по ряду причин.

Если вы будете использовать TeamCity, то можно сразу включить плагины для анализа кода.

Интегрирована ли система с другими системами?

Перед тем, как вносить в унаследованную систему какие-то изменения, нужно получить схемы интеграции со сторонними проектами. Возможно система что-то выгружает или забирает со сторонних FTP, у нее есть публичные веб-сервисы, она делает выгрузки в бухгалтерские системы и т.д.

Если документации нет, то информацию нужно собрать и задокументировать самостоятельно, потом дать заказчику и его разработчикам на ревью. Вы ведь не хотите, чтобы после заливки вашей версии заказчику начали звонить контрагенты и спрашивать куда подевались их данные? Незначительные изменения в системе могут сломать хрупкую, складывающуюся годами схему интеграции с подсистемами компании и сторонних клиентов.

Стоит проверить есть ли интеграция со сторонними сервисами типа Google Webmaster, картами и т.п. В пример могу привести систему, которую мы недавно в срочном порядке доделывали. Одна из команд заказчика после заливки потеряла из индекса Google около миллиона страниц. Они сделали несколько измений в архитектуре системы и не убедились, что интеграция с Google работает корректно.

Если вам предоставили документацию обо всех точках интеграции, то её необходимо актуализировать.

Логирование работы

Вам будет нужна постоянная обратная связь об ошибках, которые возникают. Её получают за счет системы логирования, запущенной на боевых серверах.

Если системы логирования нет, то эту систему необходимо развернуть до внесения изменений в код. Если эта система есть, но логи просто лежат на серверах, то надо настроить уведомления к вам на почту. Желательно прикрутить систему типа elmah, чтобы было проще обрабатывать логи со всех серверов.

Не надо бояться, что вас завалит ошибками. Вам нужна ситуация в системе «как есть», а поток ошибок, который вы увидите:

1. Откроет глаза заказчику на реальную ситуацию на проекте
2. Придаст вам дополнительную мотивацию поскорее всё исправить

Настроен ли мониторинг и аналитика?

В сложных системах обычно делают сторонний анализатор, который периодически отправляет отчеты с результатами работы системы. Это могут быть отчеты по динамике регистраций в системе, анализ покупательской активности, анализ полноты и целостности данных и другие. Если что-то подобное уже есть в унаследованной системе, то стоит подписаться на все уведомления и дать к ним доступ вашему отделу контроля качества.

Модульные и интеграционные тесты

Если в проекте есть модульные или интеграционные тесты, то это отличная возможность изучить сценарии работы системы. Для начала нужно прогнать все тесты, удалить пустые или бесполезные, чтобы они не висели техническим долгом. Бывают тесты, написанные ради увеличения покрытия кода, их тоже лучше удалить в самом начале. В проекте могут быть закомментированные тесты или отмеченны атрибутом [Skip], иногда их узучение может показать проблемы в проекте.

Зеленые тесты будут вашими лучшми друзьями, т.к. являются самой актуальной документацией к системе. Существующие тесты надо обязательно включить в CI, если этого еще не было сделано.

Если тестов недостаточно, то можно потратить некоторое время на Characterization Testing. Это позволит лучше изучить поведение системы.

Если тестов нет, то вам захочется покрыть код тестами. Здесь вы можете столкнуться с несколькими проблемами:

1. Заказчик не выделяет время на покрытие кода тестами. Тогда QA обязательно должны сделать полное ручное тестирование системы и перед каждым релизом перепроверять регресс.
2. Модульные тесты невозможно написать из-за ошибок в проектировании системы. В этом случае нежелательно кидать все силы на рефакторинг системы и постепенное покрытие кода тестами, т.к. этот процесс может затянуться, а при нехватке опыта оказаться безуспешным.

Где можно найти тестовые сценарии?

Перед внесением изменений всю систему надо протестировать. QA обязательно спросят про тестовые сценарии и документацию, чтобы сделать полное тестирование текущей версии. Также будет необходимо получить доступ к bug-tracker’у для актуализации известного списка ошибок и задач.

Если тестовых сценариев нет и документация устарела, то желательно рекомендовать заказчику полное тестировании системы и составление тестовых сценариев. Это необходимо, чтобы зафиксировать уже имеющиеся баги и в дальнейшем делать регрессионное тестированое.

Какие требования предъявлялись к системе?

На протяжении разработки унаследованной системы к ней предъявлялся ряд требований. Желательно найти все документы/письма/страницы в вики проекта, где эти требования написаны. В них вы можете найти ответы на вопросы:

1. Максимальное время отклика веб-интерфейса при обычной нагрузке
2. Максимальное время отклика веб-интерфейса при пиковой нагрузке
3. Ожидаемая нагрузка на систему
4. Частота бэкапов
5. …

Если требования не оформлены, то желательно уточнить их у заказчика и оформить в соответствующие документы. Если вы нашли эти документы, то я бы рекомендовал их актуализировать. У нас был случай, когда в системе было искусственное ограничение в 10 пользователей, иначе процесс зависал и не возвращался к жизни. Заказчика убеждали, что это нормальное ограничение для подобных проектов.

Очевидно, что список требований к системе нужно знать до начала внесения первых изменений. Команда QA должна провести анализ системы, уточнить какие из требований в данный момент выполняются, а какие нет. В дальнейшем QA должны постоянно проверять систему на соответствие этим требованиям и фиксировать улучшения или ухудшения ситуации.

Общие рекомендации для начала работы

• Для анализа кода можно прогнать его через разлиные инструменты аналитики и визуализации. Например, можно взять NDepend или FxCop. После анализа можно исправить самые критичные ошибки, которые выявят инструменты, если заказчик выделит на это время. В самом начале работы над унаследованной системой проблем довольно много, поэтому эти метрики не сыграют решающей роли. Они покажут, что всё плохо с отчетами в сотни ошибок, но что это даст? Вы и так знали, что в проекте много проблем. По мере разработки эти инструменты будут всё более и более востребованы.
• Заказчик может предложить тех. лида со своей стороны. Это довольно хорошая практика, но надо быть осторожными. Если этот тех. лид участвовал в разработке неудачной версии, которая провалилась, то он может продолжить реализацию ошибочных идей в вашей команде. Согласитесь, что трудно признавать свое творение ужасным. Мы однажды допустили такую ошибку, за что поплатились 4-мя месяцами борьбы со стереотипами, сложившимися на проекте.
• Несмотря на это взять, разработчика из предыдущей команды, который находится на проекте на правах консультанта, это хорошая идея. Вы будете придумывать решения, которые прошлая команда уже пробовала и они оказались неудачными по ряду причин, специфичных для проекта. Эти знания о развитии проекта пригодятся в будущем.
• Кроме численных метрик, вам будут нужны люди способные понять, что система становится лучше или хуже. Скорее всего это будет кто-то из отделов тех. поддержки, аналитики, сам заказчик или один из ключевых (или группа) пользователей. Используйте любые возможности для закрепления текущего состояния системы, чтобы при каждом изменении делать сравнение.
• Нужно собрать и занести в таблицу все технологии, фреймворки, ОС, СУБД и т.п., которые используется в системе. Посмотреть их версии, выделить те, которые уже не поддерживаются и составить план по обновлению. Это довольно рискованные и длительные изменения, поэтому вряд ли заказчик даст возможность сделать это в начале вашей работы, но иметь эту информацию пригодится.
• Если в системе нет тестового сервера (staging, UAT), то желательно его развернуть в самом начале. Это может оказаться трудоемкой задачей из-за сложности инфрастуктуры проекта или больших объемов данных, необходимых для работы системы.
• Если в самом начале непонятно куда двигаться, то можно разделиться на несколько команд, каждая из которых будет идти по своему пути развития. Таким образом, вы сможете быстрее выработать нужные решения.

Стратегия изменения

После проработки вышепечечисленных вопросов вы должны понять, что за система вам досталось и в каком она состоянии. Теперь надо понять, как двигаться дальше.

Набор конретных тактик уже описан в книгах:

1. Рефакторинг. Улучшение существующего кода про тестирование, Мартин Фаулер
2. Рефакторинг с использованием шаблонов, Джошуа Кериевски
3. Эффективная работа с унаследованным кодом, Майкл К. Физерс

В этих книгах разобраны конкретные примеры и даны ответы на вопросы про улучшение кода и его покрытие тестами. Например, что делать с длинным методом, который сложно тестировать? Как разорвать ненужные зависимости? Как убрать зависимость от статического класса? И многое другое. Рекомендую прочитать эти книги и 90% проблем в коде будут для вас не проблемой.

Я же предлагаю рассмотреть основные стратегии, которые можно использовать при работе с унаследованными системами, показать их плюсы и минусы.

1. Переписать

Вы смотрите на чужой код, видите в нем множество недочетов. Хочется просто написать правильно с нуля. Почему бы и нет? Один из возможных вариантов развития старой системы — это ее перерождние в greenfield-проекте.

Плюсы:

• Проанализировав унаследованный код, мы узнаем как не надо делать
• Система наверняка будет содержать много хороших решений, которые можно будет взять как есть. Это сэкономит время при создании проекта с нуля
• Повышенная мотивация в команде, т.к. кодовая база будет полностью «ваша»

Минусы:

• Заказчик оплатит создание той же системы во второй раз
• Заказчик долго не увидит разницы между тем, что было и как стало. Первый релиз новой системы, который превзойдет старую систему по количеству фич, появится не скоро
• Если система уже используется, то переписывание старых функций может занять значительное время
• Вам придется поддерживать одновременно и старую и новую системы, до тех пор пока все пользователи перейдут на новую
• Система может оказаться сложнее, чем вы изнально предполагали, есть шанс сделать также плохо как было или хуже. Вы не знаете всех нюансов системы и подсистем, которые копились годами.

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

1. Заказчик дает время и деньги на переписывание старой системы с нуля, а вы со своей стороны уверены в своих силах
2. Систему еще не начали использовать, возможно она представляет из себя прототип или ‘proof of concept’
3. Система действительно не работает, пользователи отказываются от нее. Например, у нас был проект, который предыдущая команда писала год, в итоге он просто не соответствовал заявленным характеристикам. Дописывать или рефакторить его не было смысла. Мы проанализировали то, что было сделано не так и реализовали с учетом предыдущих ошибок новую версию с нуля

Пример проекта, когда пришлось полностью переписать первую неудачную версию.

2. Оставляем как было

Вы можете принять решение не трогать то, что уже написано. Новый код писать в том же стиле, не рефакторить, не изменять дизайн системы. Возможно система слишком большая и сложная, возможно давят сроки, возможно нет бюджета на исправление критических ошибок, а может код показался вам достаточно хорошим. Тогда вы принимаете стандарты и подходы из текущей реализации.

Плюсы:

• Работа над системой не останавливается, клиент видит результаты своих вложений
• Поставка новых функций и исправление ошибок идет с самого начала вашей работы

Минусы:

• Заказчик может настаивать на том, чтобы не тратить время на абстрактное улучшение дизайна, а просто поправить пару критичных ошибок. Если код в системе плохой, то вы добавляете туда еще больше костылей и стараетесь быстрее избавиться от этого проекта
• Есть шанс попасть в ситуацию, описанную Бруксом: «Все исправления имеют тенденцию к разрушению структуры, увеличению энтропии и дезорганизации системы. Все меньше сил тратится на исправление ошибок исходного проекта и все больше — на ликвидацию последствий предыдущих исправлений»
• Реанимация системы в разы сложнее, чем создание новой. Для этой работы нужна высокая квалификация
• Есть вероятность потратить время разработчиков и в итоге откатить все изменения

Рекомендация, когда стоит оставить всё как есть:

1. Бизнесу не нужны новые функции, нужно только исправить часть существующих. Такое случается, когда дальнейшее развитие системы не планируется. Возможно, параллельно создается новая система, с новыми идеями на новый платформе.
2. Нужно очень быстро дать результат, даже путем осознанного добавления костылей в код. Я понимаю, что это может усугубить ситуацию, но если заказчик с этого рывка получит огромную прибыль, то в дальнейшем сможет инвестировать её в другие стратегии работы с унаследованной системой
3. Код достаточно хороший, есть тесты, архитектура отвечает требованиям клиента

3.

Душитель

Этот подход является смягченной версией полного переписывания системы с нуля. Мы создаем новое приложение вокруг старого. По мере роста нового приложения оно перехватывает всё больше и больше функций существующей системы. Cтарую систему при этом не трогаем, новые функции пишем в новой.

Метафора была описана у М. Фаулера в статье Strangler Application.

Плюсы:

• Все плюсы первого подхода с полным переписыванием
• Работа старой системы не останавливается и при этом мы добавляем новые функции
• Заказчик сразу начинает видеть результаты своих вложений
• Если унаследованная система построена на Event Sourcing или с общей шиной, то реализация перехвата событий будет очень простой

Минусы:

• Если в системе были серьезные ошибки, то нам придется исправлять их в унаследованном коде
• Есть опасность «не додушить» (например, финансирование закончится или прекратите работу с заказчиком), тогда система станет еще большим чудовищем с двумя головами
• При сложной и запутанной архитектуре унаследованной системы этот подход может быть трудно реализуем
• На мой взгляд это один из самых сложных подходов, который требует хорошего предварительного анализа и высокого уровня разработчиков

Рекомендация, когда стоит «душить»:

1. Унаследованная система стабильно работает
2. В основном надо добавлять новые функции, а не расширять уже существующие

4.

Переработка по модулям

Если создать новое приложение «душителя» не получается и код в текущем состоянии оставлять нельзя, то нам остается заняться постепенным рефаторингом и улучшеним дизайна системы. Для этого релиз за релизом мы изолируем части системы, выделяем независимые модули и переписываем их. Таким образом, через определенное время большая часть системы будет переписана.

Плюсы:

• Постепенное улучшение качества системы
• Возможность сделать постоянную скорость поставки, не максимально высокую, но стабильную
• Пользователи продолжают работать с уже знакомой системой, получая периодические обновления

Минусы:

• Не будет резкого скачка качества системы, возможно скорость разработки будет слишком низкой для заказчика
• Не всегда возможно выделить модули (добавление от hazzik)

Рекомендация, когда стоит постепенно переписывать по модулям:

1. Унаследованная система имеет высокую ценность для заказчика
2. В системе реализовано много отлаженных модулей
3. В основном надо расширять уже существующие функции

Поддержка и развитие

Мы рассмотрели в основном технические вопросы при работе с унаследованными системами. Только технических изменений не будет достаточно для долгосрочного успеха. Например, внедрение CI или Continuous Deployment в корне меняет сами подходы, которые были на проекте.

Для успеха проекта нужно поменять культуру разработки. Привить новые ценности владельцам продукта и пользователям. Убрать все потери, автоматизировать рутину.

Была ли в вашей практике работа с унаследованной системой с плохим кодом? Удавалось ли выбросить плохой код и убедить заказчика переписать всё с нуля? Если она была успешно изменена, то что вам помогло решить проблемы? Если успеха не было, то что стало проблемой?

Кроме того, вы можете заказать у меня анализ вашей системы и план по ее переработки.

Истории работы с унаследованными системами

Рекомендую прочитать истории от разработчиков и менеджеров, которые работали с унаследованными системами, проводили рефакторинги, покрывали тестами и добивались успеха в выпуске новых версий. Истории разные и могут пригодится вам в работе, даже если прямо сейчас у вас нет унаследованной системы.

• Legacy vs Agile Team, AgileKitchen, Алексей Воронин
• Lessons Learned for Dealing with Legacy Code, Jeremy Miller
• A Team, A System, Some Legacy … and You, Eoin Woods
• Strategies for Effectively Managing Legacy Systems, Amit Uttam, Derek Longmuir
• PTOM: Black-box analysis of legacy applications, Jimmy Bogard
• An Agile Approach to a Legacy System, Chris Stevenson и Andy Pols
• Tips to Developers Starting on Large Applications, Choudary Kothapalli
• Removing the «Legacy» from your Code, Jeremy Miller
• Cleaning Code — Tools and Techniques for Legacy Restoration Projects
  , Mike Long
• Recovering the Ability to Design when Surrounded by Messy Legacy Systems, Eric Evans
• Classic software engineering mistakes: To Greenfield or Refactor Legacy code?

10 синонимов слова НАСЛЕДИЕ | Тезаурус Мерриам-Вебстер

Сохранить слово

что-то, что является или может быть унаследовано

• старый медальон был частью наследства моей прапрабабушки

• завещания,
• права по рождению,
• heritage,
• inheritance,
• patrimony

• heirloom

• bestowal,
• gift,
• offering,
• present

See the Dictionary Definition 

Share legacy

Разместите больше слов для наследия в Facebook

Поделитесь другими словами для обозначения наследия в Твиттере

Путешественник во времени на наследие

Первое известное использование

legacy было
в 15 веке

Другие слова того же века

Тезаурус Записи рядом с

наследие

наследие

наследие

законный

Посмотреть другие записи рядом 

Процитировать эту запись

«Наследие». Merriam-Webster.com Тезаурус , Merriam-Webster, https://www.merriam-webster.com/thesaurus/legacy. По состоянию на 23 октября 2022 г.

Стиль: MLA

Merriam-Webster.com Thesaurus, Merriam-Webster, https://www.merriam-webster.com/thesaurus/legacy. По состоянию на 23 октября 2022 г..»>MLA
Merriam-Webster.com Тезаурус, с.в. «наследие», по состоянию на 23 октября 2022 г., https://www.merriam-webster.com/thesaurus/legacy.»>Chicago
Тезаурус Merriam-Webster.com. Получено 23 октября 2022 г. с https://www.merriam-webster.com/thesaurus/legacy»>APA.
Merriam-Webster.com Thesaurus, https://www.merriam-webster.com/thesaurus/legacy. По состоянию на 23.10.2022.»> Merriam-Webster

Подробнее от Merriam-Webster на Legacy

Nglish: Перевод Legacy для носителей испанского языка

Британская английская
воля

См. Определения и примеры »

Получайте ежедневное электронное письмо «Слово дня»!

Тест на часто путаемые слова

• Я пошел в магазин ______, чтобы купить поздравительную открытку.

• канцелярские товары
  стационарный

Проверьте свои знания и, возможно, узнаете что-нибудь по пути.

ПРОЙДИТЕ ТЕСТ

Ежедневное задание для любителей кроссвордов.

ПРОЙДИТЕ ТЕСТ

Подпишитесь на крупнейший словарь Америки и получите тысячи дополнительных определений и расширенный поиск без рекламы!

Merriam-Webster без сокращений

Слова в игре

• «Дундерхед» и другие «приятные» способы сказать «глупый»

  Как показано на некоторых очень умных щенках

• 10 слов из географических названий

  Бикини, бурбон и бадминтон заняли первые места

• «Гордость»: слово, которое превратилось из порока в силу

  Вы гордитесь Прайдом?

• Когда впервые были использованы слова?

  Найдите любой год, чтобы узнать

Спросите у редакторов

• Буквально

  Как использовать слово, которое (буквально) приводит некоторых людей в. ..

• «Все интенсивные цели» или «Все намерения и цели»?

  Мы намерены разобраться

• Лэй против лжи

  Редактор Эмили Брюстер разъясняет разницу.

• горячий беспорядок

  «Публика в беспорядке»

Игра слов

• Встреться со своими страхами

  Не бойтесь отвечать на эти вопросы о…

  Пройдите тест

• Мегавикторина «Назови эту вещь»: Vol. 2

  Проверьте свой визуальный словарный запас!

  Пройди тест

• Правда или ложь?

  Проверьте свои знания и, возможно, узнаете что-то новое. ..

  Пройдите тест

• Орфографическая викторина

  Сможете ли вы превзойти прошлых победителей национального конкурса Spelli…

  Примите участие в викторине

Наследие Определение и значение | Dictionary.com

• Основные определения
• Синонимы
• Викторина
• Похожие материалы
• Примеры
• Британский

Показывает уровень сложности слова.

[ нога-э-э-э ]

/ ˈlɛg ə si /

Сохранить это слово!

См. синонимы слова legacy на сайте Thesaurus.com

Показывает уровень обучения в зависимости от сложности слова.

существительное во множественном числе.

Право. дарение имущества, особенно движимого, в виде денег по завещанию; завещание.

все, что досталось из прошлого, как от предка или предшественника: наследие Древнего Рима.

абитуриент или ученик школы, которую посещал его или ее родитель.

Устарело. должность, функция или поручение легата.

прилагательное

, относящееся к старому или устаревшему компьютерному оборудованию, программному обеспечению или данным, которые, хотя и функционируют, плохо работают с современными системами.

ДРУГИЕ СЛОВА ДЛЯ наследства

1, 2 наследство.

См. синонимы слова legacy на Thesaurus.com

ВИКТОРИНА

Сыграем ли мы «ДОЛЖЕН» ПРОТИВ. «ДОЛЖЕН» ВЫЗОВ?

Следует ли вам пройти этот тест на «должен» или «должен»? Это должно оказаться быстрым вызовом!

Вопрос 1 из 6

Какая форма обычно используется с другими глаголами для выражения намерения?

Происхождение наследия

1325–75; Среднеанглийское наследие должность заместителя или легата <средневековая латынь lēgātia. См. legate, -acy

Слова рядом с legacy

leftward, leftwards, left wing, lefty, leg, legacy, Legal, совершеннолетие, юридическая помощь, общество юридической помощи , правовая шапка

Dictionary.com Полный текст
Основано на словаре Random House Unabridged Dictionary, © Random House, Inc., 2022

Слова, относящиеся к наследству

имущество, подарок, традиция, завещание, право первородства, разработка, пожертвование, семейная реликвия, возврат

Как использовать наследство в предложении

• Все три действия напрямую угрожают наследию Карла Стоукса и той реке в 1969 году.0003

• Мартинес сказал мне, что обязательство по мониторингу — это огромная победа для рабочих, многие из которых с тех пор покинули Voyant, но теперь «оставляют наследие своим оставшимся коллегам».

  Временные работники борются с предполагаемыми сексуальными домогательствами и заявляют, что им грозит возмездие за это|Мелисса Санчес|28 августа 2020 г. |ProPublica , Кук создал свое собственное отличительное наследие.

  Генеральный директор Apple Тим Кук воплощает в жизнь еще одно видение Стива Джобса|Рэйчел Шаллом|24 августа 2020 г.|Fortune

• Частично это связано с тем, что молодых покупателей не волнует наследие или количество времени, которое существуют бренды.

  «Новое определение роскоши»: Highsnobiety раскрывает, как ландшафт элитной моды смещается в сторону доступности|Кейли Барбер|24 августа 2020 г.|Digiday

• в предстоящем избирательном сезоне, чтя наше наследие и обеспечивая будущее нашей страны как единого народа.

  Отступление от условностей — мама, бейсбол, почтальон и патриотизм|Джейкмет|19 августа 2020 г.|Fortune

• К сожалению, это больше касается защиты наследия «великого человека».

  Филисия Рашад и the Cult of Cosby Truthers|Stereo Williams|8 января 2015|DAILY BEAST

• Я не знаю, зачем и кто это делает, но это наследие… и это наследие так важно для культуры.

  Филисия Рашад и культ Косби Трутерс|Стерео Уильямс|8 января 2015 г.|DAILY BEAST

• TVA, находящийся в федеральной собственности и зарегистрированный поставщик электроэнергии, является наследием Нового курса, как и Социальное обеспечение.

  Стив Скализ показывает, что между Confederate и Southern существует тонкая грань|Lloyd Green|2 января 2015 г.|DAILY BEAST

• Reconcile — рэпер из Хьюстона, города с богатым хип-хоп наследием.

  Долой короля: христианство не прячется в шкафу рэпа|Stereo Williams|28 декабря 2014 г.|DAILY BEAST

• Пока промежуточные выборы благополучно отражаются в зеркале заднего вида, Обама патрулирует наследие.

  Хлопок Обамы одной рукой с Кастро|Даг Макинтайр|24 декабря 2014|DAILY BEAST

• «Это должно быть наследием наших детей», — был ответ серьезным и почти сокрушенным тоном.

  Эдинбургский журнал Blackwood, № CCCXXXIX. Январь 1844 г. Том. LV.|Various

• Каждая из них оставила аббату в наследство свою любовь, чтобы передать ее близким, которых нужно было оставить.

  Мадам Роланд, Makers of History|John S.C. Abbott

• Таким образом, если лицо, упомянутое в качестве наследника, умрет раньше наследодателя, наследство будет недействительным.

  Удобная книга законов Патнэма для непрофессионалов|Альберт Сидни Боллес

• Первобытная церковь хранила эти воспоминания о моральном героизме как самое ценное наследие для грядущих времен.

  Катакомбы Рима|Уильям Генри Уитроу

• У него было еще одно наследство, большой железный ящик с тремя железными замками.

  Black Diamonds | Mr Jkai

Британские словарь определения для Legacy

Legacy

/ (ˈlɛəsɪ) /

существительные плюс. вышедшие из строя или полученные от предка или предшественника

(модификатор) сохранившиеся компьютерные системы, аппаратное или программное обеспечение устаревшей сети; заявка на наследие

Происхождение слова для наследия

C14 (значение: должность легата), C15 (значение: завещание): из средневековой латинской комиссии lēgātia; см.