Простые решения, простая жизнь!
Легаси - часть кода, со скрытыми слоями, которая делает что то и никто не знает как именно она работает. Фактически наличие легаси в проекте значит утерю понимания и прозрачности кода
Возможно код устарел и на тех технологиях уже не пишет никто либо команда которая закладывала основы уволилась и теперь никто не понимает что там есть
Документация не всегда способна помочь, т. К. Она описывает то что есть а проведение любых изменений может привести к появлению багов в других не связанных местах
Легаси можно максимально отодвинуть или предотвратить если следовать рекомендациям
- минимально используйте наследие в ооп. У вас должна быть очень везкая причина чтобы унаследовать класс. Если каким то образом вы наследуете класс который уже наследуется от другого - это уже путь в никуда. Любые дальнейшие правки базовых классов обязательно аукнуться в других местах в будущем
Наследование от классов фреймворка не считается, если оно для этого изначально было спроектировано (в фреймворк вы ведь не будете изменения вносить? ) - избегайте маппинга на ровном месте. Если у вас основные данные находятся в базе - используйте эти названия таблиц и полей для всех остальных переменных и классов с минимальными искажениями. Если допускаете искажение - оно должно быть единым во всём проекте. Множественное число, заглавные буквы. При изменении названий в базе - меняйте и переменные. Никаких исторически сложилось. И сразу
Названия файлов, папок и URL также должно максимально точно повторять описание полей и таблиц. Это также поможет при отладке - добавляйте комментарии там где через переменные или смысл не получается полную картинку описать. Это может быть текст задачи по локальному изменению алгоритма какого то блока или описание общего смысла скрипта. Особенно это важно при наличии множества похожих по смыслу блоков
- не дублируете логику которая отвечает за что то конкретное. Логика формирования паролей, подключений. Она может измениться и правок этих зависимостей должно быть как можно меньше. Но без фанатизма. Да, это что-то похожее на S в Solid
Нужно отличать вещи которые однажды изменяться и сразу везде и вещи которые однажды изменятся локально
Посыл один и тот же - соблюдайте простоту и прозрачность как можно дольше. Минимум преобразований на пустых местах и необоснованного непонятного кода
Приходилось вам решать похожие задачи? Может у вас есть какие рекомендации которые я могу упустить, предлагаю обсудить это в комментариях