Я пишу на PHP уже 12 лет, и застал ещё даже перевод проектов с PHP 4 на PHP 5. Уже тогда, после института, я понимал насколько низок уровень большинства людей, пишущих на PHP. Тяжелое наследие PHP 4, невысокая алгоритмическая и структурная сложность проектов(даже при объёмной кодовой базе), выбор №1 для малого бизнеса, всё это делало своё дело. Сообщество было непрофессиональным, и мне это не нравилось. Но то что творится сейчас еще хуже.

Небольшое введение для тех, кто не следил за развитием PHP последние 10 лет. Сегодня язык по уровню возможностей и современному стилю написания кода напоминает Java. У нас есть нормальные интерфейсы, классы, трейты, пространства имен, тайп-хинтинг, фреймворки enterprise уровня, хороший менеджер пакетов с отслеживанием зависимостей. Интерпретатор допиливали и на нем постепенно стало возможно писать долгоживущие демоны и асинхронные сервера, работающие с хорошей производительностью. Стандартный набор промышленного языка программирования в 2020 году. Что-то лучше, что-то хуже, но ведь у всех есть изъяны.

Вместе с языком поменялся и характер тех кто пишет на нём. Люди пишущие в стиле PHP 4 были есть и будут, хотя в прошлом месяце вышел PHP 8. Но появились и те, кого наименее оскорбительно можно было бы назвать астронавтами архитектуры. Вы наверное не раз слышали про паттерны, SOLID, KISS, DRY, YAGNI, отличие интерфейса от абстрактного класса и т.д. Еще лет 5 назад это было нормой скорее для культуры C#/Java, теперь же это типовые темы в PHP-сообществе.

Это хорошо и замечательно, что и в наш мирок пришли вещи из мира большого софтостроения. Плохо то, что в 99% случаев оно здесь не надо. Еще хуже то, что многие авторы, рассуждающие на тему приведенных выше аббревиатур, не до конца понимают с чем они имеют дело. И, наверное, самое страшное заключается в том, что теперь в мир PHP приходят не отрицающие всякую академичность практики, а глубокие теоретики, академики от сохи. Хотя сложность проектов доступных на рынке труда кардинально не поменялась, чтобы этой академичности было где разгуляться.

В смысле сейчас типовой крупный проект на PHP — это symfony/laravel + mysql/postgresql/mongo + redis + rabbitmq + elk. Он может крутиться на сотнях серверов, быть дробленным на микросервисы, но в сухом остатке там нет ни структурной, ни алгоритмической сложности. Тем не менее, если такой типовой проект начнет описывать тот PHP программист, о котором речь в статье, то мы заснем от длинного списка паттернов, и рассуждений о том как это можно реорганизовать еще сильнее следуя SOLID. При этом между тем, как хорошо применены лучшие принципы, и тем, насколько легко поддерживать проект, корреляции обычно нет.

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

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

Третий будет апеллировать к тому что следование SOLID повысит тестируемость. Но гораздо больше повышает тестируемость наличие времени, денег и желания у заказчика видеть тесты на проекте. Если они будут, то путем титанического mock-а и легкого рефакторинга вы напишете тесты к чему угодно. Если вы будете поддерживать или писать типовой проект, то даже сделав всё по заветам большой четверки, без ресурсов у вас не будет времени на написание и поддержание тестов в актуальном состоянии. Не надо смотреть на открытые проекты — они не ограничены по времени. Не надо смотреть на большие компании — они не ограничены по ресурсам.

Четвёртый будет радоваться, что восьмой Drupal на симфонии позволит писать сайты по-другому и гораздо лучше. Господа, окститесь! Во-первых на проекте на базе CMS просто негде развернуться ни по задачам, ни по возможностям фреймворка, ни в рамках времени, отведенного вам. Поддерживать это будут самые дешевые программисты, которые ваших изяществ просто не поймут.

Раньше сообщество PHP было полно неопытных людей, просто левых людей, и просто плохих программистов. Неопытных людей в сообществе меньше не стало, но теперь у них есть куча методичек, в которых они сами толком не разобрались. Ухудшает ситуацию и то, что программисты растут в том информационном вакууме, который они сами себе создают своими методичками. Вооружившись догмами, чтобы не ошибиться, они не пробуют альтернативных вариантов, не допускают обратной связи. И в итоге это ведет к отрицательной селекции даже на уровне компаний. PHP-формошлёп мнит себя Java-архитектором и нанимает специфических людей себе под стать.

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

Для меня PHP всегда был идеальной серединой между неповоротливой корпоративной разработкой с тоннами бойлерплейта и условностей, как в случае Java, и минимализмом Javascript, ведущему к мнимой свободе стиля. Это отличный рабочий инструмент, идеальная среда в которой есть всё для web-разработки. Прикладное решение, которое впитало в себя ровно столько от академического программирования, сколько нужно, чтобы стать еще более совершенным. Зачем доводить эту академичность в стиле разработки до абсолюта мне неясно.

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