PHP коммьюнити в СНГ. Было плохо — стало хуже

    Я пишу на 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 или смерть», так и «не нужно нам енто ООП». Все это до боли напоминает мне советские НИИ, где было то же самое засилье академичности и одеревенение специалистов. Программирование — это в первую очередь процесс формализации требований, вы же пытаетесь формализовать сам процесс формализации, без всякой оглядки на какие-либо ограничения. А поскольку вы не разрабатываете ИИ, бросайте лучше это дело.

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 139

      +15
      Ситуация в СНГ-сообществе усугубляется его токсичностью.

      Не считаете ли вы свою статью токсичной?

      –32
      Я не то чтобы слежу за развитием PHP, поэтому и мой вопрос: язык научился понимать что перед ним переменная без знака $ в ее имени?
        +9
        $ всё ещё нужен.
          –16
          У языка такие классные возможности, но он все еще не понимает что работает с переменной без специального «костыля» перед ее именем :-(
            +12
            java до сих пор тип переменной не понимает без специального костыля перед ее именем в объявлении:)
            p.s.: kotlin понимает
              –7
              Одно дело один раз в объявлении, и совсем другое — каждый раз при использовании ;-)
                +34
                Вы хотите использовать переменную, но делаете это без уважения?
                  –1
                  Но это же не INTERCAL, в самом деле! Или если дать переменной больше баксов — она будет работать лучше? :-)
                    +11
                    От количества баксов переменная будет работать не «лучше», она будет работать по другому: $$ это переменная, которая по-сути содержит имя переменной. Да, мне приходилось этим пользоваться лет 10-12 назад.
                +3

                Тип переменой в Java можно не указывать начиная ещё с 10 версии.


                С другой стороны, это иногда не костыль, а нужная информация. К тому же, тип переменой может отличаться от названия класса экземпляр которого мы этой переменой присваиваем.

                  0
                  Тип переменой в Java можно не указывать начиная ещё с 10 версии.
                  Насколько мы помним — только в локальных переменных, при чем при условии что они сразу инициализируются.
                  Переменные классов, типы возвращаемых значений, объявление переменных с поздней инициализацией, параметры функций и т.д. и т.п. — вездеж надо указывать практически.
                    +1
                    Переменные классов, типы возвращаемых значений, объявление переменных с поздней инициализацией, параметры функций — к счастью, да, в этих случаях типы указывать надо и понимание типа сильно облегчает чтение кода.
                      0
                      типы указывать надо и понимание типа сильно облегчает чтение кода
                      Для понимания типа достаточно подсказок IDE, не обязательно руками набирать, показывается вычислимый тип и всё.
                      Особенно когда тип не просто Int, а что-нибудь посложнее.
                      И главное прописывать приходится в нескольких местах (определение функции, определение переменной куда идет возврат функции, определение переменной в функции для хранения возвращаемого значения до возврата… и т.д.)… а если надо сменить — снова бегай по всем местам и меняй.
                        0
                        Для понимания типа достаточно подсказок IDE, не обязательно руками набирать, показывается вычислимый тип и всё.

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


                        Впрочем, в любом случае непонятно, зачем сравнивать с Java, которая далеко не на переднем крае.

                  0
                  java до сих пор тип переменной не понимает без специального костыля перед ее именем в объявлении:)

                  var в джаве уже года 3 как есть.

                    0
                    в java 11 появился var, то что в большинстве своем используется java 8 другая тема, но все же, да, java умеет динамически присваивать тип, да и модификаторы "", l,f уж явно кажут что за тип используется в переменной
                +10
                и мой вопрос: язык научился понимать что перед ним переменная без знака $ в ее имени?

                Это не недоработка языка, а элемент его индивидуальности: Р
                  –12
                  Примерно как возможность выстрелить в ногу дюжиной способов в некоторых более древних языках, ага ;-)
                  +4

                  А какой в этом смысл?

                    +12

                    Научить понимать не очень сложно. Гораздо сложнее разобраться с легаси.
                    К тому же, к этому привыкаешь и это становится удобным. Видишь доллар — сразу мозг на подкорке детектит переменную. На Golang из-за этого я иногда ломался =).
                    И последнее — неужели это настолько важно? Ребята вкручивают jit, оптимизируют выполнение, добавляют вагон различного жирка — на фоне этого символ перед именем переменной вообще не является проблемой.

                      +2
                      Просто хейтеры $ в php никогда не видели Perl с его $,%,@. А с него стоило бы начать идучать скриптовые зыки.
                        +3

                        Я когда выбирал между PHP и Perl лет 20 назад, то открыл два аналогичных скрипта, в одном увидел $, в другом $,%,@ и выбрал первый )

                          0
                          Когда мне пришлось заняться web проектом, то php был еще в зачаточном состоянии и perl казался логичным выбором (правда и сайт состоял из условной борды и новостей, все на Perl). Но с выходом 3.0 я таки о нем узнал и мы решили сделать свою CMS на php. И да в течении жизни проекта до 2012 года мы перешли с 3 до 5 версии совершенно спокойно.
                            0

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

                    +27
                    Извините, конечно, но из-за таких вот статей сообщество и считается токсичным. Проблема не в том, что вы напрямую оскорбляете то самое сообщество, и даже не в том, что вы, используя максимально простые приемы демагогии, пытаетесь настроить читателя на нужный вам лад.

                    Проблема в очевидных противоречиях в двух ваших основных тезисах:
                    Одно из главных отличий PHP от Java — это гибкость, возможность писать в разных стилях, срезать углы, большая вариативность сопутствующих технологий.
                    И тут же:
                    Плохо то, что в 99% случаев оно здесь не надо. Еще хуже то, что многие авторы, рассуждающие на тему приведенных выше аббревиатур, не до конца понимают с чем они имеют дело.
                    Эти люди используют ваш же постулат о том, что PHP «это гибкость, возможность писать в разных стилях». Для них именно этот стиль удобен и легко реализуется в PHP. За это вы же их и клеймите.

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

                    Оценочное суждение
                    Целая статья ни о чем, наполненная демагогией и домыслами. Это ли уровень хабра?
                      –12
                      Современные PHP-конференции(и в т.ч. подкасты) — это мероприятия, где ораторы собираются в кружок и надрачивают друг другу ЧСВ. Что прямо говорит о пошлости данных мероприятий, и косвенно — об ориентации ораторов на этих мероприятиях. Боюсь, что если бы я честно написал о наших PHP конференциях, то хабр не пропустил бы это порнографию.

                      В ваших цитатах моего текста я противоречия не нашел. И независимо от того, кто из нас дурак, сомневаюсь что мы друг другу что-то докажем.
                        +9
                        Современные PHP-конференции(и в т.ч. подкасты) — это мероприятия, где ораторы собираются в кружок и надрачивают друг другу ЧСВ.
                        Это же просто голословное оскорбление. Вы всерьез считаете, что голословные оскорбления что-то смогут изменить в сообществе?

                        В ваших цитатах моего текста я противоречия не нашел. И независимо от того, кто из нас дурак, сомневаюсь что мы друг другу что-то докажем.
                        Давайте поясню. У нас есть тезис:
                        Одно из главных отличий PHP от Java — это гибкость, возможность писать в разных стилях
                        Далее второй тезис:
                        Плохо то, что в 99% случаев оно здесь не надо.
                        DRY, KISS, SOLID, etc — это тоже стиль. А вы, напомню, утверждаете, что главное в PHP — это возможность писать в разных стилях. Как люди, которые следуют вашему же тезису о разных стилях, могут быть не правы в вашей же статье? Тут очевидное логическое противоречие.
                          –18
                          К сожалению я недостаточно умён, чтобы его заметить. О моём низком уровне интеллекта также свидетельствует то, что я опускаюсь до прямых оскорблений.
                            +11
                            Снова демагогия. Хотя тут несколько более изящная. Вы пытаетесь с помощью подмены тезиса создать ощущение, что я апеллировал к вашим умственным способностям. Этого не было. При этом не приводите никаких возражений по существу.

                            Да, боюсь, что диалога у нас не выйдет.

                            Советую вам все же поискать светлые стороны в современном PHP и сообществе, а то рискуете выгореть, с таким отношением.
                          +3

                          Токсичность ради токсичности. Вам самому-то как? Комфортно?

                            –1
                            Нет, ну а вы видели-то докладчиков этих?
                        +2
                        На мой взгляд вообще странно с классами в php: на каждый запрос загрузить структуру классов, чтобы потом это все сразу убить… :))
                          +1
                          Это решается даже традиционными для всех языков способами — демонами, разгребающими сообщения и FastCGI.
                            +7

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

                              +4

                              Ну сейчас вроде нужно специально постараться на продакшене, чтобы каждый раз с нуля загружать структуру классов. Кэши опкодов, прелоадинг, JIT вон завезли, даже явную компиляцию в бинарники (файлы с опкодами), для запуска которых не нужны исходники, активно продвигают.


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

                              +1
                              А где не так-то?
                              Я сейчас не буду даже про RabbitMQ \ Elk, у меня с PHP ситуация куда проще. Крохотный корпоративный сайт, часто используемый движок. Задача — слегка допилить корзину, чтобы там по почте движение заказа уходило.

                              Так вот уже четвертый (!) подрядчик подряд пытается решить эту задачу просто впиливанием send.php на submit(), а чтобы заполнить шаблон — они даже ORM не подключают, а просто mysql_connect к базе и селектят оттуда всякое. И это за 35 баксов в час.

                              Видя такую ситуацию — заказчики начинают избегать языка. Сокращается количество исполнителей, пропасть между «обычными» исполнителями и «квалифицированными» — растёт. Ну вот в итоге и имеем строго то, о чем Вы написали.

                              А сам язык ни в чем не виноват, да. Трейты там, тайпхинтинг. Мне иногда кажется, что Delphi каким-то похожим образом умирал.
                                +3
                                Вы верно заметили про разрыв между квалификациями и часовую ставку. Вполне вероятно что все 4 раза подряд вы имели дело с субподрядчиком с неприятным гортанным английским, получающим в 3-10 раз меньше, чем ваш прямой подрядчик. На одеске и прочих подобных местах это классика.
                                  +1

                                  Фриланс он такой — бессмысленный и беспощадный.
                                  Но это справедливо не только для пхп, но для многих других языков и направлений. Например, js (фронт и бек), верстка, диз.
                                  И тем бессмысленнее и беспощаднее чем больше ориентированность на мелкий и средний бизнес (различные мелкие онлайн магазы или сайты визитки на популярных cms и т.п.)

                                    +3
                                    Ну подключение ORM — это весьма спорный вопрос, я, например, привык сам писать запросы к БД, а ORM порой такую дичь собирает, что ну его нафиг. А вот насчет mysql_connect — ну это кому как удобно, я лично в пхпшных проектах PDO использую.
                                      +1
                                      PDO тоже не везде установлено, а это значит договариваться (не лезть же в настройки клиентского сервера без разрешения), объяснять, зачем оно надо, возможно самому ставит и настраивать… И вот, микро-задача на час превращается в тягомотину на день.
                                      Если исполнитель прямо фрилансер-прифрилансер, ему проще за минимально возможное время сделать то, что гарантированно будет работать.
                                      Ну и, скорее всего, «даже ORM подключать» никто и не просил.
                                        0
                                        Ни разу не встречал даже самого примитивного хостинга, где не было бы PDO, если оно не работает, то где-то просто включается в настройках панели управления.
                                          +1
                                          Любой VPS-хостинг, где тебе дают «голую железку» и наличие/отсутствие панелии каких-то модулей в PHP, как и самого PHP — твоя личная забота.
                                            0

                                            Бывает

                                            +1
                                            Если не ошибаюсь, с какой-то версии PDO идет с пхп по умолчанию, его даже включать не надо
                                          +1
                                          И это за 35 баксов в час.
                                          А точно в час?
                                          Может скорее просто за 35 баксов, пусть даже в формулировке «рейт 35 в час, у вас есть только час»
                                          Потому что так-то нет обычно проблем у подрядчика на часовой основе сделать всё по канонам заказчика.
                                          Вот только это будет не «тыгыдык и в продакшен за час», а «3 часа изучения что бы ничего не поломать, 2 часа написания тестов, 2 часа написание кода, 1 час тестирование и 2 часа на документацию» выливающиеся уже в 10 часов ака 350 баксов.
                                          p.s.: И да, 35 баксов в час оплаты это достаточно скромно, т.к. после всех накладных расходов (15-25% бирже, 10% комиссий на вывод, 15% налоги) — от них останется баксов 20 в лучшем случае уходящих работнику, а это оплата даже не джуниора, а «просто с улицы зашел».
                                            +2

                                            Порядка 3200 в месяц, почти 40 000 в год — это «просто с улицы зашел»?! Для меня это где-то на грани между сильным миддлом и новоиспеченным сеньором на фуллтайме в наших широтах. А по ощущениям российские удалённые работодатели столько вообще на PHP не предлагают (в марте-апреле, когда я менял работу). Украинские могут.

                                              +1
                                              На хабре уже была статья с подробным объяснением, что час работы «на дядю» и час фриланса — это две огромные разницы. Если кратко, на фрилансе время тикает пока вы кодите по задаче. Поиск заказов, согласование условий, ведение бухгалтерии, больничные и отпуска, простои в «межсезонье» — всё это тоже надо чем-то компенсировать. И чем короче задача, тем выше доля этих расходов.
                                                0
                                                А есть ссылочка на статью или название? Буду очень благодарен
                                                +2

                                                Эк вы лихо наумножали.
                                                Никогда не были целиком на фрилансе хотя бы полгодика? )

                                                  +2

                                                  Были, за 5 баксов вчас, кажется.

                                                  0
                                                  Порядка 3200 в месяц
                                                  Перефразируем старый анекдот:)
                                                  "Роды у женщин идут в среднем 12 часов, значит за 30 дней женщина родит 60 детей."
                                                  А выносить ребенка 9 месяцев, не?:)
                                                  Или вот еще классика
                                                  очень в тему анекдот про фотографа
                                                  Новый русский открыл фотосалон и дал объявление: «Приглашаю
                                                  фотомодель для эротической съемки. Оплата наличкой на месте. За час работы
                                                  — 20 тысяч баксов».
                                                  Набежала куча длинноногих, отобрали одну, весь вечер снимали во всех
                                                  позах. Приходит новый русский:
                                                  — Ну что, фотограф, сколько наснимал?
                                                  — Сто двадцать кадров.
                                                  — А выдержку ставил какую?
                                                  — 1/500 секунды.
                                                  — Ну ты, девка, в натуре и на полсекунды не наработала:

                                                  При 20 баксах в час и полной занятости в месяц будет в районе 800 у джуна, т.к. 50% времени он будет искать заказы и 25% их обсуждать и сдавать.

                                                  Мы нередко берем заказы у москвоских студий (работаем неграми), так вот стандартно они себе берут 50-80% от заказов и нам это всё равно получается выгоднее чем прямой поиск заказчиков, т.к. мы получаем на руки готовое ТЗ и сразу начинаем работать, а не тратим время на всю ерунду.

                                                  А по ощущениям российские удалённые работодатели столько вообще на PHP не предлагают (в марте-апреле, когда я менял работу).
                                                  Предлагают.
                                                  Просто в российском сегменте нюанс в том, что соотношение дешевый проект/дорогой проект 95/5, а на западе 50/50. Поэтому когда ищешь в россии заказы — постоянно предлагают копейки и складывается ощущение низких цен, но так собственно и работа по сложности как правило больше не стоит.
                                                  А вот на дорогие заказы платят и по 50 евро в час, но там надо не просто знаниями solid потрясать и юнит тесты впаривать, а реально решать задачи… не брезгуя в том числе и методом (говна и палок) описанным в статье, если это вызвано производственной необходимостью. А такой скилл куда большая редкость, чем вот эти все «чистые архитектуры».
                                                    0

                                                    Я понимаю разницу между фрилансом и фуллтаймом. Просто последний абзац мой мозг распарсил как:


                                                    • на фриланс-бирже — 35 в час
                                                    • на руки чистыми — 20 в час
                                                    • 20 — это даже не джун

                                                    На последней стадии мой парсер сломался, типа 35 — это достаточно скромно, а 20 — это даже нее джун, хотя это одна и та же сумма для меня по тексту, просто грязными и чистыми. Какое-то новое качество появилось, наверное работа фуллтайм…

                                              +5
                                              Третий будет апеллировать к тому что следование SOLID повысит тестируемость. Но гораздо больше повышает тестируемость наличие времени, денег и желания у заказчика видеть тесты на проекте.

                                              Золотые слова.
                                                0

                                                Слишком много ответственности для заказчика в ответе на вопрос «а надо ли тесты писать?». С чего бы ему вообще этим интересоваться, а мне — это (у заказчика!) спрашивать?

                                                  0
                                                  Если коротко — снижение рисков.

                                                  Если длинно — да, не обязательно заказчик должен приходить с такой инициативой, но менеджер может ему это пояснить и заказчик согласиться. И объяснить не конкретно про тесты, а про смысл правильного подхода к разработке — с регулярным подчищением тех.долга, с автоматизацией, с девопс методологией.
                                                  Результатом будет гораздо более предсказуемые сроки внедрения новых фич, практически отсутствие зависимости от конкретного специалиста, который «проработал на проекте 3 года и единственный понимает как тут все работает», простой вход в разработку новых людей
                                                    0

                                                    А если не объяснять? Заказчику нужны фичи — мы их поставляем, а техническая кухня — наша компетенция, для этого он нас и нанял, нет?

                                                      0
                                                      Так фичи и фичи + продумывание архитектуры + тесты — это разное время и объем работы. Время работы и сумма обычно в контракте оговаривается. Качесто кода — нет. Если вы начнете его обговаривать и повышать сумму, то контракт скорее всего заключат не с вами. И на крупных проектах все даже хуже порой — там положим деньги дать готовы, но сроки для больших проектов берутся с потолка, а уровень программистов(если это гугл), как правило, ниже чем в небольших командах, можно сказать дно, если это глобальный аутсорс. А это делает сроки еще менее предсказуемыми.

                                                      На мой взглядл, среди всех препон, мешающих писать тесты, плохое качество кода находится на последнем месте.
                                                        +1
                                                        Задача менеджера и заказчика — договориться об удобстве для всех. Найти консенсус, при котором заказчик будет доволен скоростью появления новых фич и стабильностью работы, при этом он будет понимать, что в book of work будет определенное количество технических задач, которые ставит не он, а архитектор/тех лид — для собственно поддержки этой стабильности и скорости.
                                                        То есть добавление технических задач прозрачно для всех — это удобно.
                                                      0
                                                      Слишком много ответственности для заказчика в ответе на вопрос «а надо ли тесты писать?». С чего бы ему вообще этим интересоваться, а мне — это (у заказчика!) спрашивать?
                                                      Даже написание ТЗ для проекта можно отдать на аутсорс. Компетентным людям/организации. И, по опыту, часто так делают. От заказчика — только деньги. Остальное все сделают за вас. Главная ответственность заказчика (кроме, конечно, оплаты) — правильно выбрать исполнителей.
                                                    +4
                                                    Спасибо за статью. Такая ситуация не только в PHP.

                                                    В Ruby сообществе последнее время еще модно пилить все на микросервисы, переписывать все на монады, сервис-объекты, 12factorapp и т.д. Архитектура ради архитектуры, программирование ради программирования.

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


                                                      +6
                                                      Нет. Программирование — это процесс передачи формальных требований другому программисту (и себе в будущем) в процессе борьбы со сложностью. Код только ради конечного результата остался где-то в 60-70-х годах. Поэтому и возмущение автора кажется скорее достоянием истории, либо крохотных проектов. Мне вообще казалось, что уже все это осознали и сейчас на каком-то следующем этапе.
                                                        +5
                                                        Код только ради конечного результата остался где-то в 60-70-х годах


                                                        Теперь это называется MVP.
                                                        0
                                                        То, что происходит в руби и рельсах сейчас, придет в другие языки и фреймворки лет через 5 :)
                                                        Просто рубисты- это бета-тестеры от мира программирования.

                                                        Если что-то не зайдет — откинут, а если что-то очень зайдет — примут на вооружение.
                                                        +3
                                                        Очень похожую проблему наблюдаю в NodeJS сообществе. Огромный плюс ноды, по моему мнение, в возможности писать как сложный код с применением кучи патернов так и супер простой минимальный код без единого класс на 3-4 функции. Тем не менее разработчики упорно тащат непонятно кому нужные паттерны и псевдо best practices из-за чего одна функция разрастается на добрый десяток классов.
                                                          +1
                                                          А по-моему, нет, в js все ещё остается полная свобода. В nodejs с одной стороны ООП с DI в лице nest.js, считается ентерпрайзным подходом, с другой стороны функциональщина, а большинство просто пишет код и думает о задаче. Вот взять node best practices — тут первым пунктом компонентный подход, который большинство упорно игнорирует, чем меня раздражает, и тут ни слова ни о парадигмах, паттернах, все только по делу. Даже про точку с запятой пишут «no matter if you use semicolons or not».

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

                                                          И как в ноде: самый популярный фреймворк express, роутинг + пара утилит = фреймворк по версии javascript. И абсолютно все, каждую мелочь, решает разработчик: как ему параметры валидировать, как с базой работать, как организовать, и главное — мудрить или не мудрить тоже решает сам.
                                                          +5

                                                          Да, PHP сообщество токсичное. И это факт. И не важно из-за чего эта токсичность — из-за профдеформации или профнепригодности, но она существует.


                                                          И это справедливо не только для рунет сообщества, но и для англоязычной его части.
                                                          Кстати в англоязычном сообществе токсичность в разы выше — фанатики и сектанты закидают любого не согласного с религией данной секты. Даже если это объективные граничные условия или исключения из данной догмы. Сектанты они такие — догма должна быть только одна и строго по заповедям, без разночтений и иносказаний, а все остальное ересь!
                                                          Рунет сообщество PHP не сильно большое и в нем действительно интересно бывает устроить срач. Но да, надо понимать специфику и неподготовленному морально может быть тяжеловато.


                                                          И да, статья тоже токсичная и это тоже факт. Хотя токсичность статьи не исключает что большинство проблем из нее определенно присутствуют.


                                                          P.S. И да, я пишу на PHP.

                                                            +1

                                                            А в чём проблема-то? Или проблемы нет?


                                                            Как вы сами сказали, целые компании формируется по стилю исполнения PHP. На любой вкус найдётся. Мне вот ближе "SOLID или смерть, статанлиз наше всё", кому-то "PHP3+WordPress решат любую задачу'"

                                                              0
                                                              Проблема в том, что слишком категорично. На любой вкус — это аутсорс в непонятный проект. СНГ-шные команды это 2 крайности, либо говнокод, либо «SOLID или смерть».
                                                                +2
                                                                На любой вкус — это аутсорс в непонятный проект.

                                                                Вам шашечки или ехать? )

                                                                  +2

                                                                  Либо говнокод, либо говнокод адептов SOLID.

                                                                    0

                                                                    Поддерживаю. Часто именно так. Только в зависимости от команды SOLID можно заменить на любую другую аббревиатуру :)

                                                                      0
                                                                      Непонятно, что вы так прицепились к SOLID, для его примерного соблюдения (в меру [не]годности этого термина) не нужны дополнительные усилия. Может только дополнительные усилия по самообучению.
                                                                        0

                                                                        Я думаю SOLID был взят в качестве примера. Из моей практики там может быть любая из аббревиатур.

                                                                    +1

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


                                                                    А третий это и есть психотерапевт, который решил "войти в айти"?

                                                                      +6
                                                                      Ситуация в СНГ-сообществе усугубляется его токсичностью.

                                                                      И это прекрасно! Токсичность проф-сообществ пост-СССР это прям как первозданный бульон, это как тот самый свободный интернет где можно высказать свою мысль не смотря на все эти штуки с опасностью кого-то обидеть.
                                                                      Я когда переписываюсь или общаюсь с иностранными коллегами — мне становится жутко не комфортно. Мне некомфортно оттого что я не могу сказать идиоту что он идиот и что ему хорошо-бы сделать трепанацию и в получившиеся отверстие вставить скрученный листочек со стандартами принятыми в компании или прочесть 100-страничный мануал где подробнейшим образом описаны все ньюансы сложной системы.
                                                                      И нет, я не быдло и я много раз сталкивался с неприятной токсичносью в свою сторону (не только в рунете), особенно когда задавал вопросы на профильных форумах, но я считаю что это необходимая часть жизни разработчика который хочет расти. Это определенный порог вхождения помогающий отстаивать свою точку зрения.

                                                                        +8
                                                                        Я вас умоляю! Наша токсичность абсолютно непродуктивна, потому что у нас в культуре неявно прописано, что кто неправ, тот лох; если ошибся, то могут спросить. Не так грубо как в подворотне и не прям в таких формулировках как я описал, но все это исподоволь проникает в наше сознание через воспитание, массмедиа, быт. И если в западных командах, когда я поднимал спорные вопросы, мне приходилось преодолевать только административное сопротивление, то в снг-командах каждый тянет одеяло на себя и противоречит чисто из синдрома вахтёра.
                                                                          +5
                                                                          СНГ:
                                                                          — Ребята, а давайте забьем гвоздь в сервак! Я слышал, что это стильно-модно-молодежно!
                                                                          — Ты шо, йокнулся?
                                                                          Новичку устраивают тёмную в профилактических целях.

                                                                          Запад:
                                                                          — Ребята, а давайте забьем гвоздь в сервак!
                                                                          — Этого не стоит делать.

                                                                          — Тщ. менеджер, команда не позволяет мне забить гвоздь в сервак!
                                                                          — Почему?
                                                                          — Ну они все отсталые динозавры, а гвоздь в серваке — это стильно-модно-молодежно и ускорит сервак в 100500 раз! Вот статья из СпидИнфо за авторством Гоши Куценко, подтверждающая мои слова. Ну так я забью?
                                                                          — Забивай!
                                                                          Команда косится на новичка, но молчит, потому что назвать его идиотом — это токсик и грозит увольнением, а отрицательное влияние внедрения гвоздя в сервер можно будет наглядно показать менеджеру только через полгода и объяснить, что Куценко — не авторитет в подобных вопросах.
                                                                            +4
                                                                            Второй диалог выглядит несколько по-Задорновски, это реальная картина?

                                                                            Мне видится:
                                                                            — мне команда не даёт забить гвоздь
                                                                            — ты молодец и очень умный, забиванием гвоздей занимается отдел забивания гвоздей. если хочешь, мы обсудим твой перевод туда (или вообще отсюда) /эмоджи/
                                                                              +4

                                                                              Мне видится:
                                                                              — мне команда не даёт забить гвоздь
                                                                              — ты молодец и очень умный, прояви деятельную проактивность, проведи спайк, А/Б тесты, бенчмарки, убеди команду фактами, они тоже не идиоты и факты отрицать не будут.

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

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

                                                                                UPD: Ну и вот наглядный пример токсичности в моем понимании — некто поставил минус в карму и минус комментарию (воспользовался административными методами), но при этом даже не потрудился написать с чем именно в моем шарже он не согласен (никакого конструктива).
                                                                                  +2

                                                                                  Это могло бы быть реальным диалогом.


                                                                                  Из личного опыта — диалоги я приводить не буду, приведу конечный результат:


                                                                                  • Необходимость следовать одному кодстайлу в проекте не нужна, так как это делает разработчиков менее счастливыми и не позволяет выражать свою личность.
                                                                                  • Мы не будем пользоваться автоформаттерами, потому что Махеш запустил C++-форматтер на питонокоде с флагом --force, отчего питонокод сломался, поэтому форматтеры — это опасно.
                                                                                  • 0xd34df00d, твои коллеги на тебя жалуются, так как ты добавил во флаги компилятора -Wall и убрал оттуда -Wnone -fpermissive, из-за чего им стало труднее писать код, так как компилятор теперь сыпет ненужными предупреждениями. Да, я знаю, что ты поправил все имеющиеся предупреждения, у них они в новом коде. Нет, эти предупреждения действительно ненужные — ну и что, что программа на самом деле иногда падает, если в некоторых ветках функции, возвращающей std::string забыть return? У нас для этого есть отладчик, а не предупреждения компилятора.
                                                                                  • В нашем отделе необходимо code review, но также we need to move fast, поэтому навешивать кодревью на себя и самостоятельно ревьювить свой код — нормально. Но сразу мержить в мастер нельзя, надо отревьювить свой код.
                                                                                    0
                                                                                    Мы не будем пользоваться автоформаттерами, потому что Махеш запустил C++-форматтер на питонокоде с флагом --force, отчего питонокод сломался, поэтому форматтеры — это опасно.
                                                                                    Ну я тоже такое припоминаю, но есть серебрянная пуля без автоформатирования — не пускать на сервер неправильно отформатированный код.
                                                                                      0

                                                                                      А для этого (или против этого) см. предыдущий пункт в списке.

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

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

                                                                                  Черт знает как вы сюда это г. притянули...


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

                                                                                  Да что вы! У меня тут целый институт математики вспоминает как они прилюдно друг-друга смешивали на конференциях всесоюзных, по приколу. Или как они аспиранта заставляли перечитывать тонну литературы, вместо ответа на вопрос. Или как на защите аспиранта доводили до слез...


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


                                                                                  Нет, я конечно против того чтоб аспиранта доводить до слез прилюдно, но как-то это работает...

                                                                                    0
                                                                                    и фидошников 90-х

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

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


                                                                                  P.S.
                                                                                  Когда я вижу слово "ньюансы"...

                                                                                    –1
                                                                                    Ни разу не встречал токсичной реакции в ответ на корректные вопросы. «Смешивают» обычно после заявлений вида «я тут пишу тестовое задание на фреймворке таком-то, вчера впервые его поставил, как тут сделать форму редактирования пользователя?».
                                                                                    И то чаще всего человеку отвечают — иди учи основы языка, потом учи фреймворк, потом сможешь сделать всё сам.
                                                                                    Если это теперь считается токсичностью — дайте мне другой глобус.
                                                                                      0

                                                                                      А я встречал… В последнее время больше по вопросам процессов разработки и эксплуатации PHP приложений, типа каждый PHP-разработчик должен уметь разворачивать своё приложение в k8s и/или AWS, а кто не умеет — вон из профессии.

                                                                                        0
                                                                                        типа каждый PHP-разработчик должен уметь разворачивать своё приложение в k8s и/или AWS, а кто не умеет — вон из профессии

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


                                                                                        Потому куча "специалистов" которые умеют развернуть докер (даже там где не надо), но вообще не знают как это все работает. И если такому "профессионалу" сказать настроить то же самое на чистой системе (на собственный выбор) — не сможет. Я не говорю что пхп разработчик должен быть сисадмином, а к тому что если и использует технологии типа докера и k8s, то должен понимать как это работает внутри и когда применять. Это тоже самое что если разработчик использует сторонние библиотеки, то должен понимать как они работают. Например, стандартные жалобы на джунов и мидлов, которые типа умеют только в ORM, но не могут в SQL

                                                                                          0

                                                                                          Я больше про разделение обязанностей: обоснованно или нет, но решили перевести проект на docker, k8s и/или aws. И теперь разработчик должен писать докерфайлы, манифесты, чарты, конфиги терраформ и т. п. как раз на уровне сисадмина, да ещё отвечать за баланс.

                                                                                            0

                                                                                            Ну когда есть k8s, то тут явно должен отвечать не просто сисадмин, а модный сейчас девопс.


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

                                                                                              0

                                                                                              Если таких лендингов десятки, да с разными версиями PHP, то докер облегчает жизнь, на самом деле

                                                                                                0

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

                                                                                                  0
                                                                                                  Но тот же паппет, ансибл или банальный инсталл скрипт может быть лучше докера.

                                                                                                  Ансиблом я ставлю докер ))


                                                                                                  А если это разовый заказ на фрилансе

                                                                                                  Как раз на фрилансе мне его не хватало, когда сайтов десятки надо держать поднятыми локально да с разными версиями рантайма


                                                                                                  Но вот например бывает что в публичном докер репе, не только система, но и весь код, со всеми доступами и паролями. Это разве
                                                                                                  нормально?

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

                                                                                                    0

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

                                                                                                      0

                                                                                                      Да и со мной бывало, что забыл что-то *ignore файлы добавить. Когда нет процессов проверки реп, образов и т. п. на предмет наличия чувствительной информации, то мы зависим от человеческого фактора...

                                                                                  0

                                                                                  Токсичность рунет сообщества сильно отличатся от токсичности сообщества англоязычного.
                                                                                  У нас все-таки в разы адекватнее в профессиональном плане и не так распространены секты.

                                                                                    +2
                                                                                    Не совсем ясны тезисы из статьи.
                                                                                    Упоминается сообщество СНГ и конференции СНГ, но при этом нет никакого сравнения с сообществами других стран и конференциями других стран. Ну хоть какие-нибудь примеры.
                                                                                    Утверждается что на PHP нет алгоритмической сложности, а на Java не так что-ли? Java разработчики в сбертехе не знают даже нотации О большое. За всех конечно не отвечаю, только за тех с кем общался.
                                                                                    Что такое делают на Java, что не пилят на PHP? CRM? Вы не видели ошибки и стактрейсы томкэта у всех на виду, как будто это последний битрикс на котором в продакшене забыли отключить дебаг-режим? А я вот много раз видел.
                                                                                      +1

                                                                                      Пост, конечно, очень токсичный вышел, да и зачем хотеть чего-то сильно сложного от инструмента, название которого расшифровывается Personal Home Page? Для сложных задач есть другие инструменты.


                                                                                      Но в одном вы правы: у СНГ-шного сообщества карма испорчена, отягощена такой поделкой, как Битрикс. Думаю, не ошибусь, если скажу, что у очень большой части малого бизнеса сайты на нём, родимом. А это значит, что всегда будут люди, готовые задешево возиться с этой лапшой, где вместо KISS, DRY и SOLID используются принципы "сдал и забыл" и "ну так — и в подакшен". Жить-то хочется, порог вхождения низкий..


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


                                                                                      Но зачем их пинать? Пишите на Go или на Kotlin, зачем переживать за фронтенд — у нормального программиста столько разных путей и возможностей развития, что на две жизни хватит.

                                                                                        +3

                                                                                        Ну а разве Laravel это что-то неописуемо прекрасное?

                                                                                          +1

                                                                                          Странный продукт. При желании можно писать по SOLID, даже псалм к илокенту люди прикручивают полноценно, если верить. Но в реальной жизни не встречал такого.

                                                                                            0
                                                                                            Laravel выглядит как удачная попытка махнуть рукой на усилия перетащить слабую часть сообщества на бест практисес. Для меня названия классов и их иерархия контр-интуитивна, но значительной части коллег нравится. И если отбросить вопросы именования, то в Laravel действительно хороший набор компонентов для типовых задач.
                                                                                              +3

                                                                                              только вот код ларавеля очень сомнительного качества и мануалы просто пропагандируют антипаттерны.

                                                                                                0

                                                                                                Причём умудряяются пропагандировать даже при наличии в нём же альтернатив типа DI...

                                                                                                  0

                                                                                                  Именно! Я как раз об этом.


                                                                                                  Сейчас разработка PHP в 90% случаев сводится к TDD — Tutorial Driven Development.
                                                                                                  Дока для Symfony тоже этим страдает

                                                                                              0

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

                                                                                                0

                                                                                                https://github.com/oroinc/crm — не чистый феншуй, но гораздо лучше большинства "закрытые исходники, NDA и т.п."

                                                                                                0

                                                                                                (deleted)

                                                                                            +1
                                                                                            Высокая нетерпимость к чужому мнению вкупе со схемой «я начальник — ты дурак» порождает целые компании, где люди отбираются строго по религиозному признаку.

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

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

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

                                                                                                Вы так говорите, как будто это что-то плохое.

                                                                                                  0
                                                                                                  Для формирования команд программистов, которые страшные индивидуалисты в массе своей — плохо. Для поиска жены или воспитания детей — отличная стратегия.
                                                                                                    0

                                                                                                    Моя практика показывает, что команды индивидуалистов, разделяющих общую точку зрения, заметно эффективнее команд тех же индивидуалистов, согласившихся с чьей-то точкой зрения. Буквально тех же: приходит CTO новый и вводит, например, такую мелочь как новые код-стайлы. Старые были приняты всей командой в процессе обсуждения, а тут директивно. Эффективность упала, хотя казалось бы...

                                                                                                      0
                                                                                                      Я вам немного про другое. Допустим вам не нравится Laravel, но попался очень вкусный проект на нём. В процессе собеседования вы демонстрируете достаточные знания фреймворка, но на вопрос о предпочтениях замечаете, что предпочитаете Symfony. И тут вашего собеседника передергивает, и он вам говорит, что мол нет, нам такие бойцы не нужны. Подразумевая, что ему нужны люди, которые живут Laravel и дышат им. При это вы понимаете, что смогли бы с легкостью писать по ларавеловской доке и копировать уже имеющийся код стайл проекта, потому что этот фреймворк уже даже не пятый по счету в вашей карьере.
                                                                                                        +1
                                                                                                        Подозреваю что у вас профдеформация :)
                                                                                                        Вы думаете что в мире есть места где все сделано и работает правильно. А под правильно вы видите какой-то конкретный вариант. Это не так. Мозг человека работает иначе. И обычно нет единственно правильного пути.

                                                                                                        Подбор персонала — весьма субъективная штука, вероятно этот ваш оппонент уже обжигался при подборе, ему попадался любитель Symfony который постоянно тянул одеяло в сторону Symfony которым в проекте и не пахло, и всех этим задолбал.
                                                                                                        Теперь они ищут чела без таких недостатков :)
                                                                                                          0
                                                                                                          Ну знаете, как только мы вступаем на скользкую дорожку вычисления вероятности в субъективных предпочтениях, можно додуматься, что каждую ночь человеку снятся гномы с лицом Fabien Potencier одетые в футболки с логотипом Symfony, и щекочут несчастного.

                                                                                                          Обычно всё гораздо прозаичнее
                                                                                                            0

                                                                                                            Я такой человек ;)

                                                                                                +4

                                                                                                После слов про то, что сложности в проектах на язык-нейм нету в сухом остатке, сей опус я покинул.

                                                                                                  –2
                                                                                                  Ну куда же вы, я же еще не успел добавить сакрального «да там же работы на полчаса»!
                                                                                                  –1
                                                                                                  Имхо, «токсичность» «новых» программистов не зависит от языка.
                                                                                                  Это скорее связано с несколькими факторами: клиповое мышление, большой объем накопленных в отрасли знании, повышение порога входа, синдромом самозванца и желание скрыть свою неуверенность (а в некоторых случаях и некомпетентность).
                                                                                                  Эту тенденцию можно было наблюдать на примере Японии в начале этого века.
                                                                                                  Привыкайте. Это новый мир. Дальше будет хуже. Надо научиться с этим жить.
                                                                                                    –1
                                                                                                    А в чем особенность Японии в этом плане?
                                                                                                      0

                                                                                                      Насчёт синдрома самозванца — разве не наоборот? Мне кажется, что он развивается как раз у тех, кто видит чужие вещания с табуретки о том, как правильно. А тому, кто вещает, нормально. Разве что, возможно, не хватает восхищений его величием.

                                                                                                      –5
                                                                                                      Я как раз из тех, кто пишет, если так можно выразиться «в стиле PHP4» в 2020. Не выношу Wordpress, Drupal и прочий подобный ужас, предпочитаю свои велосипеды. С удовольствием бы перенял какие-то более современные практики, но во-первых, где взять время на освоение нового, если работы и заказов много (и я довольно успешно решаю вопросы клиентов, малого бизнеса со своими наработанными годами велосипедами), во-вторых, сегодня такое многообразие технологий, целый зоопарк, что не знаешь, за что хвататься и самое главное, еще нет уверенности, что освоенная новая технология, пока её освоишь, не устареет за это время и ей на смену не придет новая. Да, в среде командной разработки и крупных девелоперских контор, без этого всего никак. Но что делать таким как я, работающим по заказам в одиночку? Которым даже спросить и посоветоваться не у кого. Желание развиваться дальше есть, но клиентам в моем провинциальном городе без разницы на чем я пишу, применяю ли модные паттерны программирования или нет. Занимаюсь либо корпоративными сайтами, либо бэкендом — написанием внутренних корпоративных сайтов наподобие CRM, кастомных под запросы заказчика.
                                                                                                      Где же это токсичное PHP-сообщество, покритикуйте меня :))
                                                                                                        +2
                                                                                                        Судя по описанию, у вас получается фриланс примерно на 50-60к в месяц. Попробуйте устроиться на галеру на бОльшие деньги. Или на удалёнку на ещё бОльшие. А то однажды так можно оказаться вообще не востребованным на рынке труда.
                                                                                                          0
                                                                                                          Спасибо за совет. У меня есть опыт работы несколько лет программистом в одном региональном системном интеграторе, в офис я уже точно не вернусь, удаленная работа намного удобнее для меня.
                                                                                                          Видимо тут в красках представили фразу «в стиле PHP4» :) Не востребованным у меня вряд-ли получится стать, я конечно не обладаю опытом работы в ряде модных фреймворков (их можно освоить, в конце-концов при особой необходимости), но опыт работы с PHP, C#, SQL, адаптивная верстка, JS и т.п. все же имеется.
                                                                                                          Дело в том, что я несколько лет немного другим занимался делом и вернулся в веб-программирование в этом году и осознаю, что несколько отстал от трендов, хотя работа при этом находится без проблем, точнее, она сама меня находит. Но нужно бы развиваться, поэтому и написал здесь, чтобы немного подстегнуть себя.
                                                                                                            0

                                                                                                            удаленная работа и работа по заказам — это все же разные вещи
                                                                                                            особенно сегодня, когда многие крупные игроки идут в сторону remote first

                                                                                                              0
                                                                                                              Сейчас это размывается, у меня есть и разовые заказы, а есть клиент, с которым я работаю удаленно несколько лет, просто не сижу у него в офисе.
                                                                                                              0
                                                                                                              И раньше можно было найти удалённые позиции на полный рабочий день с трудоустройством, а теперь это кажется стало ещё проще.
                                                                                                              Каждому своё, мой знакомый например больше ценит возможность запилить проект и иметь возможность не работать пока деньги не кончатся, а потом снова искать проект, главное не сложный, чтобы в одного вывезти и голову сложной логикой не греть. А я ценю свою востребованность на рынке труда и более высокий и стабильный доход чем у него. А это требует сложных проектов и команд.
                                                                                                            0

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


                                                                                                            P.S. Да, Wordpress и Drupal объективно гуано. Но это не отменяет громадных плюсов Wordpress в плане пользовательского опыта

                                                                                                            0
                                                                                                            Последний абзац так вообще к PHP никакого отношения не имеет
                                                                                                              0

                                                                                                              А я начинал ещё с PHP3 и переходил к PHP4...


                                                                                                              Статья настолько прекрасна, что перечитал пару раз. Спасибо автору – вспомнил 20+ лет в PHP, как это всё было и к чему привело.


                                                                                                              И почему я пришёл к Node.js ;)

                                                                                                                0
                                                                                                                Комьюнити — это не закрытая группа, в нее может войти каждый, любой, без приглашения. Это не проблема языка, не язык (core team) собирает вокруг себя определенных людей. Всё намного сложнее.
                                                                                                                Есть отличные коммьюнити, где тусуются пара сотен (не более тысячи) людей, где каждый знает своего и у них уже не коммьюнити из всяк входящих, а своё, которое они построили. Это чаще всего чаты, группы, где модерируется по внутренним правилам.
                                                                                                                Да, есть проблема, что язык позволяет делать всё, даже BDSM, и это — одна из причин «всяк входящих», такое же положение и не только в мире PHP.
                                                                                                                Проблема в самих людях — PHP позволяет делать всё, от чего они (люди) не смотрят налево и направо.
                                                                                                                  +5
                                                                                                                  Сейчас все объясню на пальцах:

                                                                                                                  1) Появился PHP, появилось много разных компаний.
                                                                                                                  2) Лет через 10 выжившие построили крупные системы на ПХП и столкнулись с тем, что все стало сложно и неповоротливо. Надо что-то делать, иначе будет конец.
                                                                                                                  3) Одни компании стали переводить свои системы на Java, другие начали пилить костыли (Fb/Vk/Badoo и так далее). А вот последние нанимают лучших разработчиков на ПХП, которые видят проблему и говорят: «А давайте её решим также, как это решили ребята с java/net).
                                                                                                                  4) Так как лучшие разработчики на PHP имеют вес, опыт и имя в айти-сообществе, они начинают толкать разработку php в сторону Java-like языка. Добавляем сюда финансирование на выступления, доклады, книги и прочее.
                                                                                                                  5) Как итог, чтобы решить корпоративные проблемы больших компаний на PHP, разработчики тянут php к интерпрайз стандартам.

                                                                                                                  Естественно, ребята, которые пишут небольшие проекты на CMS и прочих системах начинают говорить, „А зачем это?“, „А зачем так сложно?, “А зачем копировать Java». Но так как деньги и возможности стоят за корпоративными программистами, их игнорят и правильно делают.

                                                                                                                  Вон обратите внимание на всех говорящих голов по PHP от ру-комьюнити, явно не сайтики на CMS делают.
                                                                                                                    –1
                                                                                                                    как это решили ребята с java/net

                                                                                                                    Вы думаете они что-то там решили? Да ничего подобного. У всех проблемы одни и те же. Просто в PHP мире как то принято обожествлять java/net и унижать самих себя.
                                                                                                                    +1

                                                                                                                    Каким образом наличие опытных программистов, следующих сложным принципам на сложных проектах, мешает новичкам решать свои задачи просто на простых? У PHP замечательная обратная совместимость, можно при желании по старым книжкам писать, если проект позволяет. А вот отсутствие новых фич и интересного в плане структуры кода, понятного и близкого переходящим из других технологий, ведет к неприятию и тому самому мнению, что PHP не умеет то, что могут современные языки, и негде применить свои скиллы, некуда расти.

                                                                                                                      0
                                                                                                                      Никаким образом не мешает. И статья не об этом. Она о неуместности оверинжиниринга из явамирка для большинства проектов на PHP.
                                                                                                                      +3

                                                                                                                      Автор с забавным апломбом выдаёт свои комплексы за проблемы миллионов. Редкая статья, в которой не согласен с каждым первым утверждением.


                                                                                                                      В разработке с 2001 года, поработал админом, фрилансером, в проектных организациях и продуктовых командах. Код писал на двух-трёх десятках языков, если считать всякую экзотику и эксперименты. За деньги: PHP, SQL, JS, Ruby, Groovy…
                                                                                                                      Всем прочим предпочитаю Symfony, но и Битрикс изучал, и на Drupal сайты делал. Всему своё время.


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

                                                                                                                      Only users with full accounts can post comments. Log in, please.