За последний год разработчики Vimeo написали бэкенд-код на множестве языков-PHP, Go, Ruby, Python, NodeJS, Java, C, C++ и немного Rust.

В 2004 году мы начинали только с одного: PHP. Это был идеальный язык для совершенно новых стартапов, таких как Vimeo. Интерпретатор PHP позволил предпринимателям быстро разрабатывать прототипы, и он пришел с большой стандартной библиотекой, которая сняла хлопоты с обычных задач, таких как отправка электронной почты и доступ к базам данных.

Большинство стартапов терпят неудачу, но некоторые PHP-стартапы все еще живые даже 10 лет спустя. Некоторые из них достигли стремительного роста, и некоторые из них (в первую очередь Facebook) решили, что PHP является узким местом, и начали мигрировать с него. Для этого было две большие причины: производительность PHP и проблема поддержания больших кодовых баз PHP.

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

За десять лет, прошедших с 2004 года, Vimeo выросла во много раз, а вместе с ней и наша кодовая база PHP, но мы выросли недостаточно, чтобы эти проблемы действительно встали у нас на пути. Однако, когда Facebook публично отказался от PHP, некоторые разработчики здесь подумали, что PHP находится на пути к тому, чтобы стать Фортраном эпохи Интернета. Новая волна бэкенд-инженеров планировала, как мы могли бы вырезать 500 000 строк PHP в кучу более хорошо спроектированных, быстрых и тестируемых сервисов Go.

Какое-то время это казалось неизбежным, но мы так и не смогли отказаться от PHP. Были некоторые очевидные причины — переписывание всей кодовой базы является ресурсоемким и подверженным ошибкам, но также и несколько менее очевидная: PHP стал лучше.

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

Потребовалось некоторое время, чтобы улучшения PHP появились в Vimeo. Сначала нам нужно было избавиться от старой версии PHP — 5.4, которую мы запускали в производство много лет спустя после истечения срока ее действия. Переход на PHP 7 сделал наши бэкенд-ответы намного быстрее, а в качестве бонуса улучшенный синтаксис PHP 7 позволил нашим разработчикам писать немного более чистый код с полной поддержкой типов return и param на уровне языка.

PHP не перестает внедрять инновации — версия 8, выпущенная две недели назад, приносит много улучшений на уровне языка, которые позволят нашим разработчикам более лаконично выражать бизнес-логику. Мы с нетерпением ждем обновления в начале следующего года.

Статический анализ – это потрясающе

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

Я тоже иногда стрелял себе в ногу с PHP, но вместо того, чтобы сдаться, я решил создать инструмент, который улучшил бы мою цель. Так родился Psalm – средство проверки типов статического анализа для PHP.

Основная функциональность Psalm в целом похожа на проверку TypeScript, заимствуя некоторые идеи из языка Facebook (производного от PHP) под названием Hack. Psalm говорит вам, когда PHP-код может вызвать ошибку типа, а также когда ваша логика не имеет смысла. Он добавляет некоторые дополнительные функции, такие как обнаружение неиспользуемых классов и методов, и может исправить многие проблемы, которые он находит автоматически.

Использование Psalm в качестве части нашего конвейера CI в последние несколько лет оказало трансформационное влияние на то, как мы пишем PHP в Vimeo: Psalm дал нам уверенность в том, что мы можем вносить крупномасштабные изменения, не беспокоясь о том, чтобы сломать абсолютно все.

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

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

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

Старый код не обязательно является устаревшим кодом

В середине 2000-х годов не было ни одного хорошо зарекомендовавшего себя PHP ORM, поэтому мы создали свой собственный. К счастью, PHP предоставляет множество строительных блоков для создания простого ORM в стиле ActiveRecord, включая поддержку MySQL, привязку параметров запроса и волшебные геттеры и сеттеры. Помогло и то, что у нас было несколько действительно умных инженеров, которые справились с этой задачей.

Последнее крупное обновление ОРМ произошло десять лет назад. Он имел некоторые незначительные улучшения-исправления ошибок, лучшие типы и несколько новых функций, но базовая структура не изменилась.

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

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

• Делает свою работу эффективно
• Прост в статическом анализе
• Хорошо проверено
• Это идиоматично

К счастью, наш существующий ОРМ отвечает всем четырем требованиям.

Сохранение надежного старого кода также дает нам возможность сосредоточить наши инженерные усилия на вещах, которые приносят материальную выгоду бизнесу, и я по контракту обязан (но также и рад) сказать, что Vimeo в последнее время находится на подъеме, с тонной замечательных новых продуктов, таких как Vimeo Record.

“PHP не обязательно должен быть ужасным”

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

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

Ренессанс PHP превратил по крайней мере одного бывшего отрицателя. Однажды коллега и давний критик языка отвел меня в сторону и очень искренне поблагодарил за то, что я показал ему, что “работа с PHP не должна быть ужасной.”

legacy в it

Оригинал https://medium.com/vimeo-engineering-blog/its-not-legacy-code-it-s-php-1f0ee0462580