Legacy программа что это

Что такое legacy code?

5 июл 2018 в 6:22
5 июл 2018 в 6:30

То есть legacy можно сказать, что весь код legacy включая import классов. В широком смысле весь код унаследован?

5 июл 2018 в 6:34

5 ответов 5

Сортировка: Сброс на вариант по умолчанию

Legacy code — тяжелая наследственность : ) Устаревший код, который более не поддерживается и не обновляется, но используется. Второе значение — код от сторонних разработчиков, или из старых версий.

Отслеживать
ответ дан 25 сен 2012 в 2:52
30.5k 4 4 золотых знака 46 46 серебряных знаков 83 83 бронзовых знака
25 сен 2012 в 8:56

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

Legacy code — код, подпадающий под один или несколько признаков:

• написан другими разработчиками, возможно, уже недоступными для контакта;
• не покрыт юнит-тестами;
• сохранён для совместимости с предыдущими версиями системы;
• устарел и/или более не поддерживается в связи с развитием системы (написан на предыдущем языке, под старую архитектуру, аппаратную платформу, операционную систему и т.д.).

Отслеживать
ответ дан 25 сен 2014 в 14:51
Cowboy_BeBoob Cowboy_BeBoob
417 4 4 серебряных знака 3 3 бронзовых знака

Программисты увольняются из-за наличия Легаси кода

Требование «опыт работы с legacy кодом» в вакансии означает, что вам достанется код, написанный лет 10-20 назад давно уволившимися программистами. Не исключено, что он изначально был плохо написан, что требования к проекту менялись уже много раз и каждый раз код правился как придётся в режиме жёсткого дедлайна, что документацию никто не писал и рефакторинг не делал. Поэтому вместо того чтобы писать новый код на прогрессивных технологиях, вам большую часть времени придётся разбираться в старом и править его, ловя потом каскады багов. Добро пожаловать в чудесный мир кровавого энтерпрайза, основного потребителя Java.

Отслеживать
ответ дан 5 июл 2018 в 6:34
Sergey Gornostaev Sergey Gornostaev
65.7k 6 6 золотых знаков 49 49 серебряных знаков 109 109 бронзовых знаков
Отслеживать
ответ дан 25 сен 2012 в 6:42
80.7k 7 7 золотых знаков 70 70 серебряных знаков 151 151 бронзовый знак

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

Отслеживать
ответ дан 3 ноя 2020 в 18:36
user236980 user236980

Highly active question. Earn 10 reputation (not counting the association bonus) in order to answer this question. The reputation requirement helps protect this question from spam and non-answer activity.

Что такое легаси код? / Монолит vs легаси vs микросервисы / Варианты архитектур

Важное на Мете

Связанные

Похожие

Подписаться на ленту

Лента вопроса

Для подписки на ленту скопируйте и вставьте эту ссылку в вашу программу для чтения RSS.

Нажимая «Принять все файлы cookie» вы соглашаетесь, что Stack Exchange может хранить файлы cookie на вашем устройстве и раскрывать информацию в соответствии с нашей Политикой в отношении файлов cookie.

Источник: ru.stackoverflow.com

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник: thecode.media

Legacy программа что это

МЕРОПРИЯТИЯ

QAtalks: Tools https://proglib.io/p/legacy-reasons» target=»_blank»]proglib.io[/mask_link]

Код без тестов — легаси

Если вы работаете в IT, то о легаси вы слышите часто — обычно с множеством негативных коннотаций. Понятно, что это не «хороший код», но какой? Может старый, может не поддерживаемый или не обновляемый, а может просто чужой? Есть ли «полноценное» определение «легаси», на которое можно ссылаться? А когда разберемся — что нам делать с легаси?

Попробуем разобраться. Спойлер: выводы неочевидны.

Автор — Николас Карло, веб-разработчик в Busbud (Монреаль, Канада). Специализируется на легаси. В свободное время организует митап Software Crafters и помогает с конференциями SoCraTes Canada и The Legacy of SoCraTes.

Данная статья была скомпилирована (и отредактирована) из двух статей Николаса: «What is Legacy Code? Is it code without tests?» и «The key points of Working Effectively with Legacy Code». Показалось логичным рассказать о том, что такое легаси, а потом — как с ним работать.

Что такое «легаси»?

Возможно, если вы задавались этим вопросом, то встречали определение от Майкла Физерса. Майкл выпустил книгу «Working Effectively with Legacy Code» в 2004 году, но она до сих пор актуальна. Комикс это отлично иллюстрирует.

В своей книге Майкл пишет своё определение:

«Для меня легаси — это просто код без тестов».

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

Это хорошее определение: чаще всего тесты отсутствуют, так что это хорошее начало. Но это ещё не всё — есть нюансы.

Код с тестами также может быть легаси. Если вы читаете тесты, но не можете понять, что должен делать код — они отстой. Плохие тесты только мешают: тестируемый код так же трудно отрефакторить, как если бы у него не было тестов, а может даже и сложнее!

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

Перейдём к моему определению легаси.

Легаси — это ценный код, который вы боитесь менять.

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

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

Хорошие тесты помогают легко менять незнакомый код. А плохие тесты не помогают. Отсюда и определение Физерса.

С легаси помогает время. Парадоксально: обычно время превращает любой код в легаси, но чтобы его понять нам также помогает время. Если вы начали работать над легаси и это трудно — подождите. Да, большая часть кода ужасна, но вы привыкнете и лучше поймете его причуды и особенности.

Легаси не виновато в том, что оно такое. Большая часть кода ужасна, потому что это результат работы многих людей в течение долгого времени с противоречивыми требованиями и под давлением дедлайнов. Это Рецепт Устаревшего Кода™. Когда мало времени и недостаточно знаний — рождаются костыли (ну вы знаете). В конце концов, мы достигнем состояния, когда каждое движение приводит к ошибке, а реализация любой функции занимает целую вечность.

А теперь один из важнейших нюансов.

Легаси — это код, который мы изо всех сил пытаемся понять, чтобы поменять.

Легаси — это личная точка зрения. Устаревший код может стать проблемой для каждого разработчика команды. Какой-то код может показаться сложным, потому что мы его ещё не поняли, а какой-то понимаем, но всё равно чувствуем себя некомфортно, когда рефакторим. Но субъективное ощущение «легаси» зависит от нашего понимания кода, и наших чувств по поводу его изменения. Часто люди этого не понимают.

В итоге мы получаем, что легаси это:

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

Как же эффективно работать с легаси?

Легаси — код, который мы пытаемся понять, чтобы отрефакторить. Задача рефакторинга в том, чтобы сохранить существующее поведение кода. Как без тестов мы будем уверены, что ничего не сломали? Нам нужна обратная связь. Автоматизированная обратная связь — ещё лучше.

Добавить тесты, а затем внести изменения

Логично, что если добавить тесты, они помогут его «прощупать» и он перестанет быть устаревшим. Поэтому первое, что нужно сделать — написать тесты. Только тогда мы будем в безопасности, чтобы рефакторить код.

Но чтобы запустить тесты, мы должны поменять код. Возникает парадокс легаси. Мы обречены? Нет. Поменяем как можно меньше кода для тестов:

• Определим точки изменения — «швы».
• Разорвём зависимости.
• Напишем тесты.
• Внесём изменения.
• Отрефакторим.

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

Найти «швы» для разрыва зависимостей

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

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

«Шов» — место, где можно изменить поведение программы, не меняя код.

«Швы» бывают разные. Если это объектно-ориентированный ЯП, то обычно это объект, например, в JavaScript.

export class DatabaseConnector < // A lot of code… connect() < // Perform some calls to connect to the DB. >>

Допустим, метод connect() вызывает проблемы, когда мы пытаемся поместить код в тесты. Получается, что весь класс — это «шов», который можно поменять. Можно расширить этот класс в тестах, чтобы предотвратить его подключение к реальной БД.

class FakeDatabaseConnector extends DatabaseConnector < connect() < // Override the problematic calls to the DB console.log(«Connect to the DB») >>

Есть и другие виды швов. Если язык позволяет изменять поведение кода без изменения исходного кода, у нас есть точка входа в написание тестов. Кстати о тестах…

Напишем unit-тесты

Дискуссии о лучших практиках тестирования обычно перерастают в холивары. Применять принцип пирамиды тестов, и писать максимум unit-тестов? Или использовать «Кубок тестирования» и писать в основном интеграционные?

Почему советы такие противоречивые? Потому что у них нет единого определения того, что такое «unit». Одни люди говорят об «интеграционных тестах» и тестируют всю библиотеку, а другие тестируют каждый класс по отдельности.

Чтобы избежать путаницы, Майкл даёт четкое определение того, что такое НЕ unit-тест:

• он не работает быстро ( < 100ms / test);
• он взаимодействует с инфраструктурой, например, базой данных, сетью, файловой системой, переменными;

Напишите максимум тестов, которые обладают этими 2 качествами, при этом неважно, как вы их назовёте.

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

Тесты для определения характеристик

Это тесты, которые формализуют фактическое поведение части кода.

Вместо того чтобы писать комплексные модульные тесты, мы фиксируем текущее поведение кода — делаем снимок того, что он делает. Тест гарантирует, что это поведение не изменится!

Это мощная техника, потому что:

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

Этот метод также называют «Approval Testing» («тестированием одобрения»), «Snapshot Testing» или «Golden Master».

Но обычно на всё это очень мало времени.

Когда совсем нет времени на рефакторинг

Несколько советов, если предыдущие не подходят.

Большие куски кода обладают «гравитацией» и привлекают ещё больше кода. «Теория разбитых окон» в действии: небольшой беспорядок влечёт за собой беспорядок серьёзнее. Если класс уже содержит 2000 строк, то какая разница, что вы добавите еще 3 if оператора и будете поддерживать класс длиной в 2010 строк?

Это всего лишь 3 if: тяжело себя убедить, что нужно потратить на них 2 дня, хотя и должны. Что делать, если действительно нет времени писать тесты для этого класса? Используйте техники Sprout (прорастание), Wrap (обёртывание) и скретч-рефакторинг.

Sprout

Напишите код в другом месте, сделайте один тест, определите, где вы должны вызвать этот код из существующего кода (точка вставки), и вызовите свой код из легаси.

Рассмотрим на примере:

class TransactionGate < // … a lot of code postEntries(entries) < for (let entry of entries) < entry.postDate() >// … a lot of code transactionBundle.getListManager().add(entries) > // … a lot of code >

Допустим, нам нужно убрать дубли файла entries, но postEntries() трудно проверить — нет на это времени. Мы можем «прорастить» код где-то ещё, например, в новом методе uniqueEntries(). Этот новый метод легко протестировать, потому что он изолирован. Затем вставим вызов этого метода в существующий, не проверенный код.

class TransactionGate < // … a lot of code uniqueEntries(entries) < // Some clever logic to dedupe entries, fully tested! >postEntries(entries) < const uniqueEntries = this.uniqueEntries(entries) for (let entry of uniqueEntries) < entry.postDate() >// … a lot of code transactionBundle.getListManager().add(uniqueEntries) > // … a lot of code >

Минимальные изменения, минимальный риск. Можете «вырастить» один метод, целый класс или что-то ещё, что изолирует новый код.

Wrap

Можно «обернуть» изменение, если оно должно произойти до или после существующего кода.

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

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

class TransactionGate < // … a lot of code postEntries(entries) < for (let entry of entries) < entry.postDate() >// … a lot of code transactionBundle.getListManager().add(entries) > // … a lot of code >

Ещё один способ решить эту проблему — это обернуть её, поэтому мы переходим к postEntries(), списку записей, из которых мы удалили дубли.

class TransactionGate < // … a lot of code postEntries(entries) < // Some clever logic to retrieve unique entries this.postEntriesThatAreUnique(uniqueEntries) >postEntriesThatAreUnique(entries) < for (let entry of entries) < entry.postDate() >// … a lot of code transactionBundle.getListManager().add(entries) > // … a lot of code >

В тестах мы бы изменили проблему postEntriesThatAreUnique(), чтобы проверить, работает ли логика удаления дубликатов. Разница может быть ещё больше.

class TransactionGate < // … a lot of code + postEntries(entries) < + // Some clever logic to retrieve unique entries + this.postEntriesThatAreUnique(uniqueEntries) + >+ postEntriesThatAreUnique(entries) < — postEntries(entries) < for (let entry of entries) < entry.postDate() >// … a lot of code transactionBundle.getListManager().add(entries) > // … a lot of code >

Эти методы не идеальны, и у них есть недостатки. Но это полезные инструменты при работе с легаси. А при необходимости можно даже немного нарушить правила.

Скретч-рефакторинг

Сложно работать с кодом, который мы не писали, без тестов и с плохой документацией. Чтобы «выбраться» нам нужно разбить зависимости, написать тесты. Но с чего вообще начинать, когда код непонятен? Хорошая техника — скретч-рефакторинг.

Его цель в том, чтобы ознакомиться с кодом, а не менять. Мы «играем» с кодом столько, сколько захотим: извлекаем функции, упрощаем, переименовываем переменные. Как только сделаем, всё, что нам нужно — откатим всё обратно и начнём с правильных тестов.

Выводы

Легаси будет везде, где бы вы ни работали, в каждой кодовой базе. Можно сопротивляться и чувствовать себя плохо, когда вы застряли в нём. А можно рассматривать это как возможность. Работа со старым кодом это очень ценный навык, его надо изучать теоретически (почитайте книгу «Working Effectively with Legacy Code») и практиковать в ежедневных задачах.

Похожие и интересные статьи:

• Как мы выпиливали Realm.
• Как мы накосячили пока делали Бриллиантовый чекаут™ 9 месяцев, а планировали 2.
• Как заблокировать приложение с помощью runBlocking.
• О том, над чем в целом мы тут работаем: монолит, монолит, опять монолит.
• Как у нас работает QA-команда.
• Кратко об истории Open Source — просто развлечься (да и статья хорошая).

Больше новостей про разработку в Додо Пицце я пишу в канале Dodo Pizza Mobile. Также подписывайтесь на чат Dodo Engineering, если хотите обсудить эту и другие наши статьи и подходы, а также на канал Dodo Engineering, где мы постим всё, что с нами интересного происходит.

А если хочешь присоединиться к нам в Dodo Engineering, то будем рады — сейчас у нас открыты вакансии iOS-разработчиков (а ещё для Android, frontend, SRE и других).

• Блог компании Dodo Engineering
• Тестирование IT-систем
• Совершенный код

Источник: habr.com

Legacy программа что это

Комментарии

ЧТОБЫ ПОСМОТРЕТЬ ВСЕ КОММЕНТАРИИ ИЛИ ОСТАВИТЬ КОММЕНТАРИЙ,
ПЕРЕЙДИТЕ В ПОЛНУЮ ВЕРСИЮ

Сообщество

JavaRush — это интерактивный онлайн-курс по изучению Java-программирования c нуля. Он содержит 1200 практических задач с проверкой решения в один клик, необходимый минимум теории по основам Java и мотивирующие фишки, которые помогут пройти курс до конца: игры, опросы, интересные проекты и статьи об эффективном обучении и карьере Java‑девелопера.

Подписывайтесь

Язык интерфейса

Скачивайте наши приложения

Этот веб-сайт использует данные cookie, чтобы настроить персонально под вас работу сервиса. Используя веб-сайт, вы даете согласие на применение данных cookie. Больше подробностей — в нашем Пользовательском соглашении.

Источник: javarush.com