«Комьюнити у PHP сейчас одно из самых активных»: интервью c разработчиком Yii Framework Александром Макаровым
2026-02-26 17:24 Diff
https://ru.hexlet.io/blog/posts/intervyu-c-razrabotchikom-yii-framework-aleksandrom-makarovym

Вокруг языка программирования PHP достаточно давно существует огромное количество мифов, в том числе что он постепенно умирает. Однако на нём работает очень большая часть Интернета, язык постоянно обновляется, а вокруг него сформировалось одно из самых активных и больших сообществ разработчиков. Мы поговорили с разработчиком одного из фреймворков для PHP Yii Framework Александром Макаровым — о том, как попадают в PHP, какую роль играет опенсорс в карьере, почему пропали токсичные программисты и куда вообще движется этот язык разработки.

Содержание

C Java Enterprise edition на PHP

— Какой у вас был первый язык программирования?

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

Первая моя настоящая работа была на Java Enterprise Edition в компании Siemens. Там оставалось много свободного времени, за которое я неплохо изучил PHP, C# — да и вообще, достаточно много технологий — на что было время, то и брал. Другие языки и вообще какие-то новые инструменты меня никогда не пугали.

— Почему вы дальше начали заниматься именно PHP?

— На самом деле я очень много времени провел c Java. Мой опыт постепенно набирался, я общался с коллегами и понимал, что они тоже постоянно учатся, и было бы классно делиться знаниями. В один момент я решил завести свой блог — в то время этим занимались все подряд. Посмотрел, на чем их делают: тогда все создавали блоги на WordPress, который превращает весь код в постах в непонятную кашу. Поэтому я взял и самостоятельно написал свой блог — на Java. Потом стало понятно, что из-за выбора Java мне приходится отдавать много денег на поддержку сайта — тогда еще Docker не было, а хостинг для Java был дорог. Я посмотрел, на чем работают остальные — самыми дешевыми были PHP и Perl.

Учитесь:

Трек ООП в PHP с отдельным проектом

Тогда еще был распространен язык программирования Parser, который создала студия Артемия Лебедева — первая переработанная версия моего блога как раз была написана именно на нём. Позже я понял, что мне хочется больше возможностей, и переписал всё на PHP.

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

Когда я только начал разбираться с PHP, у меня начался своеобразный кризис разработчика — уныние из-за того, что много времени приходилось тратить на старте проекта. Тогда я нашел фреймворк CodeIgniter, который это решал и где код более или менее не превращался в полный ужас. Я достаточно долго работал на нём — мы сделали свое русскоязычное сообщество, перевели всю документацию на русский язык и в общем-то достаточно хорошо всё это развивали.

В один момент я залез внутрь CodeIgniter и ужаснулся тому, как там все выглядит. Тогда стало понятно, что нам дальше не по пути.

Тем более, что разработчики этого фреймворка начали фокусироваться на своих коммерческих продуктах и откровенно подзабили на поддержку CodeIgniter. Поэтому даже мои первые попытки сделать что-то в опенсорсе ни к чему не привели — мои предложения было просто некому рассматривать.

Тогда же я начал смотреть другие фреймворки — первый Symfony, первый Zend, но мне не понравилось. Пробовал какое-то время писать на CakePHP, но там были большие несоответствия между тем, что написано в документации, и тем, что есть в реальности.

Как попасть в опенсорс и что это дает

В это время мне попадается Yii-фреймворк с ужасным сайтом и вообще, все это выглядело как дикий треш. Несмотря на это, у него была хорошая документация, а весь код работал именно так, как в ней описывается — что достаточно большая редкость для того времени. Мне понравилось работать с Yii, поэтому я отправил несколько изменений — и создатель фреймворка Тян [Qiang Xue] нормально на это реагировал, так я начал подтачивать инструмент под себя. В какой-то момент ребята просто мне сказали, что я присылаю им много кода неплохого качества, им надоело на него смотреть, поэтому мне нужно самостоятельно отправлять его в trunk (это такой master в SVN был).

Так я попал в core team фреймворка Yii, и так закончился мой путь в аутсорс-разработке. Как только я пришел в Yii и немного там поварился, меня начали звать к себе классные компании, которые работали с этим фреймворком. В один момент это была компания Clevertech из Нью-Йорка, хотя сам я жил в это время в Воронеже. В Clevertech я был техлидом — нанимал разработчиков, увольнял, строил разные процессы. Тогда это было скорее по наитию, потому что настоящего опыта в этом у меня еще не было.

