[PHP, Программирование, Анализ и проектирование систем] PHP коммьюнити в СНГ. Было плохо — стало хуже
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Я пишу на 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 или смерть», так и «не нужно нам енто ООП». Все это до боли напоминает мне советские НИИ, где было то же самое засилье академичности и одеревенение специалистов. Программирование — это в первую очередь процесс формализации требований, вы же пытаетесь формализовать сам процесс формализации, без всякой оглядки на какие-либо ограничения. А поскольку вы не разрабатываете ИИ, бросайте лучше это дело.
===========
Источник:
habr.com
===========
Похожие новости:
- [Программирование, IT-инфраструктура, Виртуализация, Промышленное программирование, Управление разработкой] Цифровая индустрия: непрерывная оптимизация процессов
- [Анализ и проектирование систем, Исследования и прогнозы в IT, Медийная реклама, Управление продуктом] Вкалывают роботы, счастлив человек. Как мы настроили автоматическую закупку рекламы на ТВ
- [Разработка веб-сайтов, JavaScript, Программирование, ReactJS] Заметка о том, как React обновляет состояние (перевод)
- [Программирование, Управление разработкой, Развитие стартапа, Карьера в IT-индустрии, Научно-популярное] Путь CTO в небольшом стартапе (Zapier) (перевод)
- [PHP, TDD, Laravel] Как я пытался улучшить Laravel, а сделал только хуже
- [PHP, Управление разработкой, Учебный процесс в IT, Управление e-commerce, Управление персоналом] «Как этот год поменял жизнь IT сферы» Часть 2
- [Информационная безопасность, Программирование, Софт] Антирекорд 2020: в ПО выявили уязвимостей больше, чем в любой другой год
- [Программирование, Prolog, Искусственный интеллект, Natural Language Processing] Роль логического программирования, и стоит ли планировать его изучение на 2021-й
- [Программирование, Разработка под Android, Визуализация данных, Криптовалюты] CoinRoad: Как мы сделали приложение на базе кастомных пушей в Android
- [CMS, PHP, Magento] За что я люблю Magento 2
Теги для поиска: #_php, #_programmirovanie (Программирование), #_analiz_i_proektirovanie_sistem (Анализ и проектирование систем), #_a_jato (а я-то), #_v_sovetskie_vremena (в советские времена), #_oooo! (о-о-о-о!), #_php, #_programmirovanie (
Программирование
), #_analiz_i_proektirovanie_sistem (
Анализ и проектирование систем
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 19:08
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Я пишу на 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 или смерть», так и «не нужно нам енто ООП». Все это до боли напоминает мне советские НИИ, где было то же самое засилье академичности и одеревенение специалистов. Программирование — это в первую очередь процесс формализации требований, вы же пытаетесь формализовать сам процесс формализации, без всякой оглядки на какие-либо ограничения. А поскольку вы не разрабатываете ИИ, бросайте лучше это дело. =========== Источник: habr.com =========== Похожие новости:
Программирование ), #_analiz_i_proektirovanie_sistem ( Анализ и проектирование систем ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 19:08
Часовой пояс: UTC + 5