Что такое легаси проект
Что такое легаси в коде
Однажды, Симба, всё это будет твоим
Иногда программисты на вопрос, почему программа работает именно так, отвечают, что это «легаси» и исправить ничего нельзя. Разберёмся, что это значит, насколько это мешает разработке и что делают с легаси-кодом.
Что такое легаси
С английского legacy переводится как «наследие». Легаси-код — это код, который перешёл «по наследству» от предыдущих разработчиков. Чаще всего это происходит так:
👉 Проще говоря, легаси — это код, про который говорят: «Это ещё Михалыч писал 8 лет назад для синхронизации с сервером, он работает, мы его не трогаем, потому что иначе всё сломается». При этом Михалыча в компании давно нет, документации тоже нет, и проще этот код не трогать совсем.
Так как легаси — это старый код, то обычно на него завязаны многие важные вещи в программе. Получается замкнутый круг: отказаться от легаси нельзя, потому что без него всё сломается, но и поддерживать его в рабочем состоянии тоже сложно, потому что никто не хочет разбираться в старом коде.
Откуда берётся легаси
Причин появления легаси может быть несколько:
Легаси — это не какое-то преступление, а часть жизни любой живой ИТ-компании. Рано или поздно у любого продукта появится легаси. И чем крупнее проект, тем больше его будет. Например, в исходном коде Windows 10 до сих пор остаются фрагменты кода, написанные ещё 20 лет назад для Windows 3.1.
Легаси — это плохо?
Легаси — это просто старый код, который нужно поддерживать наравне с новым. Если он работает — отлично, пусть живёт. Другое дело, что команде, например, было бы удобнее, чтобы код был написан не на старом фреймворке, а на новом, который знают все.
Получается, главный минус легаси-кода не в том, что он работает плохо, а в том, что его неудобно поддерживать.
Что значит «поддерживать старый код»?
Например, в старом коде для запроса к серверу идёт сначала адрес, а потом номер запроса. Спустя 10 лет требования сервера изменились, поэтому сначала должен идти запрос, а потом уже адрес. Значит, нужно изменить порядок полей в коде.
Если старый код понятен и хорошо задокументирован, на эту задачу уйдёт две минуты. Если это старые пыльные легаси-кишки, то это может стать задачей на час.
Что делать с легаси-кодом
Если легаси-код работает и не требует вмешательства и поддержки — то можно пока ничего не делать, пусть работает. Будет время — перепишем на новый фреймворк, а если нет, то и так пока поработает.
А если нужно срочное вмешательство — пахнет бедой. Зовите менеджеров.
Код без тестов — легаси
Если вы работаете в 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.
Допустим, метод connect() вызывает проблемы, когда мы пытаемся поместить код в тесты. Получается, что весь класс — это «шов», который можно поменять. Можно расширить этот класс в тестах, чтобы предотвратить его подключение к реальной БД.
Есть и другие виды швов. Если язык позволяет изменять поведение кода без изменения исходного кода, у нас есть точка входа в написание тестов. Кстати о тестах…
Напишем unit-тесты
Дискуссии о лучших практиках тестирования обычно перерастают в холивары. Применять принцип пирамиды тестов, и писать максимум unit-тестов? Или использовать «Кубок тестирования» и писать в основном интеграционные?
Почему советы такие противоречивые? Потому что у них нет единого определения того, что такое «unit». Одни люди говорят об «интеграционных тестах» и тестируют всю библиотеку, а другие тестируют каждый класс по отдельности.
Чтобы избежать путаницы, Майкл даёт четкое определение того, что такое НЕ unit-тест:
он не работает быстро (
Похожие и интересные статьи:
О том, над чем в целом мы тут работаем: монолит, монолит, опять монолит.
Кратко об истории Open Source — просто развлечься (да и статья хорошая).
Больше новостей про разработку в Додо Пицце я пишу в канале Dodo Pizza Mobile. Также подписывайтесь на чат Dodo Engineering, если хотите обсудить эту и другие наши статьи и подходы, а также на канал Dodo Engineering, где мы постим всё, что с нами интересного происходит.
А если хочешь присоединиться к нам в Dodo Engineering, то будем рады — сейчас у нас открыты вакансии iOS-разработчиков (а ещё для Android, frontend, SRE и других).
Что такое legacy code?
Не могу найти перевод. Можете объяснить в двух словах что это такое? Что за понятие?
5 ответов 5
Legacy code — тяжелая наследственность : ) Устаревший код, который более не поддерживается и не обновляется, но используется. Второе значение — код от сторонних разработчиков, или из старых версий.
Суммирорав все определения, которые встречались, для себя вывел следующее.
Legacy code — код, подпадающий под один или несколько признаков:
Требование «опыт работы с legacy кодом» в вакансии означает, что вам достанется код, написанный лет 10-20 назад давно уволившимися программистами. Не исключено, что он изначально был плохо написан, что требования к проекту менялись уже много раз и каждый раз код правился как придётся в режиме жёсткого дедлайна, что документацию никто не писал и рефакторинг не делал. Поэтому вместо того чтобы писать новый код на прогрессивных технологиях, вам большую часть времени придётся разбираться в старом и править его, ловя потом каскады багов. Добро пожаловать в чудесный мир кровавого энтерпрайза, основного потребителя Java.
Всё ещё ищете ответ? Посмотрите другие вопросы с метками терминология или задайте свой вопрос.
Связанные
Похожие
Подписаться на ленту
Для подписки на ленту скопируйте и вставьте эту ссылку в вашу программу для чтения RSS.
дизайн сайта / логотип © 2021 Stack Exchange Inc; материалы пользователей предоставляются на условиях лицензии cc by-sa. rev 2021.12.10.40971
Нажимая «Принять все файлы cookie» вы соглашаетесь, что Stack Exchange может хранить файлы cookie на вашем устройстве и раскрывать информацию в соответствии с нашей Политикой в отношении файлов cookie.
Как выруливать с legacy code, когда проект нужно было на вчера
Привет. Меня зовут Иван Мельничук, я Head of Development Department в украинской IT-компании. В публикации хочу поделиться личными профессиональными подходами относительно решения вопроса legacy code в условиях стремительного развития проекта и рассказать о приемах, к которым прибегает наша команда в случаях “когда фичи нужно сдавать “на вчера”.
Разбираемся с проектом
Для того, чтобы передать насколько аккуратной, продуманной и кропотливой, должна быть работа с легаси, приведу аналогию с карточным домиком.
Именно так выглядит устаревший код. Если мы решим убрать или заменить хотя бы одну карту из этой постройки, мы рискуем завалить весь дом и сровнять его остатки с землей.
Понять бизнес
Бизнес считает деньги. Бизнес не хочет тратить дополнительный финансовый ресурс просто на переделывание того, что уже и так работает. Бизнес никогда не купит идею: “сделаю по-новому потому, что мне это не нравится”. Поэтому всегда предлагайте больше.
Часто разработчики задвигают бизнесу бесполезные идеи. По этому случаю есть отдельный “фонд золотых цитат”.
П — Планирование
Для быстрой и эффективной работы с техническим долгом нужен план.
1. Определение задач, на которых будем паразитировать. Почему паразитировать? Часто бывает: мы продали фичу, а под ней частично подразумеваем рефакторинг.
2. Определение требований высокого уровня. Необходимо прописать четкий запрос бизнеса по “высокой планке”, дабы составить правильную документацию.
3. Определение основных модулей системы, наложение модулей. Перед стартом рефакторинга, нужно понять основные модули системы: где, как, что и с чем может взаимодействовать и разграничивать код на секции.
4. Определение интеграции. При создании конкретного модуля мы должны заранее продумать возможность вмонтировать его в соседний легаси.
5. Определение команды. Один в поле рефакторинга не воин. Команда — очень важный элемент успешного результата. Задор, командный драйв и отличное взаимодействие между участниками процесса must have.
6. Как будем тестить? Если вы собираетесь сдавать качественный проект, то нужно заранее продумать и варианты тестирования продукта.
Наряду с перечисленным выше также важно определить, каким должен быть желаемый конечный результат, составить план масштабирования и прописать узкие места проекта. Например, в случае масштабирования кода важно понимать, где потенциально могут возникнуть проблемы в условиях highload (это может быть база данных, или тяжелые запросы, или сетка, или еще какое-то промежуточное звено, способное “упасть”).
Не менее важно определить границы проекта, где был старый код и где будет новый уровня “шедевр”. Также следует продумать подходы по микросервисам, или DDD, или, возможно, понадобится еще какая-то “наномагия”.
Ниндзя-вские техники работы с легаси
После “подготовительных работ” подходим к техникам, которые облегчают процесс спасения технического долга. Универсального рецепта и панацеи от всех бед в легаси не существует, но по ходу работы на highload проектах составил список ингредиентов, с помощью которых можно приготовить действительно “вкусный” код.
1. Не изобретать велосипед. Для меня это главный лайфхак по написанию кода. Уже все придумано до вас, не стоит прибегать к танцам с бубнами и прочим экспериментам для решения вопросов с legacy code.
2. Код стандарт. Без единого стандарта каждый разработчик будет писать по-своему. “Авторский стиль” поспособствует хаосу и нарастит еще больше код-хлама.
3. Код ревью. Мало только одного наличия код-стандарта. Нужно еще, чтобы в команде был ответственный за его проверку. Иначе все вернется на круги своя, то есть к уровню старого кода.
4. Static Code analyzers, PHP mess detector etc (вместо тысячи книг). Эти и другие автоматические виды техники понадобятся для ускорения процесса, в частности с тем же код ревью.
5. Пробуем микросервисы. Отдельно также могут быть модули или библиотеки. Почему именно микросервисы? Их преимущество в максимальной изоляции логики и ограничении ее определенным API. Плюсом последней является то, что API представляет собой более монолитную сущность по сравнению с “адаптером в коде, которым можно поправить”. Однако у API есть один недочет в виде дополнительных расходов на сеть.
6. Архитектура БД, источники данных. Именно базу данных считаю первым “узким” местом любого легаси. Но каждый проектирует, как хочет, и даже в SQL можно найти неафишируемые недостатки. Вот несколько советов по работе с новой БД:
8. Декораторы, адаптеры, медиаторы … Эти паттерны одни из главных для интеграции нового кода в старое легаси.
9. План Б, или план отката при интеграции. Многие делают ошибку, что забывают о нем. Он жизненно необходим в ситуации “когда что-то пойдет не так” при заливке нового материала. То есть как только мы начинаем строить архитектуру, уже на этом этапе мы должны понимать, как будем откатывать ее назад в случае бага.
10. Новый код без (доки) тестов через неделю становится легаси. Насколько красивым ни был бы ваш код, без документации через неделю он будет в статусе “legacy” — по причине своей непонятности.
11. Тестирование. Если юнит-тесты не по карману, то используем смоук, функциональные и интеграционные тесты. Насколько реально продать юнит-тесты бизнесу под соусом “чтобы сделать работу красиво?”. В наших реалиях это скорее редкость, нежели закономерность. Если же с “юнитами” по какой-то причине не складывается, то обращаемся к смоук, функциональным или интеграционным тестам, а также не забываем, что можем делегировать задачу, например, мануальному тестировщику.
Вместо эпилога
Самое главное в этой истории — сделать работу и не оставить после себя в наследство легаси и 6 проблемных стадий (приведены в порядке от простой к более сложной):
Ты приходишь в проект, а там легаси…
Привет, сегодня я хочу поговорить об ужасной кодовой базе, с которой вы, скорее всего, прямо сейчас имеете дело. Есть проект и вы нужны, чтобы добавлять новые фичи и фиксить баги. Но вы открываете IDЕ, делаете пул репозитория с проектом — и хочется плакать. Кажется, что с этим кодом невозможно работать.
Картина, конечно, немного удручающая, но… давайте отбросим эмоции. И посмотрим, что можно быстро предпринять, чтобы облегчить страдания.
Почему мы чувствуем себя несчастными, работая с легаси-кодом?
Если порассуждать, легаси не так уж и плох: это значит, что проект жив, он приносит деньги и в нем есть какая-то польза. Конечно, круто, когда мы сами с нуля выбираем язык, базу данных, систему обмена сообщениями, проектируем архитектуру — но няшный стартап может так никогда и не попасть в прод. А легаси — уже радует пользователей.
Но с точки зрения старшего разработчика часто все выглядит так:
приложение очень хрупкое: если фиксим где-то баг, в ответ прилетают два новых;
новые фичи занимают все больше времени: откладываются релизы, давят дедлайны, вы начинаете сознательно увеличивать время на планировании.
Причиной этих бед, как правило, является огромный объем технического долга — и отношение к нему в команде. Тесты, рефакторинги требуют времени. Конечно, когда важнее деливерить фичи, хочется на это забить. И я думаю, мы сами допустили подобное в индустрии.
У меня есть одна история. Приходит менеджмент, говорит, что нам нужна эта фича, причем «еще вчера». Мы работаем изо всех сил, релизим как можно быстрее. Затем говорим менеджменту: «Теперь нам нужна неделя, чтобы отрефакторить, написать тесты». На что менеджер отвечает: «Что? Вы этого не сделали?».
Когда вас просят сделать что-то, от вас ожидают что-то готовое. А если фича нужна настолько срочно, что к ней даже не нужна «пожарная сигнализация» в виде тестов, это должно быть оговорено в самом начале. И наша задача как разработчиков донести это до бизнеса. Я хочу поделиться подходом, который мы применили в команде мобильного бэкенда Skyeng — это путь инкрементального улучшения легаси-проекта.
Что будет, если ничего не делать (и почему переписать не всегда выход)
Каюсь, как-то раз я работал в компании, где использовался подход «нет времени ничего менять, давайте быстро пофиксим». Мы продолжали добавлять фичи, плодить (и фиксить) всё больше багов. Мы лечили не болезнь, а лишь ее симптомы. Я на практике столкнулся с «эффектом разбитых окон». Начав делать фиксы по принципу «лишь бы просто работало» и заметив, что, в принципе, и новичкам и старичкам в команде всё равно, мы начали жить по принципу: быстрый фикс, копи-паста, костыль — сделали, зарелизили, забыли.
Становилось всё хуже и хуже. Всё это привело к серьезному стрессу и потере мотивации. В конце концов, не дожидаясь, когда мы подойдём к моменту, что всё это станет не поддерживаемо, я ушел.
Есть другая крайность. Мы видим старую систему. Думаем: «Если тот криворукий, кто написал этот ужас, смог заставить всё работать, то наверняка это просто. Давайте перепишем всё уже по-нормальному. Сделаем красиво». Но это ловушка. Легаси-код уже пережил много деплоев и изменений требований. Начиная с начала, мы думать не думаем и знать не знаем о всех тех трудностях, которые пережил тот код. Да, мы пытаемся делать предположения, но зачастую они неверны. Почему так?
Есть старая команда, которая поддерживает легаси-проект, и новая — у нее обычно нет большой накопленной экспертизы ни в домене, ни в легаси-коде. Новая команда будет делать слишком много предположений о системе. И не всегда угадает.
Я не хочу сказать, что это не работает. У меня есть позитивный опыт переписывания легаси-системы: но, во-первых, тот, кто писал старый проект, и переписывал его. Во-вторых, бизнес дал добро, что на определенный промежуток времени мы замораживаем систему — ничего больше не добавляем, не фиксим без крайней необходимости. Плюс у нас под рукой всегда был доменный эксперт. Но у меня до сих пор есть ощущение, что нам повезло и это было скорее исключение, подтверждающее правило.
Шаг первый: пишем smoke-тесты, которые скажут, что приложение хотя бы живое
Иметь тесты действительно важно для бизнеса. И если тестов до вас не было, а вы решили что-то улучшать, начните с них. Возможно, на данном этапе вам не нужны «правильные тесты» — юнит, приемочные и т.д. Начните с «просто тестов», которые будут рассматривать приложение как черный ящик, — и покройте хотя бы критические эндпоинты. Например, убедитесь, что после рефакторинга регистрации приложение хотя бы не пятисотит.
Что использовать? Нам понравился Codeception — у него приятный интерфейс, можно быстро накидать smoke-тесты на наиболее критичные эндпоинты, сами тесты выходят лаконичными и понятными. А еще у него такой выразительный API и тест можно читать прямо как user story.
Что покрывать? Правило простое: покрываем тот функционал, который отвечает за бизнес-домен. В нашем случае это были тренировки слов — мы покрыли smoke-тестами его. Например, у нас был эндпоинт, который отдавал выученные пользователем значения слов.
Мы явно прописали эндпоинт, который будем тестировать, и через аннотацию @see сделали указание на контроллер. Это удобно тем, что по клику в IDE можно сразу перейти в контроллер. И наоборот, по клику на экшен контроллера можно перейти в тест.
Сам тест был максимально прост: подготавливаем данные, сохраняем в базе выученное пользователем слово, авторизуемся под этим юзером, делаем get-запрос к API и проверяем, что получили 200.
Такой тест — это самое простое, что можно сделать, но это уже дает подушку безопасности. Теперь мы могли быть уверены: после рефакторинга приложение не запятисотит.
Но потом нам захотелось большего, и мы допилили тест: стали дополнительно проверять схему ответа и что в нем вернулось действительно то, что нужно. В нашем случае — выученное слово.
Так постепенно мы покрыли все критичные части нашего приложения — и могли перейти непосредственно к коду.
Недостаточно просто написать тесты — важно их поддерживать максимально наглядными, понятными и легко расширяемыми. Нужно относиться к коду тестов так же трепетно, как мы относимся к коду приложения, которое тестируем.
Шаг второй: удаляем неиспользуемый код
В проекте не нужен код, который «потом понадобится». Потому что нас есть git, который уже его запомнил. Надо будет — восстановим.
Как понять, что удалять, а что нет. Довольно легко разобраться с каким-то доменным или инфраструктурным кодом. Совсем другое дело — API и эндпоинты. Чтобы разобраться с ними, можно заглянуть в NewRelic и проекты на гитхабе. Но лучше прямо сходить к командам и поспрашивать — может статься, что у вас есть какой-то эндпоинт, из которого аналитика раз в год выкачивает важные данные. И будет очень некрасиво удалить его, даже если по всем признакам его никто не вызывал уже почти год.
Шаг третий: делаем слой вывода
Очень часто в легаси-приложениях либо сущности торчат наружу, либо где-то в контроллере собирается и отдается массив. Это плохо — скорее всего, у вас нарушена инкапсуляция и у сущности есть публичные свойства. Такое тяжело рефакторить: клиенты в ответе уже ожидают определенные поля, и если мы захотим переименовать или сделать приватным какое-то свойство, то даже обнаружив и пофиксив все использования, мы имеем шанс что-то сломать и разбираться с фронтом.
Например, у нас есть контроллер, который возвращает баланс пользователя. В этом примере мы просто достаём из репозитория сущность и как есть отдаём наружу — то есть как только мы порефакторим, API у клиента поменяется.
Чтобы решить проблему, можно вместо этого в ответах всегда использовать простую DTO — пускай у нее будут только те поля, которые нужны в ответе клиентам. Добавим маппинг из сущности и уже в контроллере это вернем.
Всё, больше слой вывода никак не привязан к доменному коду, сам код стал более поддерживаемым.
Можно спокойно начинать улучшать и рефакторить, не боясь сломать обратную совместимость API.
Шаг четвертый: статический анализ кода
В современном PHP есть strict types, но даже с ними можно по-прежнему менять значение переменной внутри самого метода или функции:
А так как типы проверяются в runtime, проверки могут зафейлится во время выполнения программы. Да, всегда лучше упасть, чем словить проблем из-за того, что строка внезапно превратилась в число (причем не то число, которое мы бы ожидали увидеть). Но иногда хочется просто не падать в runtime. Мы можем выполнить проверки до выполнения кода с помощью дополнительных инструментов: Psalm, PHPstan, Phan и так далее.
Код неочевиден. Нам придется залезть в сервис, чтобы узнать, какие поля там используются. Статическим анализом мы можем явно указать, что в этот метод нужен такой-то массив с такими-то ключами, а под ключами — значения определенных типов.
Прописав через докблоки формат и тип данных, при следующем рефакторинге мы запустим Psalm, он проверит все возможные вызовы и заранее скажет, сломает ли код. Достаточно удобно при работе с легаси.
Что дальше?
Получите контроль над существующей кодовой базой, поймите, как она работает, и попытайтесь немного привести ее в порядок. Имея в арсенале тесты, статанализ и постепенно вычищая код, вы сможете приступать к более серьезному рефакторингу и улучшать качество продукта.
А дальше — просто подумайте, что еще нужно, чтобы чувствовать себя счастливым, работая с этим кодом. Чего еще не хватает? Составьте себе план действий и постепенно улучшайте доставшийся вам в наследство код.
p.s. Несколько полезных материалов для дальнейшего изучения:
Пост основан на докладе с краснодарского PHP-митапа — вот его запись