Что такое легаси в программировании
Перейти к содержимому

Что такое легаси в программировании

  • автор:

Как распознать легаси, пока не стало поздно? Вебинар с Владимиром Филоновым

Как распознать легаси, пока не стало поздно? Вебинар с Владимиром Филоновым главное изображение

Представим ситуацию. Вы приходите на проект, начинаете его изучать и понимаете, что код в нём не читаем. Совершенно невозможно понять, что он делает, документация по нему отсутствует и даже комментариев нет. Или другая ситуация: вы открываете свой старый код и совсем не помните, что имели ввиду. Как вы понимаете, речь идёт о легаси — старом коде, который либо перешёл по наследству от других разработчиков, либо был написан так давно, что его никто не трогает (вдруг это что-то важное, и, если его снести, всё сломается).

Все слышали, что легаси — это зло. Но что же это такое, откуда берется и как его распознать, пока еще не поздно? Обо всем этом и не только поговорим на вебинаре на youtube-канале Хекслета.

Вебинар начнётся в прямом эфире 9 сентября в 19:00 по московскому времени. Ссылка на трансляцию: https://youtu.be/5xTR7eXtX-g По этой же ссылке будет доступна запись.

Спикер: Владимир Филонов, разработчик широкого профиля и один из организаторов сообщества Moscow Python (любит Python, Erlang/Elixir, асинхронность и TDD, копаться во внутренностях библиотек, а потом рассказывать об этом).

Moscow Python Conf++ 2021:

Владимир является спикером одной из крупнейших конференций для Python-разработчиков. Регистрируйся здесь и приходи слушать его доклады 27 и 28 сентября. Промокод со скидкой 10%: Hexlet

Полезные ссылки

  • Расписание предстоящих мероприятий Хекслета
  • Блог Виктории о DataScience
  • Комьюнити Хекслета
  • Программирование на Python: особенности обучения, перспективы, ситуация на рынке труда

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Курсы по программированию с нуля

Приходите к нам в ИТ. У нас есть удаленная работа, высокие зарплаты и удобное обучение в «Яндекс Практикуме». Старт бесплатно.

Курсы по программированию с нуля Курсы по программированию с нуля Курсы по программированию с нуля Курсы по программированию с нуля

Получите ИТ-профессию

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

Почему код становится legacy?

Написание кода похоже на соединение двух точек. Ожидаемо, что самым простым путем будет нарисовать прямую линию между точками А и Б.

Writing code is like connecting two points

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

Давайте увеличим количество препятствий на порядок. Линия становится все более извилистой.

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

А если мы заставим двигаться не только препятствия, но и сами точки? Вдобавок убедимся, что эти точки не приклеены к линиям, и вам придется следить за ними, чтобы они оставались соединенными. Начинает немного бесить?

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

What if we only knew the approximate location of points?

Усложним еще немного. Допустим, мы знаем только приблизительное положение точек.

Вот это уже в значительной степени похоже на то, как происходит разработка в реальном мире.

Обсуждение

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

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

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

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

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

Но в современном обиходе этот термин более широкий и обозначает плохой ломкий код.

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

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

Как решить эту проблему?

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

Но шаблонов проектирования недостаточно. Гораздо важнее знать, что мы быстро движемся в правильном направлении, нежели правильно двигаемся в неправильном. И да, в мире полно устаревшего кода, который следует лучшим шаблонам проектирования. Фактически, чрезмерное использование шаблонов проектирования сверх необходимого называется «оверинжинерингом».

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

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

Code with correctness feedback and design patterns in place

  1. Как можно быстрее узнавать, что мы быстро движемся в правильном направлении (обратная связь о правильности в виде черного ящика тестов)
  2. Использовать заранее продуманные решения для быстрого и контролируемого построения пути (шаблоны проектирования).

Что в итоге

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

Однако основное внимание будет уделено первому аспекту (немедленной обратной связи), так как именно он часто оказывается наиболее болезненным, в то время как дизайн-паттерны относительно хорошо изучены и известны, поэтому они будут упомянуты только кратко.

Почему разработка пользовательского интерфейса особенно склонна к Legacy?

Используя метафору с линией из примера выше, мы пришли к определению того, что такое legacy-код:

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

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

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

Дисклеймер: Все приведенные ниже примеры являются выдуманными, упрощенными и нужны только для иллюстрации — любое сходство с реальными людьми случайно.

От идеи до legacy

Greenfield — проект одного человека, создаваемый с нуля

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

Greenfield project

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

Итак, вы начинаете работать над проектом, настраиваете конфигурации и прочее. Но как только этот этап остается позади, игра начинается — теперь вы создаете.

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

С некоторыми неудачами (мы же с вами в реальном мире живем) вы справляетесь. Всё сделано вовремя, все довольны.

Проект Brownfield

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

Brownfield project

Вам будет гораздо сложнее понять мыслительный процесс человека, который создавал приложение до вас. Как он думал, что делал, зачем. Скорее всего, он не обращал много внимания на что-то, кроме требований, поэтому тестирования тут будет мало (если оно вообще будет). А логика будет куда более запутанной из-за упрощения разработки.

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

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

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

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

Шаг за шагом, и кодовая база станет тем, что называется legacy.

Legacy-проект

И даже пример выше не такой печальный, как самая частая ситуация — работа над legacy-проектом в качестве разработчика.

Legacy project

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

Заключение

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