В это же время я начал собеседоваться в Facebook, но там со мной случилась дурацкая штука — после того, как я прошел несколько этапов собеседований, рекрутер, который меня вёл, уволился. И меня просто потеряли. Но оказалось, что это и к лучшему — ребята из Yii начали работать в норвежском стартапе Stay — сервисе для путешественников, где работала очень сильная команда. Я пошел туда — и ни разу не пожалел, это был один из самых продуктивных мой периодов.

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

— Как в компаниях относятся к опыту в опенсорсе?

— Совершенно по-разному. Лично для меня это важно — мне кажется, что для начинающего разработчика это показатель, что его не нужно проверять на множество важных вещей. Например, что он умеет пользоваться системой контроля версий, гитом, работать с документацией, оформлять код в нужном виде, может быть даже писать тесты. То есть опыт в опенсорсе — не самое важное требование, но он позволит избежать части вопросов на собеседовании.

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

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

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

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

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

Про будущее PHP

— Куда вообще развивается PHP?

— Какого-то генплана у PHP нет, и никогда не было. Он развивается динамически — есть отдельные люди, которые на него очень влияют. Например, есть core team PHP Дима Стогов — он сделал JIT, а сейчас смотрит на движок языка и думает, в какую сторону его развивать, например, улучшать производительность. Есть Никита Попов — он делает так, чтобы PHP двигался в сторону строгости. Что очень важно — и Попов, и Стогов, и остальные контрибьюторы языка, которые просто не пересекаются с русскоязычным коммьюнити, начали активно общаться с пользователями. То есть с той частью сообщества, которая много использует PHP, и у этой части есть запросы на разные фичи. Там часто говорят про асинхронность, про долгоживущие приложения на PHP. Что точно будет в будущем — дальнейшее причесывание синтаксиса, ускорение языка, избавление от каких-то вещей, которые тянутся с первых версий языка и по-настоящему ужасны. От этого постепенно избавляются — и это очень хорошо.

— Какое комьюнити вокруг PHP?

Сейчас — прекрасное. Да, раньше был застой, практически не было конференций про PHP, было не ясно, куда движется язык. После того, как вышел PHP 7, комьюнити стало чувствовать себя лучше, появился даже сайт русскоязычного сообщества (https://phpcommunity.ru/), где есть большой список городов с региональными коммьюнити — они проводят митапы, классные тусовочки. Сейчас, конечно, в онлайне, а раньше — в оффлайне. Вообще, по ощущениям, комьюнити вокруг PHP сейчас чуть ли не самое активное.

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

Что делать джунам

— А какой язык программирования лучше брать первым?

— Смотря для какой области. Если человек из научной среды и хочет строить модели или работать с машинным обучением — то Python. И даже не потому, что язык подходит — просто все из этой среды работают на нем. Если хочется заниматься вебом — то у PHP мало конкурентов. Если обрабатывать данные — то Java, Go. Если мобильной разработкой — Kotlin, Java, Swift.

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

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

Все остальное на начальном этапе карьеры не так важно. Да, деньги — нужны, но не так, как классная команда, которая готова вас прокачивать.

— Если вам нужно брать на работу джуна, на что вы будете смотреть?

— На желание обучаться, на возможности обучаться, и на общую логичность кандидата — особенно на то, четко ли он формулирует свои мысли. Буду смотреть еще на базу — как он знает алгоритмы, язык программирования — но это уже во вторую очередь только. Конечно, если у кандидата закрыта классическая часть, связанная с computer science — это тоже будет плюсом.

— Какие нужны софт-скиллы?

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

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

Раньше таких программистов было намного больше, чем сейчас. К счастью, теперь их почти всегда отскринивают HR-менеджеры, это их работа.

— Какие книги вы бы посоветовали начинающим разработчикам и есть ли смысл вообще их читать в самом начале?

Если именно про PHP — PHP The Right Way, это бесплатная книгу, доступна на сайте. У нее есть перевод на русский, но я бы советовал читать на английском. И вообще, английский — это супер важно, и если его нет, то нужно подтягивать — это даст мощное ускорение, как в чтении документации, так и в карьере. PHP The Right Way объясняет, как программировать на современном PHP, чтобы не тащить все наследие, которого в языке действительно много — оно болтается в нем, чтобы могли работать старые сайты. Но все-таки сейчас работать лучше именно с новыми классными фичами — как раз эта книга и описывает их.

Второе — мануал PHP. В нем обычно все ищут всякие аргументы какой-нибудь функции и все такое. Но на самом деле там есть неплохое введение в ООП, хорошие материалы про веб-безопасность. И если не пользоваться поиском по каким-то конкретным функциям, а просто открыть оглавление — можно найти очень интересные главы, которые отлично написаны. Еще можно книги Матиаса Нобака, особенно «PHP для веба». Этого хватит, чтобы нормально и быстро стартануть.