Иногда программисты на вопрос, почему программа работает именно так, отвечают, что это «легаси» и исправить ничего нельзя . Разберёмся, что это значит, насколько это мешает разработке и что делают с легаси-кодом.
Что такое легаси
С английского legacy переводится как «наследие». Легаси-код — это код, который перешёл «по наследству» от предыдущих разработчиков. Чаще всего это происходит так:
- Команда делает продукт, внутри много разных возможностей.
- Часть функций со временем оптимизируется, а часть остаётся неизменной в виде старого кода, потому что и так работает.
- Некоторое время спустя в команде не остаётся тех, кто писал старый код.
- Текущая команда не знает, почему старый код написан именно так.
- В этих кусках сложно что-то поменять или разобраться, потому что всё остальное написано уже по-другому.
- Этот старый код, который сложно поддерживать и сложно разбираться — это и есть легаси.
Проще говоря, легаси — это код, про который говорят: «Это ещё Михалыч писал 8 лет назад для синхронизации с сервером, он работает, мы его не трогаем, потому что иначе всё сломается». При этом Михалыча в компании давно нет, документации тоже нет, и проще этот код не трогать совсем.
Какие Биткоин адреса лучше — Legacy или Segwit? 1, 3, bc1?
Так как легаси — это старый код, то обычно на него завязаны многие важные вещи в программе. Получается замкнутый круг: отказаться от легаси нельзя, потому что без него всё сломается, но и поддерживать его в рабочем состоянии тоже сложно, потому что никто не хочет разбираться в старом коде.
Откуда берётся легаси
Причин появления легаси может быть несколько:
- команда перешла на другой фреймворк, но части программы остались на старом;
- часть программы написана на старой версии языка;
- старая команда не задокументировала свой код;
- код написан в одном стиле, а команда давно перешла на другой стиль программирования.
Легаси — это не какое-то преступление, а часть жизни любой живой ИТ-компании. Рано или поздно у любого продукта появится легаси. И чем крупнее проект, тем больше его будет. Например, в исходном коде Windows 10 до сих пор остаются фрагменты кода, написанные ещё 20 лет назад для Windows 3.1.
Легаси — это плохо?
Легаси — это просто старый код, который нужно поддерживать наравне с новым. Если он работает — отлично, пусть живёт. Другое дело, что команде, например, было бы удобнее, чтобы код был написан не на старом фреймворке, а на новом, который знают все.
Получается, главный минус легаси-кода не в том, что он работает плохо, а в том, что его неудобно поддерживать.
Что значит «поддерживать старый код»?
Например, в старом коде для запроса к серверу идёт сначала адрес, а потом номер запроса. Спустя 10 лет требования сервера изменились, поэтому сначала должен идти запрос, а потом уже адрес. Значит, нужно изменить порядок полей в коде.
Если старый код понятен и хорошо задокументирован, на эту задачу уйдёт две минуты. Если это старые пыльные легаси-кишки, то это может стать задачей на час.
Legacy проекты на старых технологиях. Работать или быстрее сваливать?
Что делать с легаси-кодом
Если легаси-код работает и не требует вмешательства и поддержки — то можно пока ничего не делать, пусть работает. Будет время — перепишем на новый фреймворк, а если нет, то и так пока поработает.
А если нужно срочное вмешательство — пахнет бедой. Зовите менеджеров .
Это первая часть цикла:
1 часть — Что такое легаси в коде (вы находитесь здесь)
Источник: dzen.ru
Код без тестов — легаси
Если вы работаете в 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 году, но она до сих пор актуальна. Комикс это отлично иллюстрирует.
В своей книге Майкл пишет своё определение:
«Для меня легаси — это просто код без тестов».
Почему Физерс так считает? Потому что по его многолетнему опыту без тестов обычно трудно узнать всё, что код умеет. Если тестов нет, то для понимания, что код делает, вам нужно внимательно его прочитать, воспроизвести программу в своей голове и представить все возможные сценарии. Потом вы поменяете код и нужно снова представить все сценарии. Или проверить их вручную, но всегда есть шанс что-то сломать.
Это хорошее определение: чаще всего тесты отсутствуют, так что это хорошее начало. Но это ещё не всё — есть нюансы.
Код с тестами также может быть легаси. Если вы читаете тесты, но не можете понять, что должен делать код — они отстой. Плохие тесты только мешают: тестируемый код так же трудно отрефакторить, как если бы у него не было тестов, а может даже и сложнее!
Тестов может и не быть, но код всё ещё легко можно отрефакторить. Возможно, вы поддерживаете небольшую кодовую базу без тестов, которую легко понять и рефакторить. Хотя, по моему опыту, это аномалия. Эту кодовую базу можно было бы проверить, но отсутствие автоматизированных тестов всё же не позволяет квалифицировать его как легаси.
Перейдём к моему определению легаси.
Легаси — это ценный код, который вы боитесь менять.
Например, мы ищем первопричину ошибки или выясняете, куда вставить свою функцию. Мы хотим поменять код, но это трудно, потому что непонятно как не нарушить существующее поведение. Готово — у нас легаси!
Почему многие программисты не любят legacy проекты
Многие люди не сильно посвящённые в области программирования удивляются, а иногда даже негодуют на отсутствие у некоторых программистов энтузиазма в плане работы с legacy проектами.
Что такое представляют из себя подобные проекты и в чём состоит причина такого отношения к ним со стороны программистов?
Понятие legacy проекта
Слово «legacy» в переводе с английского языка означает «наследство». legacy проект, это проект, который уже давно написан (зачастую даже не теми людьми, которые занимаются этим проектом сейчас) и который до сих пор продолжает использоваться. Таким образом подобные проекты в некотором смысле «унаследованы» от предыдущих версий или коллег.
Какие бывают legacy проекты
Legacy проекты можно классифицировать по двум категориям: качество технической части и развитие.
По качеству технической части можно выделить две группы:
- Проекты, которые написаны и поддерживались квалифицированными специалистами назовём их для краткости «Проекты от профи»);
- Прочие проекты (проекты не профессионального качества).
В плане развития также можно выделит две группы:
- Развивающиеся проекты;
- Стагнирующие (не развивающиеся) проекты.
Рассмотрим каждую из этих четырёх групп более детально.
Проекты от профи
Как следует уже из краткого описания, приведённого выше, эти проекты были изначально написаны квалифицированными (чаще всего профессиональными) разработчиками, а позднее также поддерживались грамотными специалистами.
Если вы попали на такой проект, считайте, что вам повезло.
Подобные проекты достаточно легко развивать и поддерживать. С ними связан минимум издержек и рисков. На таком проекте можно получить очень хороший опыт.
Главное только самому ничего в нём не испортить.
Однако «проекты от профи» сравнительная редкость потому, что:
- Хороших специалистов самих по себе мало;
- Стоят такие проекты, как и их поддержка на должном уровне как правило не дёшево.
Проекты не профессионального качества
Фактически подобные проекты являются диаметральной противоположностью первой группы.
Обычно их разработкой и сопровождением занимаются люди, квалификация которых как программистов и т.д. вызывает существенные сомнения. Потому нет ничего удивительного в том, что уже на стадии разработки имеют место грубые нарушения соответствующих технологий. И, как результат последующая «жизнь» таких проектов тесно сопряжена со «слезами» тех, кто ими будет в последствии заниматься и даже использовать для решения своих бизнес-задач.
Таких проектов, к сожалению, очень много (если не большинство). И собственно, когда словосочетание «legacy проекты» используют в уничижительной форме, то имеют в виду как раз проекты из данной группы.
К слову, к данной группе относятся не только проекты, написанные «на коленке». В неё также может со временем перейти проект, изначально написанный вполне профессионально, но который сопровождали недостаточно компетентные специалисты.
Если у вас крупная организация и необходимо не допустить утечку информации, вам не обойтись без siem системы, которую мы рассмотрели в отдельном материале.
Развивающиеся проекты
Подобные проекты регулярно поддерживаются на актуальном (или хотя бы относительно актуальном) технологическом уровне. В них периодически внедряются новые решения, устраняются слабые места и т.д. Функционал также не отстаёт в своём развитии от бэкграунда.
В некоторых случаях даже не скажешь, что проекту на самом деле уже очень много лет. Настолько он современен.
Стагнирующие проекты
Это также диаметральная противоположность проектов, описанных нами только что.
Развитие подобных проектов в своё время (иногда даже сразу же после сдачи в эксплуатацию) фактически остановилось. Периодически они могут незначительно дорабатываться с целью добавления нового или изменения существующего функционала (задачи из разряда (утрированно) «добавить кнопку» или «поменять значок на кнопке») или устранения существенных ошибок. Но, в целом проект давно морально устарел.
Данное обстоятельство также накладывает сой отпечаток на перспективы его дальнейшего сопровождения.
Издержки и риски связанные с legacy проектами
Особенности legacy проектов порождают определённые издержки и риски при работе с ними.
Основные издержки это:
- Необходимость разбираться в работе больших объёмов исходного кода (зачастую совершенно незнакомого);
- Более высокие требования для «аккуратного» проектирования и реализации нового функционала (чтобы ничего не «сломать»);
- Необходимость более тщательного тестирования (в том числе регрессионного).
В свою очередь основные риски:
- Столкнуться с проектом непрофессионального качества или стагнирующим;
- Подводные камни;
- Стать «стрелочником».
На рисках следует остановиться более подробно.
Проект не профессионального качества или стагнирующий
Такие проекты не только не приносят интересного и полезного опыта. В первую очередь они увеличивают все возможные издержки.
Некачественный код или давно устаревшее решение само очень сложно сопровождать. В некоторых случаях реализация нового функционала без значительной модернизации проекта в целом не рентабельна или просто невозможна. Но, на модернизацию владельцы таких проектов обычно соглашаются неохотно.
Подводные камни
Нередко в процесс сопровождения legacy проекта вмешиваются неожиданные обстоятельства или технические препятствия о которых специалист по тем или иным причинам просто не мог знать. Это также увеличивает издержки проекта.
Количество и масштаб подводных камней как правило обратно пропорциональны качеству и технологической актуальности проекта.
Стать «стрелочником»
Заказчики и работодатели обычно склонны считать если не единственными, то главным виновниками всех бед специалистов, которые ведут проект именно сейчас. Даже несмотря на то, что де факто проблема была заложена очень давно.
Поэтому принимая проект «с пробегом» вы, по сути, принимаете на себя ответственность за грехи не только свои, но и всех ваших предшественников. Ошибки менеджмента, которые могли стать первопричиной тех или иных сложностей лучше оставить без комментариев.
Legacy проект для программиста
Многие, особенно опытные, программисты прекрасно понимают особенности legacy проектов и потому часто относятся к ним с осторожностью. Это вполне объяснимо. Ведь мало кому захочется взять на себя массу проблем и в итоге остаться крайним.
В целом же то очень многое на самом деле зависит от того насколько в конечном итоге «повезёт» с проектом.
Если действительно повезёт (без кавычек), то такой проект может не только принести программисту полезные знания и опыт, но и сам программист сможет максимально плодотворно реализовать в нём свой потенциал и тем самым принести максимальную пользу со своей стороны.
Если же наоборот не повезло, то на нём вполне можно и деградировать в профессиональном отношении (о профессиональной деградации программистов была отдельная статья).
Можно ли обойтись без legacy проектов
На самом деле можно. Но, только если вы (или ваша компания) занимаетесь написанием программ на заказ и специализируетесь только на новых проектах.
Но, проекты с нуля создаются не так часто. В том числе потому, что в этом нет необходимости. Зачем каждый раз всё создавать заново, когда можно просто добавить новые функции в уже существующее решение?
Важно подчеркнуть, что legacy проекты вовсе не являются своего рода «неизбежным злом». Подобное отношение к ним в корне не верно.
В том, что проект существует давно и на нём даже сменилось не одно поколение специалистов нет ничего плохого. Каждый legacy проект приобретает те или иные особенности только вследствие того, каким он был изначально создан или во что его впоследствии превратили те люди, в руках которых он оказался.
Источник: streletzcoder.ru