Комментарии 20
Думаю, что большинство PHP легаси проектов не поддерживают PHP 8.2.
Если проект приходится поддерживать и дорабатывать, всё равно нужно рано или поздно обновлять версию PHP. Практика показывает, что это делать не так сложно, по сравнению с обновлением зависимостей и тем более переработкой кода. Нужно исправить ворнинги, депрекейшены и прочие ошибки, о которых сообщает сам интерпретатор. Код переписывать не нужно.
Это видимо какие-то мелкие проекты. В нескольких компаниях сталкивался с "монструозным" легаси кодом, который очень тяжело и главное не очень то и нужно было бизнесу переносить с версии на версию.
На прошлой работе я начинал новый проект с нуля еще на PHP 7.1. Он дорос до более чем 100 000 строк кода в папке src/ и спокойно переживал обновления версии PHP раз в год-два. Это проходило существенно легче, чем, скажем, обновление мажорной версии Symfony. Кстати, коллега подключал и использовал инструмент Rector для автоматического исправления несовместимостей в коде, может кому-нибудь пригодится: https://github.com/rectorphp/rector
Бизнесу нужно объяснять необходимость обновления соображениями безопасности, производительности и привлекательности проекта для новых разработчиков.
Так 7.1 это далеко от слова легаси) я про настоящем легаси с версии php5, где есть какие-нибудь либы для memcahe или mongo которые работают состарым драйвером. Это все переписывать очень не просто)
Ну а привлекательность разработчиков можно купить) это может оказатся дешевле человеко-часов на переписывание или еще хуже падения прода
Очень сложный вопрос.
Разбора инцидента на habr конечно не будет, но гас правосудие недавно знатно упал на пару месяцев (злые языки говорили что не поднимут)
Есть такой страшный код или старые зависимости, которые просто так не обновишь. Например, у меня есть проект, написанный в 2008, который использует старую библиотеку работы с БД, которая <= php 5.5.
Проще проект переписать заново, чем обновлять в нем зависимости.
Можно отдельно запустить PHP 8.2 в контейнере, сейчас это несложно.
аха-ха, у меня 5.1)
Сначала хотел предложить ПР, а потом прочёл статью повнимательнее. Сорян, но в разработке методом "мне сейчас гопота код напишет а потом кожаные мешки его подправят" я не участвую.
Так что только словами. Нужен метод PdoDataProvider::escapeIdentifier(), и чтобы он соответственно везде применялся. Причём особенно нужен он именно при работе с легаси проектами - каких там только имён таблиц не бывает: и с пробелами, и с дефисами, и из ключевых слов. Ну и в целом минималный здравый смысл требует. Я даже сначала удивился что нету, пока не увидел, кто код писал.
То же самое, кстати, касается и имён плейсхолдеров, только там фиксить гораздо сложнее. При том что в целом при автоматическом составлении запросов использовать именованные плейсхолдеры смысла ноль.
Многое также становится на свои места. Я долго не мог понять, почему метод deleteEntity делает аж три запроса в БД.
Луддиты тоже не хотели на станках работать. По факту сейчас широко доступные нейросети способны заменить джуна-разработчика. За джунами тоже весь код нужно пересматривать, только выдают они его существенно медленнее. Что касается кода этого проекта, в нем не осталось ни одной строчки, которая бы мне не нравилась.
Метод escapeIdentifier в общем случае, видимо, нужен, запишу в бэклог. В моем случае с названиями таблиц и полей проблем не было.
Метод deleteEntity делает три запроса, чтобы понять, произошло ли реально удаление строки из БД. Мне захотелось сделать фичу с выводом сообщения об успешном удалении или об ошибке в процессе. Теоретически можно было бы использовать PDOStatement::rowCount(), но в документации явно сказано, что rowCount не работает в SQLite и не всегда работает в PostgreSQL. Вы можете предложить хотя бы один сценарий удаления сущностей из админки, когда три запроса вместо одного хоть как-то чему-то мешают?
AdminYard — минимальная админка на PHP для легаси-проектов
...
AdminYard работает в PHP версии 8.2 и выше.
Это же просто смешно.
Я, кстати, не уверен, что в легаси-проектах вообще может быть разделение на все эти сущности «Запись блога», «Комментарий» и прочие, которыми так удобно любят оперировать при представлении админок подобного толка. Зачастую «сущностью» в базе служит сотня строк в этой таблице и ещё тысяча-другая строк в соседней, редактирование которых по отдельности абсолютно бессмысленно. А потому проще и продуктивнее править это всё через нормальный клиент к БД, sqldeveloper там или DBeaver.
На днях этот же плагин опробовал. С ним у меня получается сгенерировать небольшие полезные кусочки кода по 5-10 строк. Это конечно тоже довольно хорошо. Но вот не получилось пока добиться чтобы этот интеллект создавал файлили по аналогии с другими, но для новых сущностей. Интересно, есть что-то для таких запросов?
Я было подумал, что ты AdminYard на днях опробовал :)
Не знаю как другие плагины, но Codeium еще весной был достаточно туповат и неповоротлив, так что сложно было понять, перевешивает ли польза его недостатки. Потом он стал работать быстрее и вроде как немного поумнел. В последних версиях по ощущениям он "запоминал" и использовал в своих подсказках контекст из соседних файлов.
Могу попробовать предложить временно копировать в новую сущность существующий код, чтобы нейросеть смогла подхватить паттерны из него. Подобным образом можно конвертировать, скажем, XML-конфиг в JSON. Прямо в начале xml-файла можно начать переписывать его содержимое в синтаксисе json, а автодополнение распознает и доделает эту задачу.
Каждый PHP программист должен в своей карьере написать админку или CMS.
А если серьезно, сейчас каждый фреймворк имеет удобный кодогенератор CRUD админок.
AdminYard — минимальная админка на PHP для легаси-проектов