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

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

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


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

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

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

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

Для проникновения усовершенствований PHP в Vimeo потребовалось какое-то время. Сначала нам пришлось избавиться от старой версии PHP (5.4), работавшей в продакшене долгие годы уже после истечения её «срока годности». Благодаря миграции на PHP 7 значительно ускорилась реакция бэкенда; кроме того, улучшенный синтаксис PHP 7 позволил нашим разработчикам писать чуть более чистый код с полной поддержкой типов возвращаемых значений и параметров.

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

Статический анализ — это круто

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

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

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

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

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

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

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

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

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

Последнее крупное обновление нашего ORM было выпущено десять лет назад. В него вошли некоторые незначительные усовершенствования — устранение багов, улучшенные типы и несколько новых фич, но базовая структура осталась неизменной.

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

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

• Эффективно выполняет свою задачу
• Прост для статического анализа
• Хорошо протестирован
• Идиоматичен

К счастью, созданное нами ORM удовлетворяет всем четырём критериям.

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

«PHP не обязан быть ужасным»

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

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

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

---

На правах рекламы

Эпичные серверы — это виртуальные серверы для размещения сайтов от маленького блога на Wordpress до серьёзных проектов и порталов с миллионной аудиторией. Создайте собственный тарифный план в пару кликов, максимальная конфигурация — 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe!