Что такое легаси код и почему его так не любят, особенно в PHP

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

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

Итак начнем.

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

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

И конечно же любители таких конструкций часто избавляются от так называемого синтаксического сахара, что делает не только трудно читаемым большие массивы кода, но и усложняет его доработку. Туда же goto, break/continue и т.д.

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

Замыкания или анонимные функции, туда же анонимные классы и методы внутри методов.

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

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

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

Обозначим случаи, когда глобальные переменные нужны:

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

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

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

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

Это наверное не плохо, до определенной степени, как и все в нашем мире все хорошо в меру.

Чем же это плохо?

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

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

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

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

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

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