Вынести legacy код в изолированный сервис с ограниченным доступом, и забить на обновления — вполне рабочее решение. Встречайте в каждом банкомате мира :)
Знаешь, я вижу два мира, которые обычно не встречаются, а тут в комментариях не могут понять друг друга. Один мир — это enterprise, который хочет дженериков и радуется аннотациям. Маленькие винтики больших систем, готовые все отрефакторить за месяц-другой. Боец рефакторит — зарплата идет.
Другой мир — это веб-студии, в которые идут владельцы тысяч сайтов, а некоторые сайты написаны были еще на PHP 4. Этих сайтов были миллионы, и десятки тысяч все еще живы. Платить за рефакторинг у владельцев желания нет, но немного заплатить за продление жизни готовы. Они решают проблемы по мере их появления, и чем дешевле решение — тем лучше.
К сожалению, нет стандартов NIST, Open Group или каки-либо других для оценки языков программирования с точки зрения применимости в enterprise.
Я бы назвал Java основным языком для мобильных устройств, но в промышленности он тоже широко применяется.
Про синхронность речь не идет. Если писать точнее, PHP с помощью curl позволяет выполнять http-запросы в неблокирующем режиме.
Есть городская легенда среди разработчиков на других платформах, что в PHP доступен только блокирующий режим. Однако, это не так. Для PHP даже принят стандарт PSR 7, чтобы абстрагироваться от http-протокола и запросов.
Чтобы не работать с HTTP-запросами, есть к примеру, Guzzle. Аналогичный функционал есть в популярных фреймвоках.
Если что-то депрекейтед, варнинг или нотис — таки да.
А вот если что-то типа 0 == "" которое из тру внезапно стало фалсе, несмотря на 42 == " 42" так и оставшийся тру, при том что 42 == «42foo» стал фалсе — то тут беда, т.к. код как был абсолютно рабочим, так и остался.
Да, проблема такая есть!
У всех есть 2 года, чтобы адаптировать приложения, с 2023 PHP7 превращается в тыкву. Это много, много строк кода, и не всегда можно заменить if (foo()==0) на if (foo()===0 || foo()==='0').
Интересная тема для исследования и для статьи, может быть, даже для стартапа. Сейчас подумаю на эту тему.
Да, на php работает 80% middleware крупных интернет-проектов всего мира. Ссылка. 30% — wordpress, а 50% — системы enterprise-уровня.
PHP активно используется в корпоративной среде, наряду с Java, почему и наблюдаем развитие только тех фич, которые востребованы в крупных сложных проекта. Никита с Димой не бесплатно работают. Аннотации, JIT, типизация в CMS использоваться не будут. Это сложный функционал, развитие которого финансируется enterprise-проектами.
если бы какой-то код не запустился на какой-то версии или выдавал бы ошибки, но ведь он запустится на обоих и без всяких ошибок выдаст разные результаты
Дело в том, что такая ситуация везде и с любыми программами. В python аналогично, в JS режим strict решает не все проблемы.
Компилированные приложения, написанные на С/RUST/golang, при замене libc успешно запустятся, но ломаются на несовместимости ABI. О проблемах с ПО, которое написано под Windows 7, под 10-кой, думаю, знают все.
Любое ПО требует сопроводительной документации и указания версий.
Объемы изменений синтаксиса показывают статические анализаторы, в том числе PHPStorm.
Проблемы возникают с расширениями и сторонними библиотеками, которые не поддерживаются, или когда новые версии не совместимы со старыми.
Надо планировать срок жизни каждого стороннего продукта. Когда разработчики принимают к эксплуатации любую стороннюю библиотеку — надо планировать когда вы ее замените, удалите, или быть готовым к поддержке ее кода в будущем.
В целом — хорошо было бы жить вечно.
Дело в том, что кроме ввода в эксплуатацию оборудования и ПО надо планировать и его вывод.
Сроки жизненного цикла версий PHP известны на много лет вперед, запланировать обновление в следующем году не так сложно.
В php не так много проблем обратной совместимости между версиями. У меня был случай, когда огромную enterprise-систему с десятком команд общей численностью в несколько сотен человек обновили с PHP 5.3 на 7 менее, чем за месяц.
Кое-что переписывать приходится. Однако, эти строки не надо искать, их показывают IDE и статические анализаторы. Почему обычная штатная поддердка считается проблемой — это уже вопрос не технический.
Я думал о том, как привести пример рефакторинга. Просто кода недостаточно, надо показать как код меняется. Сначала надо прочесть пример кода со связанностью по ссылке «до изменений», потом результат рефакторинга по ссылке «после изменений», и для удобства ссылка на diff коммита.
Спасибо! Мое утверждение о невозможности подменить PDOStatement ложное, пропустил эту константу :)
Вернулись к тезису о процедурном программировании. Пользоваться PDO неудобно. Нужно изучить десятки констант и неочевидное поведение.
Доработка PDO — это то, что было бы востребовано во всех приложениях. Намного более востребовано в мире, чем те же дженерики.
Другой мир — это веб-студии, в которые идут владельцы тысяч сайтов, а некоторые сайты написаны были еще на PHP 4. Этих сайтов были миллионы, и десятки тысяч все еще живы. Платить за рефакторинг у владельцев желания нет, но немного заплатить за продление жизни готовы. Они решают проблемы по мере их появления, и чем дешевле решение — тем лучше.
Вопрос в том, как помочь вторым?
Я бы назвал Java основным языком для мобильных устройств, но в промышленности он тоже широко применяется.
простите, не понимаю о чем Вы
Есть городская легенда среди разработчиков на других платформах, что в PHP доступен только блокирующий режим. Однако, это не так. Для PHP даже принят стандарт PSR 7, чтобы абстрагироваться от http-протокола и запросов.
Чтобы не работать с HTTP-запросами, есть к примеру, Guzzle. Аналогичный функционал есть в популярных фреймвоках.
Да, проблема такая есть!
У всех есть 2 года, чтобы адаптировать приложения, с 2023 PHP7 превращается в тыкву. Это много, много строк кода, и не всегда можно заменить if (foo()==0) на if (foo()===0 || foo()==='0').
Интересная тема для исследования и для статьи, может быть, даже для стартапа. Сейчас подумаю на эту тему.
PHP активно используется в корпоративной среде, наряду с Java, почему и наблюдаем развитие только тех фич, которые востребованы в крупных сложных проекта. Никита с Димой не бесплатно работают. Аннотации, JIT, типизация в CMS использоваться не будут. Это сложный функционал, развитие которого финансируется enterprise-проектами.
Спасибо за комментарий. Java, C#, MySQL и Postgres так же ломают обратную совместимость в новых мажорных версиях.
Добавлю уточнение: обновление приложения в моем случае было полным, соблюдали SLA 5 девяток, то есть, бешовно.
Дело в том, что такая ситуация везде и с любыми программами. В python аналогично, в JS режим strict решает не все проблемы.
Компилированные приложения, написанные на С/RUST/golang, при замене libc успешно запустятся, но ломаются на несовместимости ABI. О проблемах с ПО, которое написано под Windows 7, под 10-кой, думаю, знают все.
Любое ПО требует сопроводительной документации и указания версий.
Надо брать анализаторы кода, эту проблему видят практически все — усилий и времени на нее больше не потребуется.
Может быть, Rector делает автоматическую замену. PHPStorm заменяет объявление конструктора по клику мышки.
Объемы изменений синтаксиса показывают статические анализаторы, в том числе PHPStorm.
Проблемы возникают с расширениями и сторонними библиотеками, которые не поддерживаются, или когда новые версии не совместимы со старыми.
Надо планировать срок жизни каждого стороннего продукта. Когда разработчики принимают к эксплуатации любую стороннюю библиотеку — надо планировать когда вы ее замените, удалите, или быть готовым к поддержке ее кода в будущем.
Дело в том, что кроме ввода в эксплуатацию оборудования и ПО надо планировать и его вывод.
Сроки жизненного цикла версий PHP известны на много лет вперед, запланировать обновление в следующем году не так сложно.
В php не так много проблем обратной совместимости между версиями. У меня был случай, когда огромную enterprise-систему с десятком команд общей численностью в несколько сотен человек обновили с PHP 5.3 на 7 менее, чем за месяц.
Кое-что переписывать приходится. Однако, эти строки не надо искать, их показывают IDE и статические анализаторы. Почему обычная штатная поддердка считается проблемой — это уже вопрос не технический.
Вернулись к тезису о процедурном программировании. Пользоваться PDO неудобно. Нужно изучить десятки констант и неочевидное поведение.
Доработка PDO — это то, что было бы востребовано во всех приложениях. Намного более востребовано в мире, чем те же дженерики.