Далее в цикле:

  • Так как же сделать пользовательский интерфейс легкотестируемым и легкоизменяемым?
  • Decoupler MVU или как реализовать MVU архитектуру для UI приложений

Полезные ссылки

  1. Black Box Testing: An In-Depth Tutorial — Этот туториал на Guru99 предоставляет всестороннее руководство по тестированию черного ящика. В нем рассматриваются его методы, типы, приемы, преимущества и недостатки.
  2. Design patterns — Подробное руководство по шаблонам проектирования программного обеспечения. Каждый шаблон подробно объясняется с примерами, чтобы лучше понять, когда и где их использовать.
  3. SOLID Principles: Explanation and examples — Этот пост на FreeCodeCamp разбирает принципы SOLID в понятной форме с большим количеством примеров.
  4. Understanding Legacy Code: Этот сайт — отличный источник информации для понимания legacy-кода и стратегий эффективной работы с ним. Поможет вам ориентироваться и улучшать legacy-системы.
  5. Greenfield vs Brownfield: В этой статье на LinkedIn Giorgi Bastos подробно рассматривает концепции проектов greenfield и brownfield. Автор дает отличное представление о различиях, преимуществах и вызовах обоих подходов.
  6. Greenfield vs Brownfield in Software Development: Synoptek предоставляет подробное сравнение между разработкой программного обеспечения greenfield и brownfield, дополнительно улучшая понимание этих концепций и их влияния на разработку пользовательского интерфейса.
  7. Advantages and Disadvantages of White Box Testing: На JavaTpoint опубликовано сбалансированное представление о тестировании белого ящика и подробное обсуждение его преимуществ и ограничений.
  8. White Box Testing: Pros and Cons: Segue Technologies предлагает другую точку зрения на тестирование белого ящика, подробно описывая его плюсы и минусы. Эта статья поможет вам понять, почему тестирование белого ящика может быть частью проблемы при поддержке кода пользовательского интерфейса.
  • философия программирования
  • програмирование
  • легаси
  • legacy
  • поддержка кода
  • UI
  • Блог компании билайн
  • Программирование
  • Совершенный код
  • Дизайн

Легаси-код

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

Освойте профессию
«Python-разработчик»

Python-разработчик

Освойте Python с нуля. Подготовим к трудоустройству: дадим много практики, реальные проекты для портфолио, поможем с резюме. Лучшие студенты пройдут стажировки в проектах компаний-партнеров.

картинка - 2023-03-14T190323.524

Python-разработчик

Освойте Python, самый популярный язык программирования

dffsdd (3)

Что такое legacy-код

Существует несколько определений легаси-кода, каждое из которых на самом деле описывает один из его аспектов:

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

Чтобы понять, что такое legacy в разработке, достаточно взглянуть на общую схему появления такого кода:

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

К причинам появления легаси-кода можно отнести следующие:

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

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

Станьте разработчиком на Python и решайте самые разные задачи: от написания кода до автоматизации процессов

Достоинства легаси-кода

Работоспособность. Легаси-код уже проверен временем и доказал свою работоспособность. Он может быть надежным и стабильным, особенно если прошел множество тестирований и исправлений ошибок.

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

Снижение затрат. Иногда переписывание легаси-кода может быть дорогостоящим и времязатратным процессом. В таких случаях поддержка и модификация легаси-кода может быть более экономически эффективной стратегией.

Недостатки легаси-кода

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

Ограниченные возможности. Легаси-код может быть написан на устаревших языках программирования или использовать устаревшие библиотеки. Это может ограничивать возможности расширения функциональности системы и препятствовать интеграции с новыми технологиями.

Риск ошибок и безопасности. Легаси-код, особенно если он не поддерживался и обновлялся в течение длительного времени, может содержать уязвимости и ошибки, которые могут представлять угрозу для безопасности системы.

Как работать с легаси-кодом

Работа с легаси-кодом может представлять определенную сложность для разработчика, но следующие рекомендации помогут справиться с этой задачей:

  • Осознать контекст. Перед тем как начать изменения, изучите код и разберитесь в его архитектуре и структуре. Понимание текущего функционала и основных проблем поможет вам определить, какие изменения необходимо внести и какие риски могут возникнуть.
  • Создать тесты. Прежде чем вносить изменения в легаси-код, создайте набор тестов, которые позволят вам проверить его работоспособность после внесенных корректировок. Тесты помогут избежать непредвиденных ошибок и подтвердить, что изменения не повлияли на работу системы.
  • Разделить код на модули. Если легаси-код слишком сложен для изменений в целом, попробуйте разбить его на отдельные блоки или компоненты. Это позволит вам работать с более маленькими и понятными частями, упрощая процесс изменений и обеспечивая более чистую архитектуру.
  • Постепенно вносить изменения. Вместо того чтобы пытаться переписать весь легаси-код сразу, начните с маленьких изменений. Поэтапное внедрение нового кода поможет контролировать риски и проверять работоспособность системы на каждом шаге.
  • Документировать изменения. Важно документировать все внесенные в легаси-код изменения, чтобы другие разработчики могли понять, что было изменено и почему. Это также поможет вам возвращаться к изменениям в будущем и понимать их влияние на систему.
  • Обратиться за помощью. Если вы столкнулись с особыми сложностями или не можете справиться со старым кодом самостоятельно, не стесняйтесь обратиться к коллегам или сообществу разработчиков за помощью и советами. Часто опыт других людей может быть очень полезным в работе с легаси-кодом.

Обязательно ли устранять или переписывать легаси-код

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

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

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *