Почему PHP — это моя ошибка / forpes.ru

Главная
Почему PHP — это моя ошибка

Почему PHP — это моя ошибка +11

16.09.2022 05:27

kamitora 284 27000 Источник

Почему вы не прошли очередное собеседование? Вы можете прочитать кучу причин, про непрофессионализм, незнание какого-то фреймворка, софт-скилы и т.п. Главная причина - вы не понравились, вы не идеальны с точки зрения собеседующего, как человек вы ему неприятны, вы расходитесь во взглядах на жизнь. И простого подчинения политике компании на словах тут недостаточно. Я утверждаю это на основании моего довольно интересного опыта. У меня 2 стэка - PHP(Laravel и Symfony) и Ruby(Rails). Сравнивая десятки собеседований на эти 2 стэка(да, у меня два разных резюме, об этом ниже), я пришел к очень интересным выводам.

Вывод первый PHP - это одна большая помойка. От языка до инфраструктуры. От инфраструктуры до мест работы. От мест работы до людей, которые с вами работают(если вам будет проще, то я - не лучше). Но при этом нам козыряют в лицо топовыми вакансиями на PHP. Facebook, который по сути пишет на Hack и вообще топ компания мира. Вконтакт, где kphp и хайлоад. Badoo, где просто хайлоад. Гнуснейший черрипикинг.

Остальные места работы на PHP - это параши той или иной засраности, если вы работаете там даже сеньором. Есть исключения, где тебе могут выписать 7000 $ как рядовому кодошлепу, но, боже, какие же это исключения! Это редкий случай когда легаси продукт несет золотые яйца.

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

От этого я проходил десятки собеседований, делал тестовые задания, вроде все шло хорошо, а потом полный ноль ответа и фидбэка. Или фидбэк настолько шизоидный, что лучше бы дали просто отписку "наняли другого кандидата". Потому что на рынке PHP:

переизбыток кадров
нет необходимости в высоких навыках соискателей
проекты настолько "близки к народу", что народ принимает решение о том "нравится" ему специалист или нет, а не тех. специалист

Кстати о технических специалистах PHP. Не дай вам бог в резюме указать, что вы мультистэк(окроме +JS). Это настолько мощный отворот от вашего резюме, что приглашения на собесы падают в разы. Лучше даже быть специалистом одного PHP-фреймворка. И не дай бог вы скажете, что то, что, наконец, запилили пару лет назад в PHP, вы в Ruby пощупали еще 10 лет назад. И оно вам не зашло.

Типовые вопросы на собесах по PHP - это вопросы веры и дрочки. Нужно верить в SOLID(понимать нужно также как тот кто собеседует), REST(понимание как у собеседующего). Нужно задрочить именно определенную версию фреймворка. Короче, собеседоваться с PHP-шником - это как играть в шахматы с петухом, только хуже. Петух ставит мат сразу, еще до первого хода. PHP-шник мало того что всю игру кукарекает, так еще и таблицу с результатами матча в итоге не допросишься. Рынок труда PHP - это не рынок соискателя, а рынок работодателя. Знаете какая тут цена ошибки найм плохого специалиста для 95% проектов? Ноль! Можно хоть по совместимости по гороскопу и физиогномике набирать.

Да, считается плохим тоном вешать ярлыки. Но все программисты на PHP, что мне попадались - люди с интеллектом дай бог чуть выше среднего, слепо верящие в догмы SOLID, patterns, GRASP(тут все настолько абстрактно, что каждый скудоум мнит себя философом-богословом, трактуя этот талмуд). Конечно, нужно задрочить фреймворк, ведь по меркам PHP-шника это огромный труд, и все они не построены по схеме запрос-ответ-шаблонизатор-контейнер-события-orm. Современные PHP-шники напоминают мне байтоjobов 90-х, кичившихся знаниями наизусть все портов/прерываний/системы команд Алдана/ etc.

Меня самого угораздило в свое время влезть в PHP по причине жирного проекта, где я и застрял. И я много лет жалею об этом. В этом стэке некуда развиваться. Тут гнобят за развитие и критическое мышление. Тут развитие - задрачивание очередной спеки и повторение догмы. Я не единожды с огорчением слышал от собеседующих фразу "эти вопросы надо знать наизусть, а не рассказывать своими словами". Тут нет сложных проектов. Тут не нужны особые навыки. Тут важно лишь то, насколько ты приятный человек. Это гребаный тупик, если вы конечно не хотите пролезть по линии соцскиллов в менеджеры и выше. Then you are welcome.

Особенно скажу за ситуацию, когда западный страждущий сэкономить лезет в третий мир. За 1500-3000$ нужна просто преданность и отсутствие проистекания слюны изо рта. А выше нужно уже будет СВОИМ в доску, причем по софт-скилам.

А что с руби, спросите вы? Неужели все дело только в славной команде рубистов из Днепра, которые своим мужским теплом одаряют весь СНГ? Нет, и хоть вакансий по рубям меньше, моя конверсия по ним выше в 7 раз. При этом у меня 12 лет опыта с PHP и 3 года c Ruby. И мне не надо врать на собеседованиях, что я работал больше чем с одним языком. Я получаю фидбэк. Я не должен делать вид, что верю в шизу, в которую я не верю. Вместо херок и СЕО, я гораздо больше общаюсь с тимлидами. И эти тимлиды не хихикают ехидно когда ты чего-то не знаешь в кишочках фреймворка, а сразу говорят чего ты не знаешь и куда ты поэтому идешь.

А знаете почему? Потому что рынок Ruby - все еще рынок соискателя. Это рынок, где от вас, как от специалиста, что-то зависит. Где вас нанимают за то, что вы умеете, а не за то во что вы верите, и насколько психологически совместимы с главпетухом имеющим личку тимлида, насколько у вас смазливое лицо.

Предвижу вскукарек - ты не достиг вершин в PHP, тогда все было бы проще и приятнее. Согласен, но у меня есть веское возражение: я также не достиг вершин в Ruby, но тут уже все в разы проще и приятней. Не повторяйте моих ошибок - не ходите в PHP за деньгами и развитием. Как бы язык не вырос за 10 лет, это все такое же днище по технологиям и людям, что там работают. Вы не помрете от голода, зная PHP, но этот кусок хлеба вам потом в глотку не полезет.

И вы наверное думаете, что я обычный бугуртящий, отшитый на одном собесе и экстраполирующий свой опыт на всю отрасль. Нет, на моем счету уже больше 200 собеседований за последние 10 ведь, я метил в район 3000-5000 $. Так вот я жалею, что еще в середине нулевых отмахнулся от презрительного отношения к PHP-шникам. С тех пор многое поменялось, но не суть этого стэка. PHP - это такая же помойка для посредственностей, где пышным цветом цветут самые мразотные социальные явления. Некоторые проекты из десятков тысяч выстреливают из уровня дешевого прототипа и мы слышим про них дифирамбы, что ломает адекватность восприятия. Я не претендую, что вы мне поверите. Под статьей будет много контраргументов. Но помните - если вы хоть когда-то задумаетесь над тем, что возможно, что я хоть в чем-то прав, бегите из PHP. Или идите до конца - станьте нормисом и идите в менеджеры.

Комментарии (284)

Aquahawk
16.09.2022 06:37
#24737202
+5
это вопросы веры и дрочки. Нужно верить в SOLID(понимать нужно также как тот кто собеседует), REST(понимание как у собеседующего). Нужно задрочить именно определенную версию фреймворка.

слепо верящие в догмы SOLID, patterns, GRASP(тут все настолько абстрактно, что каждый скудоум мнит себя философом-богословом, трактуя этот талмуд). Конечно, нужно задрочить фреймворк

Ох как же это в точку... но не только про php. Я не буду называть технологию, не общепринят сейчас такой взгляд. Тот же js не отличается молитвами на паттерны, в нём всё ещё слишком мало корпоратов. Как Typescript избежал тлетворного влияния шарпов мне не известно, но он отлично с этим справился.

Мой ответ в голосовании: в некоторых местах то же самое, но не везде.
1. bombe
  16.09.2022 08:13
  #24737380
  +45
  Паттерны не зависят от языка. Если Вы будете делать условный наблюдатель или фабрику - то это совсем не про язык. То же можно сказать и про SOLID, GRASP, DDD, и прочие модные словечки. Вот к примеру, инверсия зависимостей. Если программист понимает, зачем оно, то ему не составит проблем использовать этот паттерн а большинстве языков. А если нет - то на любом языке будет костылить, пока не поймёт.
  
  Лично я PHP программист. Мое мнение - человек просто сдался. Не язык помойка, а автор слабак =)
  1. mivlad
    16.09.2022 08:26
    #24737424
    +21
    С автором во многом согласен, но я сдался тоже… когда попробовал Go и обнаружил, что многие боли php там решены на уровне языка и об них можно просто забыть. Сдашься тут, когда столько лет учишься ходить в одном ботинке и вдруг обнаруживаешь, что можно надеть второй.
    
    bombe
    16.09.2022 08:33
    #24737442
    Например? Какие боли у PHP по Вашему мнению? Нет асинхронности и корутин из коробки? Но в целом же есть (и асинхронность, и файберы, и множество библиотек добавляющих функционал). Я не пробовал го, мне нечего сказать о его плюсах/минусах. Я только знаю, что там нет нормальной обработки ошибок/исключений, и это для меня огромный dealbreaker.
    
    mivlad
    16.09.2022 09:32
    #24737648
    Для меня это, пожалуй, в первую очередь строгая типизация. Очень уж нравится, когда по сигнатуре сразу видно, что туда надо передавать, допустим, массив интов.
    Асинхронность и ко/горутины в общем-то и не каждый день нужны, но когда нужны — здорово, если они есть. Делал на Go одну штуку, куда клиенты приходят за неким расчётом, и если он первый в очереди и расчёт укладывается в таймаут, то клиент получает результат в рамках этого же запроса, иначе возвращается ответ «приходите позже». На Go эта логика в экрана полтора влезает, на PHP же как такое сделать, я даже и не представляю (может быть и можно, но надо крепко подумать).
    
    naff
    16.09.2022 09:35
    #24737664
    -9
    А еще на нем можно просто взять, и начать писать код вместо выдумывания очередного слоя абсьракции
    
    naff
    16.09.2022 11:40
    #24738232
    За абсЬракцию, извините. Опечатался
    
    naff
    16.09.2022 16:47
    #24739958
    Хотел бы попросить минусующих прокомментировать в чем я не прав. Ведь в go система типов стимулирует сначала писать код, а затем, где это необходимо использовать абстракции на стороне потребителя данного кода. В php все наоборот так как система типов требует реализовать интерфейс явно
    
    hello_my_name_is_dany
    16.09.2022 19:17
    #24740574
    +1
    Не стимулирует вообще. Dependency Inversion можно делать везде, где есть "интерфейсы".
    
    В PHP просто нет утиной типизации, но вам никто не мешает сначала писать интерфейсы, использовать и только потом их имплементировать. Но если совсем надо, то можно просто не указывать у аргументов тип вообще.
    
    В Go точно так же мы можем просто указывать тип структуры, а не интерфейса, никакой стимуляции нет.
    
    naff
    16.09.2022 19:48
    #24740654
    -1
    Вы меня наверное не верно поняли. Представим ситуацию что вы используете внешний пакет. В нем нет интерфейсов вообще. Вы можете его использовать в своем коде и при этом спокойно написать к нему интерфейсы и замокать его. В php весь уровень абстракции нужно закладывать на этапе проектирования внешнего пакета, и вы на это не можете повлиять из вне.
    
    В том то и речь что в go мы используем тип структуры пока не понадобится ввести абстракцию. При этом можем это делать для кода от которого мы зависим но не можем изменить
    
    Sergey89
    17.09.2022 06:55
    #24741802
    +3
    В php просто мокается конкретный класс. Не нужен для этого интерфейс даже.
    
    А настоящая абстракция от сторонней библиотеки, что в go, что в php будет делаться через какой-нибудь адаптер.
    
    bombe
    16.09.2022 09:56
    #24737756
    +19
    В PHP есть строгая типизация (strict_types), правда нет дженериков (которые можно указать в аннотациях). Есть type hint, return type. Есть статические анализаторы phpstan/psalm/phan. В общем, язык сам по себе может обеспечить явную строгую типизацию, имея даже специальное исключение TypeError.
    
    Асинхронность и корутины можно добавить, но если нужен воркер - то тут очевидно лучше выбрать golang, хотя и на PHP всё возможно сделать: файберы, ReactPHP, разные реализации серверов, типа RoadRunner, swoole, в общем - выбор имеется.
    
    То что Вы описали - вечно крутящийся воркер. Да, на PHP тоже такое можно. И, например, прикрутить еще Temporal. да, не просто всё, но можно =)
    
    В целом хочется добавить, что у PHP есть своя ниша. Я считаю, что PHP - хороший язык программирования, который хоть и не идеален, но лично мне нравится таким, какой он есть =)
    
    mivlad
    16.09.2022 10:04
    #24737802
    +1
    Про strict_types знаю, массив интов как описать? :-)
    
    stepmex
    16.09.2022 10:17
    #24737854
    +1
    Эмм: int[]
    
    naff
    16.09.2022 10:28
    #24737924
    +4
    Так не работает) по крайней мере средствами языка
    
    bombe
    16.09.2022 10:19
    #24737872
    +2
    В докблок. И использовать статический анализатор. Он не пропустит ничего, кроме int, иначе выдаст ошибку. Да, не совсем то, что ожидалось, но массив int на самом деле редко передаётся. Скорее это будет коллекция по интерфейсу коллекции. И, на самом деле, докблок для типизации редко используется, но бывает, как вот этот конкретный случай. Как минимум, Вы точно не сможете вызвать эту функцию с аргументом, отличным от массива. А то что там инты - берёт на себя анализатор.
    
    <?php declare(strict_types=1); /** @param int[] $integers */ function doSomethingWithIntegers(array $integeres): void { }
    
    mivlad
    16.09.2022 10:27
    #24737916
    +3
    Вот, без внешних подпорок сам язык не позволяет. И если мы делаем библиотеку для использования неограниченным кругом лиц, то вопрос об использовании коллекции начинает уже слегка выходить в моральную плоскость. Ну да, хоть про докблоки более-менее все договорились.
    
    bombe
    16.09.2022 10:33
    #24737952
    Как я говорил, такая типизация в докблоке - редкое явление. Это скорее индикатор того, что можно сделать лучше.
    
    BoShurik
    16.09.2022 11:13
    #24738104
    +9
    Позволяет
    
    function doSomethingWithIntegers(int ...$integers): void { var_dump($integers); } doSomethingWithIntegers(1, 2, 3); doSomethingWithIntegers(...[4, 5, 6]);
    
    bombe
    16.09.2022 11:30
    #24738198
    Кстати да. Отличный пример, спасибо, я как-то даже не подумал. У PHP, на самом деле, очень много крутых фич подъехало с 8.0/8.1.
    
    InsanusMokrassar
    16.09.2022 11:40
    #24738234
    +2
    Судя по-всему, это vararg, тем забавнее на самом деле - чтобы решить проблему отсутствия дженериков вы на вход принимаете не массив, а набор объектов. Стоит понимать, что это костыль, а не решение, потому что я (если я правильно понял) не смогу сделать класс на базе дженерика и передать его с сохранением этого дженерика. Также, как я не могу передать массив объектов со своими дженериками.
    
    P. S. Поправьте меня, если я в чем-то не прав
    
    bombe
    16.09.2022 12:04
    #24738370
    Это variadic, и integers будет именно массивом int. Аргументом функции нельзя будет передать что-либо кроме int.
    
    не смогу сделать класс на базе дженерика и передать его с сохранением этого дженерика
    
    можете пример на другом языке, что именно Вы хотите? В PHP нет дженериков, выкручиваемся как можем =)
    
    InsanusMokrassar
    16.09.2022 12:30
    #24738434
    Это variadic, и integers будет именно массивом int. Аргументом функции нельзя будет передать что-либо кроме int.
    
    Да, я это и имел ввиду :) фактически это костыль :)
    
    можете пример на другом языке, что именно Вы хотите? В PHP нет дженериков, выкручиваемся как можем =)
    
    class Sample<T> { T someData; } function someFun(input: Array<Sample<String>>)
    
    В примере выше у нас будет класс Sample с дженериком T. Когда мы знаем, что класс Sample имеет своим дженериком String - мы знаем, что его поле someData - это String и ничто иное
    
    bombe
    16.09.2022 13:05
    #24738566
    Нет, именно так, вроде нельзя. Но с другой стороны, я смогу создать SampleInterface, унаследовать нужные T от интерфейса, и использовать их:
    
    <?php interface SampleInterface {} final class SampleString implements SampleInterface {} function someFun(SampleInterface ...$samples) {} function someFunString(SampleString ...$stringSamples) {}
    
    Можно быть точно уверенным, что там именно массив элементов, наследующих SampleInterface (someFun) или SampleString (someFunString). В данном случае PHP более "многословен", но вроде как решает задачу. При чём someFunString в принципе и не нужно, если Вам не нужна специфическая реализация. Возможно есть способ и получше. Можно передавать как массив. Тогда нужен докблок (для указания типа элементов) и, возможно, проверка. Костыли, да. Но ведь можно хоть немного абстрагироваться.
    
    InsanusMokrassar
    16.09.2022 13:18
    #24738638
    Можно и так, но на каждый тип не создашь :)
    
    bombe
    16.09.2022 13:44
    #24738746
    +1
    Практика показывает, что когда возникает подобная необходимость, то там не так уж и много наследников получается, да и поддерживать все-все возможные типы не так уж и нужно.
    
    InsanusMokrassar
    16.09.2022 13:59
    #24738804
    Справедливости ради, у вас два пути - либо использовать костыли вроде variadic (которые не везде получится использовать), либо уповать на то, что статические анализаторы всех спасут. Оба варианта являются костылями и не решают проблему отсутствия обобщений до конца
    
    bombe
    16.09.2022 14:10
    #24738852
    А variadic и не нужен. Это как пример. Вариантов, на самом деле достаточно. Можно как аргумент передать коллекцию, в которой все элементы гарантированно будут типизированы. Можно передать простой массив и проверять instance of элемента (или использовать статический анализ). А можно просто вызвать someFun на всех элементах массива, что тоже избавляет от необходимости иметь такой дженерик.
    
    Но в целом Вы правы. Иногда не хватает подобного функционала, но с этим жить можно =)
    
    BoShurik
    16.09.2022 13:14
    #24738610
    +1
    Да, так нельзя, но нас спасают статические анализаторы:
    
    /** * @template T */ class Sample { /** * @param T $someData */ public function __construct(public $someData) { } } /** * @param Sample<string>[] $input */ function someFun(array $input): void { print_r($input); } someFun([new Sample('string')]); someFun([new Sample(10)]);
    
    https://psalm.dev/r/658910a73a
    
    InsanusMokrassar
    16.09.2022 13:20
    #24738644
    Это статический анализ, а не фича языка :) хорошо, если такой анализ во время билда/запуска работает, а если только в редакторе кода - ну, ок, как костыль пойдет
    
    bombe
    16.09.2022 13:45
    #24738752
    По хорошему такой анализ всегда добавляется в CI =)
    
    maximw
    16.09.2022 15:11
    #24739534
    +1
    То, что вы называете фичей языка - статический анализатор компилятора. Та же хрень, только у в PHP это отдельно статический анализатор и интерпретатор.
    
    mivlad
    16.09.2022 15:47
    #24739740
    +2
    Язык — это не компилятор и не интерпретатор, а набор правил, позволяющих отличить программу на языке от прочих наборов букв.
    
    kamitora Автор
    16.09.2022 14:10
    #24738850
    -3
    И спасибо, что напомнили еще и про это - из-за него разработка на PHP сейчас настолько IDE-oriented, что на человека без PHP Storm косо смотрят.
    
    bat
    16.09.2022 19:45
    #24740642
    предлагаете вернуться в far/mc/..? брр...
    
    kamitora Автор
    16.09.2022 20:00
    #24740702
    Предлагаю не впадать в крайности.
    
    tendium
    18.09.2022 14:15
    #24744824
    Погодите, как Psalm связан с PHPStorm?
    
    kamitora Автор
    18.09.2022 16:09
    #24745156
    Я хочу донести мысль, что PHP для проверки типов излишне полагается на внешние инструменты. Наиболее частым из них явяляется PHPStorm. А так да, есть psalm и phpstan и codesniffer, но большая часть сидит в пыхосторме.
    
    Это кстати еще одна вещь, от которой у меня дичайше горело - мой форкфлоу на работе включал в себя vscode + phpstan + phpmd. Остальная команда считала, что я страдаю херней, а нормальные люди должны использовать PHPStorm. Ну удобнее мне один раз перед коммитом все прогнать и починить, не отвлекаясь на подсвечивания все время. Производительность была одинаковая, но за мной стойко ходили слухи, что я не осилил IDE.
    
    tendium
    18.09.2022 16:45
    #24745246
    А так да, есть psalm и phpstan и codesniffer, но большая часть сидит в пыхосторме.
    
    То, что есть PHPStorm умеет интегрироваться с данными инструментами, это типа что-то плохое?
    
    Производительность была одинаковая, но за мной стойко ходили слухи, что я не осилил IDE.
    
    Это бессмысленные холивары. Если вам удобно работать в VSCode, работайте там.
    
    Тем не менее у постоянной подсветки недочетов и ошибок есть один, на мой взгляд, плюс. Он корректирует стиль кодинга. В конечном итоге линтеры и статик-анализаторы всё меньше будут ловить недостатков в вашем коде. А значит вы будете по итогу чуть быстрее работать. Но на это нужно время. Сразу ничего не бывает.
    
    Лично я пользуюсь продукцией JetBrains просто потому, что там удобнее делать рефакторинг, лучше сделана индексация кода и, соответственно, навигация по коду получается быстрее. Но тут действительно нужно освоить предлагаемый функционал. Иначе разницы между VSCode и PHPStorm действительно не будет заметно.
    
    kamitora Автор
    18.09.2022 19:06
    #24745634
    
    То, что есть PHPStorm умеет интегрироваться с данными инструментами, это типа
    
    что-то плохое?
    
    Вы же сами пишете ниже, что PHPStorm имеет собственный линтер показывающий нечто, что не под силам этим инструментам. Да, я считаю плохо, когда коммерческая компания диктует де-факто стандарт как должен писаться код на языке, к которому она не имеет никакого отношения. Особенно умиляет, что половина народу в СНГ сидит на самых крутых версиях с торрентов. Прямо ностальгия по временам Delfi 7.
    
    Это бессмысленные холивары. Если вам удобно работать в VSCode, работайте там. Тем не менее у постоянной подсветки недочетов и ошибок есть один, на мой взгляд, плюс. Он корректирует стиль кодинга. В конечном итоге линтеры и статик-анализаторы всё меньше будут ловить недостатков в вашем коде. А значит вы будете по итогу чуть быстрее работать. Но на это нужно время. Сразу ничего не бывает.
    
    И тем не менее вы неявно намекаете, что PHPStorm лучший вариант. И вот такие намеки я слышал постоянно. И даже в тех конторах где был код-стандарт, и я и мои коллеги ему соответствовали, используя разные инструменты. Но все равно постоянно чувствуется давление, если ты не используешь PHPStorm. Выбиваешься из коллектива. Короче обычная ксенофобия и страх, что твой выбор не самый лучший и желание навязать его всем.
    
    Лично я пользуюсь продукцией JetBrains просто потому, что там удобнее делать рефакторинг, лучше сделана индексация кода и, соответственно, навигация по коду получается быстрее.
    
    И поэтому только для рефакторингов я его и использую, потому что, увы, альтернатив нет. Навигацию можно сделать хоть через LSP, хоть через ctags.
    
    Но тут действительно нужно освоить предлагаемый функционал. Иначе разницы между VSCode и PHPStorm действительно не будет заметно.
    
    Любой редактор кода типа vim, emacs, vscode и даже PHPStorm нужно осваивать. И ввиду разрозненности инструментов из которых приходится собирать себе IDE из редактора, степень освоения там будет повыше, чем в PHPStorm. Единственное чем кардинально отличается вся линейка JIdea-based IDE, так это тем, что там есть нормальный API для индексатора и рефакторинга. Но за кучу лет я припомню только один раз когда мне это пригодилось. И то по затраченному времени, возможно, codemod был эффективней.
    
    tendium
    18.09.2022 19:21
    #24745662
    Вы же сами пишете ниже, что PHPStorm имеет собственный линтер показывающий нечто, что не под силам этим инструментам.
    
    Где я это написал?
    
    Да, я считаю плохо, когда коммерческая компания диктует де-факто стандарт как должен писаться код на языке, к которому она не имеет никакого отношения.
    
    Откуда такой вывод? Стандарты определяют мейнтейнеры проекта (ну или не определяют и пишут кто как попало). PHPStorm лишь помогает придерживаться тех стандартов, которые определены в проекте.
    
    Да, PHPStorm может подсказывать по коду что-то сверх настроенных линтеров (хотя я об этом не писал), но
    
    во-первых, это отключаемо,
    
    во-вторых, программист волен им следовать или не следовать,
    
    в-третьих, JetBrains "немного" имеет к PHP отношение — погуглите кто такой Никита Попов (Никита, правда, уже не работает в JetBrains, но его вклад в развитие php непереоценим).
    
    И уж точно в дополнительных подсказках от IDE нет никакого криминала.
    
    И тем не менее вы неявно намекаете, что PHPStorm лучший вариант.
    
    Для меня — да. Но для вас может быть по-другому. Это нормально. Свобода выбора и всё такое.
    
    Если бы мы работали удаленно в одной команде, я бы, возможно, так и не узнал, какой IDE вы пользуетесь. Вот у меня сейчас в команде 5 человек. Я понятия не имею, кто из них каким IDE пользуется. Зачем мне это знать?
    
    kamitora Автор
    18.09.2022 19:59
    #24745772
    
    Где я это написал?
    
    Он корректирует стиль кодинга. В конечном итоге линтеры и статик-анализаторы всё меньше будут ловить недостатков в вашем коде.
    
    Извините, я вас неправильно понял. Думал, вы имели standalone линтеры в противовес PHPStorm.
    
    Откуда такой вывод? Стандарты определяют мейнтейнеры проекта (ну или не определяют и пишут кто как попало). PHPStorm лишь помогает придерживаться тех стандартов, которые определены в проекте.
    
    А получается ситуация как с Chrome сейчас и IE 6 в нулевых. Стандарты есть только формально, а на деле определяются софтом. И даже если у тебя в команде условный PSR-12, то нет никаких гарантий что на код-ревью не прилетит страйк за то что аннотация не так как у него в PHPStorm отформатирована, хотя явно это не регламентируется.
    
    Да, PHPStorm может подсказывать по коду что-то сверх настроенных линтеров (хотя я об этом не писал), но
    
    * во-первых, это отключаемо,
    
    * во-вторых, программист волен им следовать или не следовать,
    
    На практике это почти никогда не отключается. Хуже того, огромный процент PHP-шников в принципе не понимает разницу между ошибкой в стиле кодирования и подсказкой, что можно сделать лучше - если IDE говорит, значит надо делать.
    
    * в-третьих, JetBrains "немного" имеет к PHP отношение — погуглите кто такой Никита
    
    Попов (Никита, правда, уже не работает в JetBrains, но его вклад в развитие php
    
    непереоценим).
    
    Насколько мне известно, развитие PHP не являлось прямой обязанностью Никиты во время его работы в PHP. Но даже если я неправ, то все отношение JetBrains к PHP - это стрижка профита с PHPStorm. В случае Jetbrains и Kotlin, Microsoft и C# ситуация другая - компании создали язык и им решать как его развивать.
    
    И уж точно в дополнительных подсказках от IDE нет никакого криминала.
    
    Выше написал почему криминал есть, хотя сами подсказки полезны, да.
    
    Для меня — да. Но для вас может быть по-другому. Это нормально. Свобода выбора и всё такое.
    
    Она только на словах. Вот например наша с вами дискуссия: вы искренне не видите или не хотите видеть, что я вижу. Вы стремитесь доказать, что я неправ. Формально это свобода слова - каждый высказывает свой опыт и точку зрения. На практике это будет бесконечный срач, где я буду говорить: тут проблема, а в ответ получать (это не проблема|проблемы нет|а что вообще такое проблема) и т.д. Это касается не только PHP, но тут для меня это выражено наиболее остро.
    
    Если бы мы работали удаленно в одной команде, я бы, возможно, так и не узнал, какой IDE вы пользуетесь. Вот у меня сейчас в команде 5 человек. Я понятия не имею, кто из них каким IDE пользуется. Зачем мне это знать?
    
    Потому что ваша IDE могла бы использовать другие сниппеты, подсказки как сделать лучше, и в итоге это бы все вылезало на кодревью, усложняя работу с теми у кого PHPStorm. А еще есть не-удаленка, где норма что кто-то подойдет и будет работать за твоим компом, чтобы по быстрому перескочить в код, по которому у тебя вопросы.
    
    Спасибо вам за диалог, но на дальнейшие ваши сообщения в этой ветке я не вижу смысла отвечать.
    
    tendium
    18.09.2022 20:29
    #24745812
    И даже если у тебя в команде условный PSR-12, то нет никаких гарантий что на код-ревью не прилетит страйк за то что аннотация не так как у него в PHPStorm отформатирована, хотя явно это не регламентируется.
    
    Это уже не к PHPStorm вопрос, а к договоренностям в команде и культуре код-ревью. Если вдруг оказалось, что команда хочет следовать тому или иному стилю в коде, то это стоит внести в линтер и явным образом проверять в CI. Чтобы избежать препираний в код-ревью.
    
    огромный процент PHP-шников в принципе не понимает разницу между ошибкой в стиле кодирования и подсказкой, что можно сделать лучше — если IDE говорит, значит надо делать.
    
    Это опять же не проблема IDE. И не проблема PHP. А проблема конкретной команды и конкретных людей. Вы могли бы попытаться поднять этот вопрос на уровень дискуссии и попытаться найти компромисс.
    
    Насколько мне известно, развитие PHP не являлось прямой обязанностью Никиты во время его работы в PHP.
    
    Я, разумеется, не читал контракт Никиты, но, судя по всему, свой вклад в PHP он таки делал в обычные рабочие часы. И это нормально. У нас в компании тоже уделяется время и внимание опенсорсу.
    
    Но даже если я неправ, то все отношение JetBrains к PHP — это стрижка профита с PHPStorm.
    
    Как будто это что-то плохое для обеих сторон. Одна сторона (бизнес) получила профит. Другая сторона (сообщество) получило улучшения используемого языка. Win-win — нет?
    
    Она только на словах. Вот например наша с вами дискуссия: вы искренне не видите или не хотите видеть, что я вижу.
    
    Я думаю, что я понимаю, о чем вы. Другое дело, что я почему-то не сталкиваюсь в своей практике с описываемыми вами проблемами.
    
    Вы стремитесь доказать, что я неправ.
    
    Скорее я пытаюсь раскрыть вам глаза на тот факт, что описываемые вами проблемы не являются нерешаемыми.
    
    Потому что ваша IDE могла бы использовать другие сниппеты, подсказки как сделать лучше, и в итоге это бы все вылезало на кодревью, усложняя работу с теми у кого PHPStorm.
    
    Ну… в диффе в PR подсказок IDE нет ни у кого (если, конечно, не пользоваться плагинами, которые позволяют делать ревью в IDE, но это отдельный разговор). А стягивать к себе код и ревьюить изменения локально — это, прямо скажем, делает далеко не каждый.
    
    Но даже если так сошлись звёзды, и коллега открыл ваш код в IDE, увидел подсказки от IDE и предложил эти изменения в PR, то что такого? Это плохо? При ревью в PR могут быть 3 варианта развития событий:
    
    Вы согласны
    
    Вам не принципиально
    
    Вы не согласны (или как минимум не понимаете важность запрошенных изменений)
    
    На первых двух случаях останавливаться не будем — там всё ясно, вносим изменения и готово.
    
    Поэтому сразу 3-й случай. Почему бы не попросить коллегу мотивировать свой запрос развернуто? И если таки это сугубо вкусовщина (но с ней согласна бóльшая часть команды), то, как я написал выше, заносите это в правила своего линтера в CI и всё.
    
    P.S. И вам спасибо.
    
    denis-isaev
    16.09.2022 21:25
    #24741004
    +6
    Лол. Полгода назад, когда в Go не было дженериков, евангелисты Go говорили, что отсутствие дженериков — это достоинство языка, потому что simplicity и вот это все. Как только в Go завезли дженерики, евангелисты сразу переобулись и пошли войной на языки без дженериков :)
    
    tendium
    18.09.2022 14:35
    #24744858
    +1
    А дженерики-то недозавезли в go. Скажем, дженерики нельзя использовать в методах структур: https://go.dev/play/p/Xp6BDMgMkum.
    
    А ещё нельзя сделать вот так: https://go.dev/play/p/Wi1Kq3JV8aS. Т.е. у вас может быть дженерик, объединяющий map[int]any и []any, но вы не можете по нему итерироваться, ибо "cannot range over t (variable of type P constrained by ~map[int]T|~[]T) (P has no core type)".
    
    tendium
    18.09.2022 14:12
    #24744818
    Ниже можно не читать. Уже дали пример, не заметил.
    
    Если вы хотите гарантировать, что вы получите на вход инты (или любой другой тип), вы можете сделать функцию с вариадическими аргументами:
    
    public function callme(int ...$ints) { $this->ints = $ints; }
    
    Вызывать эту функцию так:
    
    $ints = [1, 2, 3, 4]; $obj->callme(...$ints);
    
    Да, это несколько не то, чего хотелось бы от языка. Но технически возможность имеется. Без посторонних средств.
    
    bat
    16.09.2022 11:33
    #24738206
    +5
    многие боли php там решены на уровне языка
    
    первую очередь строгая типизация
    
    я правильно поимаю, что вы называете болью отсутствие типизации в нетипизированном языке?
    
    mivlad
    16.09.2022 11:46
    #24738268
    Ну оно не перестаёт быть болью, даже будучи by design :-)
    И все эти попытки типизацию там изобразить говорят о том, что не мне одному без неё некомфортно.
    
    gmtd
    16.09.2022 11:51
    #24738290
    +1
    Если вы вегетарианец - вы едите блюда без мяса
    
    Если вам нужна строгая типизация - вы программируете на языках, которые основаны на ней
    
    А вегетарианцы пусть едят искусственную говядину (те, кому нужен вкус плоти)
    
    Все довольны
    
    p.s. Нежелание вегетарианцев есть мясо - это не их боль.
    В смысле, это вообще не боль
    
    bombe
    16.09.2022 11:56
    #24738318
    +2
    Никто не изображает. Она там есть. На проектах, в которых я работаю везде включена строгая типизация и везде используются статические анализаторы (ну и плюс cs, phpunit, deptrac). У Вас не получиться просто взять и передать int, где ожидается string.
    
    w96k
    16.09.2022 16:36
    #24739916
    На ваших проектах строгая статическая типизация. В самом языке она слабая динамическая с кучей неявных преобразований типов.
    
    bombe
    16.09.2022 17:37
    #24740200
    +1
    Если я в начале скрипта укажу declare(strict_types=1);, и укажу тип для каждого свойства, каждого аргумента каждого метода и его возвращаемый тип, то никаких неявных преобразований не возникнет. В документации это четко указано:
    
    In strict mode, only a value corresponding exactly to the type declaration will be accepted, otherwise a TypeError will be thrown.
    
    Но PHP позволяет не делать этого, что является по умолчанию и чем, собственно, пользуются. Всё зависит от разработчика.
    
    w96k
    18.09.2022 12:38
    #24744576
    Это помогает конечно, но не меняет картину. Скажем в PHP есть великолепная структура хешмапамассив, которую можно задать при помощи []. Вроде бы обсуждали тут в комментариях и в языке нет способов указать явно без костылей, что нам нужно, массив настоящий (как во всех языках) или хешмапа с ключами и значениями. В этом месте как минимум при любых настройках проявляется натура слабой типизации, хотя если любой массив php воспринимать как хешмпапу и забыть о существовании массивов в принципе, то может быть и нормально.
    
    tendium
    18.09.2022 13:07
    #24744662
    +1
    если любой массив php воспринимать как хешмпапу и забыть о существовании массивов в принципе, то может быть и нормально.
    
    Как только вы такое принимаете к сведению, вы делаете невозможным (или затруднительным) решение ряда задач, где важен порядок элементов в массиве (ибо в классической hashmap порядок не гарантирован).
    
    Начиная с PHP 8.1 есть функция array_is_list. Она может проверить тип вашего массива. В своем коде вы можете делать валидацию данных и действовать соответственно. Да, это при неаккуратной работе с данными может привести к ошибкам, но на то уже есть тесты и код-ревью. Возможно, в будущем добавят более строгий массив. А пока как есть.
    
    mafia8
    18.09.2022 14:07
    #24744812
    вы делаете невозможным (или затруднительным) решение ряда задач, где важен порядок элементов в массиве
    
    $a=[];
    for($i=0;$i++;$i<10) $a[$i]=something;
    если индексы — числа, то порядок будет. Или как?
    
    tendium
    18.09.2022 14:19
    #24744828
    Порядок, разумеется, можно получить. Но, скажем, получать первых 1000 элементов вы как будете? По одному будете вычитывать из hashmap? Какова будет эффективность такого кода?
    
    И да, если вам надо отрезать кусок от массива с начала. Вы в хвосте массива имена элементов будете переименовывать? Или где-то хранить значение наименьшего индекса?
    
    w96k
    18.09.2022 19:55
    #24745760
    Понимаю, просто без этого простого типа данных в принципе гарантии "сильной" типизации уже не такие существенные, потому что эти две структуры применяются очень часто при написании кода.
    
    В стандартной библиотеке есть класс с массивом, но он статический в стиле си, нельзя в него нельзя динамически добавлять лишние элементы. И он довольно вербозный, в реальной кодовой базе не видел, чтобы его применяли.
    
    https://php.net/manual/en/class.splfixedarray.php
    
    denis-isaev
    16.09.2022 21:29
    #24741022
    +1
    Ну да, забивать гвозди лезвием топора не перестаёт быть болью, даже будучи by design. Но вместо того, чтобы ворчать, что обухом топора вроде получается, но все равно не очень, может лучше адекватнее выбирать инструмент под задачу?
    
    kamitora Автор
    16.09.2022 16:47
    #24739950
    +2
    я правильно поимаю, что вы называете болью отсутствие типизации в нетипизированном языке?
    
    Тут еще была отдельная боль на собеседованиях. Когда с приходом семерки и типов ты судорожно пытался угадать, кто твой интервьюер - адепт старой школы, считающий, что PHP - язык динамический и енти типы бесовские нам тут не нужны. Или же человек джва года ждавший типизацию и не видящий жизни без нее. Оба типа выдавал вопрос: используете ли вы типы? Ответ, что буду использовать в зависимости от кодостиля вашей компани, обычно не устраивал.
    
    bat
    16.09.2022 19:53
    #24740668
    буду использовать в зависимости от кодостиля вашей компани
    
    скорее, конкретного проекта, а не компании
    
    в любом случае, если собеседующему надо чтобы вы угадали его позицию, а не озвучили свою - это звоночек, там делать нечего
    
    bombe
    17.09.2022 09:06
    #24741932
    +4
    Лол, не вводите людей в заблуждение байками многолетней давности. PHP7 вышел 7 лет назад, PHP8 уже года два как релизнулся. И у меня есть огромные сомнения, что Вы вообще видели его в глаза с битриксом и ларавелем =)
    
    tommyangelo27
    16.09.2022 12:08
    #24738382
    +4
    У Go другие недостатки. Я бы не стал на нём писать сложную бизнес-логику, вроде чекаута на маркетплейсе.
    
    Эдак мы придём к тому, что у разных языков разная область применения :-)
    
    12rbah
    16.09.2022 12:36
    #24738458
    Вроде чекаута на маркетплейсе.
    
    Может я чего-то не понимаю, можете пояснить почему go не подходит для этой задачи, и почему не подходит для сложной бизнес логики, ну или хотя бы раскрыть, что подразумевается под сложной бизнес логикой?
    
    tommyangelo27
    16.09.2022 13:52
    #24738784
    +1
    Я подразумеваю большое число объектов (десятки и иногда сотни) и их коллекции, а также их взаимодействия друг с другом. Лично мне в Go не хватает наследования и эксепшенов.
    
    12rbah
    16.09.2022 15:48
    #24739742
    Я подразумеваю большое число объектов (десятки и иногда сотни) и их коллекции, а также их взаимодействия друг с другом.
    
    В целом это можно реализовать, да это будет труднее чем в пхп или питоне, но как по мне это не особая проблема.
    
    Лично мне в Go не хватает наследования
    
    В целом, что-то близкое к обычному ООП наследованию можно сделать через интерфейсы и встраивание, но опять же реализация будет труднее.
    
    и эксепшенов.
    
    Это довольно холиварный вопрос(не только в го). В ряде языков - это довольно легкая конструкция, которую можно использовать для обработки обычных ошибок (например если не можешь подключиться к базе, то кидаешь эксепшен), но например в c++ их рекомендуют использовать только в крайних случаях, имеется ввиду случаи, которые не может предусмотреть программист, например, что-то в сторонней либе упало, но многие все равно используют для простых случаев, т.к. удобно. В го вы также можете делать через panic/recover, но в современном коде использовать паники не считается хорошим подходом (кроме некоторых случаев, в которых паника не должна восстанавливаться), поэтому они обычно бывают когда что-то с nil делаешь или проблема находится в сторонней либе. Просто я еще помню как на парах по c++ препод учил обрабатывать деление на 0 при помощи исключений, но в реальности такой подход оказался неправильным, кода конечно меньше получается, но ситуация на самом деле не является исключительной.
    
    tommyangelo27
    16.09.2022 16:01
    #24739796
    +3
    В целом это можно реализовать, да это будет труднее чем в пхп или питоне, но как по мне это не особая проблема.
    Так я и не утверждаю, что нельзя. Просто в условиях постоянно меняющихся бизнес-требований код на том же PHP (или на C#/Java) получается более понятным (в смысле откуда что берётся) и проще поддается модификации.
    
    У меня на Go отлично получается реализовать задачи в стиле SRP, когда есть конкретный сценарий с несколькими условиями, который нужно обслужить. Такой себе сферический микросервис в вакууме.
    
    А вот когда в одном месте сценариев может несколько десятков, требования к ним могут меняться каждые пару месяцев, в реализации нужно учесть зависимость от фазы луны, первой буквы имени собаки покупателя и дня недели — код на Go получается слишком многословным и запутанным. Обычные ООПшные классы имхо лучше справляются с сокрытием сложности в своих недрах.
    
    Вполне допускаю, что я просто плохо умею в Go ????
    
    tendium
    18.09.2022 13:52
    #24744772
    В целом, что-то близкое к обычному ООП наследованию можно сделать через интерфейсы и встраивание, но опять же реализация будет труднее.
    
    В go встроенная структура не имеет ни знаний о том, куда она встроена, ни доступа к встраивающей её структуре. Это, соответственно, делает невозможным абстрактные функции. Это так же делает невозможной работу с обрамляющей структурой во встроенной (т.е. вы не сможете встроить структуру и её методы применять не к ней самой, а к обрамляющей структуре).
    
    P.S. Да, можно заранее предусмотреть во встроенной структуре механизмы — типа переменных с типом функции, куда вы будете присваивать свои функции, меняя тем самым поведение. Вы можете также передавать во встроенную структуру указатель на обрамляющую. Но как-то это уже сильно много возни. О хрупкости и избыточной связности такого кода уже и говорить не приходится. Да и на ООП это уже как-то не очень похоже будет.
    
    0xd34df00d
    17.09.2022 07:04
    #24741808
    +2
    Почему — система типов слабая, язык адски многословный, выражать мысли тяжело, рефакторить тяжело.
    
    Что — например, тайпчекер, или симулятор транзакций в очередном блохчейне, или компилятор, или мало ли.
  1. Aquahawk
    16.09.2022 08:34
    #24737446
    +2
    Паттерны действительно не зависят от языка, но у разных языков разные комьюнити, и в некоторых из них наблюдается явные перегиб в отношении молитв на божественные паттерны и вера в то, что напихивание всех паттернов. которые они знают, сделает их код лучше просто само по себе. Это так не работает. Ещё раз, я не говорю что паттерны это плохо. Это как таблетки, применённые по делу в нужной дозировке очень полезны, применённые от балды в неумеренных количествах - безусловный вред. Я говорю именно о бездумном применение паттернов, и комьюнити разных языков болеют этим в разной степени, а некоторые почти не болеют.
  1. 9982th
    16.09.2022 14:53
    #24739306
    +2
    Паттерны таки зависят от языка. Если вы на Питоне будете реализовывать условный синглтон по канонам банды четырех, с переопределением конструктора и фабричным методом, — это будет выглядеть несколько странно. Ещё более странно будет выглядеть классический итератор, реализующий next() без нижних подчеркиваний.
    Мало знать что такое фабрика в принципе, нужно уметь выразить это при помощи средств языка и в рамках общепринятых хороших практик.
    
    bombe
    16.09.2022 15:34
    #24739690
    Если перефразировать - от языка зависит, сможете ли Вы адекватно реализовать конкретный паттерн на конкретном языке, и нужен ли он Вам. Как пример - тот же синглтон в PHP (да и не только) считается антипаттерном и не используется.
    
    Но паттерн от языка никак не зависит.
    
    KGeist
    16.09.2022 19:56
    #24740680
    +2
    Слышал мнение, что паттерн — это просто эмуляция того, что отсутствует в языке синтаксически, другими средствами. Например, где-то функтор это целый паттерн, а где-то самая обычная лямбда.
  1. w96k
    16.09.2022 16:28
    #24739884
    +4
    Паттерны нужны для тех языков, где вне объектной модели нельзя достичь таких же результатов. Паттерны Haskell, Scala, Common Lisp, SML, Ocaml и т.д. могут отличаться и отличаться довольно сильно от паттернов принятых на мейнстримных Java-like объектных языках.

Aquahawk
16.09.2022 06:42
#24737210
Вы мне напомнили о моём давнем желании написать эссе о дрочке на "гибкость" и "расширяемость" "архитектуры". Про электрика с очень гибкой и расширяемой резиновой лестницей.
1. gmtd
  16.09.2022 07:02
  #24737258
  +1
  А что не так? Архитектура современного [серверного] приложения должна быть гибкой и расширяемой
  
  Иначе будешь переписывать код несколько раз
  1. Aquahawk
    16.09.2022 07:08
    #24737266
    +11
    Квайны - очень гибкие приложения, можно запускать на разных языках. Давайте делать сервер так чтобы его можно было запустить и питоном и пыхой и явой, нам же нужна гибкость. Давайте сделаем так, чтобы сервер мог работать и с ораклом и постгрёй и монгой и с локальными файликами без бд, очень же гибко, вдруг бд нет. Я надеюсь вы поняли. Гибкость часто превращена в карго-культ. Гибкость стоит закладывать там где надо и в необходимых пределах. Иначе получаются очень гибкие лестницы из резинок от трусов. Не работает, не держит нагрузку, зато гибко.
    
    antonkrechetov
    16.09.2022 20:26
    #24740786
    Гибкость стоит закладывать там где надо и в необходимых пределах.
    Это очень правильно. Думаю, любого разработчика спроси — он согласится, что, конечно, гибкость важна, но только в необходимых пределах, и что оверинжиниринг — это, конечно, плохо.
    
    Но есть одна проблема: каждый под необходимым уровнем гибкости понимает что-то своё (весь код не в одном файле? слишком сложно). Так что без описания способа понять, когда стоит остановиться, и разбора конкретных кейсов эти рассуждения не очень полезны.
  1. urvanov
    16.09.2022 07:19
    #24737280
    +4
    С гибкостью и расширяемостью тоже меры надо знать. Мало в каком проекте действительно нужны очередные AbstractSingletonProxyFactoryBean. А время на разработку и поддержку этой очередной точки расширения или слоя абстракции нужно.
    
    gmtd
    16.09.2022 07:50
    #24737330
    Меру, конечно, надо знать
    
    Но очень много денег заказчики теряют именно из-за плохой изначально архитектуры, в том числе (если не в первую очередь) недостаточно гибкой и расширяемой
    
    Но это знание приходит только с опытом. У автора такого опыта, похоже, еще не было
    
    Aquahawk
    16.09.2022 08:48
    #24737474
    +8
    Мой прошлый проект длиной 5 лет был сконвертировать игру написанную на flash 11 лет назад на webgl и typescript и подсадить ей новый движок, и мы успешно выполнили эту работу, поверьте я видел много проектов со сроком поддержки 10+ лет. И нет, они не работают за счёт резиновых лестниц. Там много расширяемости там где она нужна, и там много жесткости, тоже там где она нужна. В том числе для поддержания единообразия расшинерий, чтобы их не лепили во все места какие только можно. Там много синглтонов, там много статики которая работает единственно верным образом и либо меняется в проекте раз и на всегда, тогда мы идём и правим код, либо работает как есть, и ей абсолютно вредна расширяемость. И да эти проекты работают на десятках платформ, там десятки языков, чёрт возьми с поддержкой склонений числительных и каких-то извратов с предлогами зависящими от пола в французском, локализованная графика и сюжет, всё это гибко и удобно, с софт рестартами, бексовместимостью минимум на 6 месяцев, а иногда на 3 года. Мне повезло работать уже 11й год в одной компании и я могу видеть как развиваются решения сделанные 10 лет назад. Как рождаются и умирают проекты. Код это текст, код расширяем в том числе способом переписывания. И если начать смотреть про деньги и стоимость поддержки, то весь из себя расширяемый код который через 8 генераторов конфигураций со стратегиями сконфигурирован единственным образом и работает так 5 лет, вреден. Это стоит поддержки. Новым людям гораздо понятнее был бы прямой линейный код в котором прямо написано что он делает. Я не говорю что расширяемость - плохо. Я говорю что расширяемость там где она не нужна это плохо. А искусство видеть где она нужна или нет приходит только с опытом, и не надо бояться ошибиться - перепишете. Делать расширяемым каждый чих, только потому что вы боитесь взять на себя ответственность за то что вдруг, о боже, код придётся удалить и переписать не нужно. Кстати подумалось тут, люди любят делать рефакторинги (т.е. переписывать код без изменения апи и функционала) но боятся переписать код с изменением функционала, им приятнее сделать плагинабильно и потом налепить новый плагин. А то что ушло 10 раз больше кода на одну простую херню которую будут менять хрен знает когда, это норм.
    
    gmtd
    16.09.2022 08:57
    #24737510
    Вы под расширяемостью понимаете что-то свое. Причем тут генераторы конфигураций?
    
    Для меня гибкость это когда ты с одного фреймворка можешь без особых сложностей уйти на другой (не меняя язык, естественно). Или поменять базу данных. А расширяемость - "раскидать" приложение по нескольким серверам, когда понадобится из-за возросшей нагрузки. Или так же поступить с БД. Добавление нового функционала производится легко, и т.д.
    
    Aquahawk
    16.09.2022 09:08
    #24737550
    +8
    Я расширяемость употребляю здесь как полный синоним гибкости. "Расширить" приложение по серверам называется масштабируемость. Про неё мы тут вообще не говорим.
    
    когда ты с одного фреймворка можешь без особых сложностей уйти на другой
    
    зачем? Чтобы что? Как часто вы меняете фреймворк под приложением, какие бизнес задачи это решает?
    
    Или поменять базу данных.
    
    Зачем? Любая конкретная база крута своими фишками, постгря транзакциями, работой с json и ещё кучей фишек, кликхаус способностью переваривать конские нагрузки при ограничении функционала. Хорошее приложение и архитектура выдерживающая большие нагрузки как правило будет так или иначе привязана к базе, просто потому что использует по полной её преимущества. Не, мы меняли базы под приложениями когда они нас переставали устраивать, но это было всегда сопряжено с изменениями в некоторых местах кода просто потому что с другой базой нужно по-другому работать. А если вы выберете просто пересечение функционала разных баз и будете использовать только то, что есть у всех, так получится тормозное чудище, зато базу каждый вторник менять можно. Если просто подсадите вместо постгри клик, клик офигеет.
    
    gmtd
    16.09.2022 09:32
    #24737646
    +1
    Ну вот когда вам придёт в голову / понадобится взять приложение с одного фреймворка (потому что он устарел, например) и перенести на другой, или поменять базу с реляционной на гибридную (потому что так удобней для изменившейся модели данных), вот тогда вы и задумаетесь, гибкое ли у вас приложение и насколько вам удобно всё это сделать.
    
    А пока не понадобилось - разговор беспредметный
    
    svr_91
    16.09.2022 09:59
    #24737774
    +3
    потому что он устарел, например
    
    Если фреймворк устарел, как вы перепишите на новый, не устаревший? Если новый, не устаревший фреймворк использует новые модные паттерны программирования (иначе, почему старый фреймворк устарел)
    
    Aquahawk
    16.09.2022 10:17
    #24737860
    +7
    Но почему вы закладываете в приложение возможность замены фреймвёрка и базы, а почему не закладываете возможность замены системы счисления, вдруг в мы перейдём на двенадцатиричную? А язык почему бы не поменять, потому что он устарел, например.
    
    impwx
    16.09.2022 13:58
    #24738792
    +3
    Не, увы, так не работает. Вы предлагаете заранее заложиться под нечто неизвестное — "новый фреймворк на смену старому", "новая модель данных". Как вы можете написать эффективную абстракцию поверх того, о чем вы ничего не знаете? А если знаете — зачем вам абстракция, почему сразу не использовать то что лучше и новее?
    
    gmtd
    16.09.2022 14:10
    #24738854
    Пример
    
    Vuetify - библиотека визуальных компонентов
    
    Прекрасно работала на Vue 2
    Но уже давно Vue 3, а Vuetify всё тормозит перейти на нее
    
    И те, у кого проект на Vue 2 и Vuetify не могут перейти на Vue 3
    Хотя очень сильно хотят!
    
    И они решают использовать другую библиотеку компонентов
    
    И тут вопрос - насколько они привязаны к Vuetify. Насколько в нее "встроились"
    
    Сколько её "фич" они использовали
    
    Например, обменяли ли они простой CSS на ихние стилевые атрибуты элементов
    
    Если нет - стили им портить не надо
    Если да - полностью переписывать стили придется
    
    Первый вариант - более гибкая архитектура чем второй
    
    Модная Vuetify за пару лет превратилась в оковы.Хотя по вашему казалась "лучшим и новым"
    
    impwx
    16.09.2022 15:24
    #24739640
    +4
    Как говорится, "знал бы прикуп — жил бы в Сочи".
    
    На момент, когда человек начал свой проект с Vuetify, это действительно мог быть новый и самый лучший для его целей UI-фреймворк, позволивший тогда сэкономить значительное количество времени и сил. Предугадать заранее, что его разрабы застрянут с портированием под Vue3, на тот момент было невозможно.
    
    Сделать из этого вывод, что все фреймворки зло — юношеский максимализм. Современный проект невозможно сделать, не опираясь вообще ни на кого: а вдруг сам Vue помрет, давайте писать на голом джиесе. А вдруг сам джиес помрет, давайте сразу на wasm. И так далее до бесконечности. Тем более, что некоторые фреймворки все-таки продолжают работать десятилетиями и все еще поддерживаются, как какой-нибудь jQuery или Windows Forms, поэтому проблема с устареванием некоторых обходит стороной.
    
    Короче говоря, все меняется, и код тоже должен меняться. Не нужно ставить себе невыполнимые требования и стараться заранее все предугадать. Переписывать рано или поздно приходится всем, никакого зашквара в этом нет.
    
    antonkrechetov
    16.09.2022 19:45
    #24740640
    Мой опыт разработки говорит о том, что стоит с осторожностью использовать крупные фреймворки, которые из коробки пытаются делать всё на свете. Например, для бэкэнда это может быть свои шаблонизатор, ORM, система плагинов, слой для работы с http и т.д. Когда понадобится сделать что-то более-менее нестандартное, начнутся трудности. Лучше брать более легкие узкоспециализированные популярные библиотеки и интегрировать их самим, а также предпочитать стандартные решения.
    
    Собственно, пример выше — из той же оперы: библиотека предлагает собственный, якобы очень удобный способ задания стилей взамен стандартного. То есть, пытается залезть куда-то вне сферы своей прямой ответственности.
    
    urvanov
    16.09.2022 15:42
    #24739714
    С таким же успехом мог бы и весь vue сдохнуть.
    
    w96k
    16.09.2022 17:05
    #24740056
    Изначально по задумке языка SQL, сменить базу должно быть довольно легко, если писать в рамках стандарта SQL. Но что-то пошло не так...
    
    Также довольно легко менять фреймворк и библиотеки, если их стараться не использовать. Фреймворк по факту вас в какой-то степени вендор-локают своей "гибкостью", перенести бизнес логику между фреймворками может быть не так просто, как вам кажется.
    
    >не меняя язык, естественно
    А если придумают новые модные языковые конструкции, но в вашем конкретном языке нет? Есть ли у вас возможность дополнять его синтаксис, подгонять под современные реалии (скажем придумают лучшую замену парадигмы ООП)? Скорее всего нет. Но в рамках дискуссии о PHP это не имеет смысла, так как в языке даже стандартную библиотеку без костылей переопределить нельзя, не то что добавить языковые конструкции. Говорит ли это о том, что PHP негибкий язык? Скорее да. Перестают ли из-за этого использовать этот язык? Скорее нет.
    
    usego
    16.09.2022 08:56
    #24737506
    +11
    Абсолютное большинство проектов даже не доживает до того момента, что бы поиметь проблемы с этой мифической "расширяемостью". Часто как раз из-за оверинжениринга на начальных этапах, когда надо было просто склеить из чего кто умеет прототип, прощупать бизнес модель, понять, что есть ROI и вот только на базе этого опыта лепить что-то сложнее. И я чаще видел переписывание проектов на совсем новые рельсы на модных актуальных технологиях в виде отдельных сервисов, чем "расширение" этого сложного и неподдерживаемого "расширяемого" монолита, который быстро превращается в легаси.
  1. antirek
    16.09.2022 08:34
    #24737444
    так она потому и гибкая и расширяемая, если ты можешь на ней переписать несколько раз ))
  1. toxa82
    16.09.2022 09:03
    #24737534
    +2
    Опыт показывает, как бы ты там не извращался с гибкостью и расширяемостью рано или поздно прилетит задача которая не влезет в твою гибкость и придется переписывать полностью. И такое случается примерно раз в три года.
  1. DarthVictor
    16.09.2022 10:28
    #24737922
    +4
    Гибкой и расширяемой архитектура должна быть в отношении
    
    Интерфейсов сетевого взаимодействия компонентов. Ведь даже для простого магазина у нас могут быть отдельные сервисы (часто 3rd party) для
    
    Авторизации
    
    Аналитики
    
    А/Б - тестов
    
    Логистики
    
    Обработки информации со складов и от внешних поставщиков
    
    В отношении систем хранения. Мы можем
    
    Поменять старую СУБД полностью (от появившейся необходимости нормальной работы с JSON до импортозамещения)
    
    Вынести часть данных в специализированную СУБД (для какой-нибудь аналитики)
    
    Вынести хранение в какую-то облачную систему
    
    В отношении разделения разработки и деплоя
    
    раздельный деплой компонентов, из-за разных требований к скорости разработки фич и надежности (например потребовалось в архивной системе одного банка, где блок заявок в архив меняли редко и им пользовались постоянно, а блок со стороны архива меняли часто)
    
    разделения проекта на разные репозитории и раздельная разработка (например маловажный функционал решили отдать на аутсорс)
    
    В отношении смены языка программирования / фреймворка, например из-за прекращения поддержки, либо просто потери популярности (например Delphi, Perl, AngularJS)
    
    И у каждого приложения комбинация будет своей.
    
    12rbah
    16.09.2022 12:50
    #24738500
    В отношении смены языка программирования / фреймворка, например из-за
    прекращения поддержки, либо просто потери популярности (например Delphi,
    Perl, AngularJS)
    
    Если проект не на 3000 строк, то например переход с ангуляра на вью или реакт будет довольно проблемным и затратным, т.к. у каждого фреймоврка есть свои особенности, а переписать на другой ЯП часто означает очень большие затраты, т.к. хотя они и похожи синтаксически, чаще всего на них пишут по разному, сравните яву/php/python/c++/go, более менее можно переписать только с питона на пхп(или обратно) и с c++ на го(обратное не работает). Попроще дела обстоят с микросервисами( и с некоторыми монолитами), где можно переписать кусок кода на другой язык.
1. alexzaides
  16.09.2022 12:50
  #24738498
  +2
  Есть утка. Птица, которая умеет ходить, плавать и летать. только делает она это всё как то не очень. Так и приложение, которое гибко может расширяться на любые фреймворки, языки, БД и чего тут ещё упоминали вероятно на всех них будет работать одинаково плохо.
  
  Всё хорошо на своём месте и в своё время. И тут нужно чувствовать грань, когда нужна гибкость, а когда нужно взять одну технологию и выжать из неё максимум.
  
  К сожалению, гибкость очень во многих местах стала священной коровой. "А если мы захотим поменять базу, всё должно продолжать работать". Зачем мы захотим поменять базу данных? Как часто в проектах просто так берут и меняют базы? мне ни разу такого не встречалось. Было, меняли. Но это был длительный процесс с вдумчивой доработкой кода напильником и оптимизацией запросов. процедур и триггеров под заморочки новой базы.
  1. Aquahawk
    16.09.2022 12:51
    #24738504
    Да, вы всё правильно поняли, именно эту мысль я и пытался донести.
    
    alexzaides
    16.09.2022 13:29
    #24738688
    +1
    только эту мысль, к сожалению, до очень многих очень сложно донести.
    
    Если какая то идея входит в моду, то во многих местах она начинает считаться серебряной пулей. Даже если авторы и популяризаторы этой идеи прямо пишут, что она применима не всегда, а в некоторых случаях даже вредна. Такое впечатление иногда, что куча народа читает в умных книгах только предисловие и начало первой главы, где описываются преимущества подхода. А главы, где пишут недостатки и границы применимости уже не осиливают.
    
    Лично для меня это источник непроходящей боли - в проектах бывает всплывает куча проблем из за того, что очевидное решение не соответствует очередной моде
    
    Aquahawk
    16.09.2022 13:51
    #24738782
    я разделяю вашу боль
  1. KReal
    16.09.2022 17:24
    #24740130
    +4
    Утка хорошо плавает и отлично летает, за птичку обидно!

gmtd
16.09.2022 06:54
#24737232
+7
"Почему автор - это ошибка PHP"

Не так давно искал Ларавель спеца на 250 т.р. на удалёнку, и не нашёл
Где вы?
1. serginhold
  16.09.2022 10:21
  #24737882
  +2
  Нафига тебе laravel спец? Чем не подходит symfony/yii/phalcon/любой-фреймворк спец?
  1. gmtd
    16.09.2022 11:26
    #24738174
    чтобы "спец" не тратил времени на изучение ларавельных изворотов типа sail
    
    Hett
    18.09.2022 22:30
    #24746088
    В пхп фреймворки за пару дней изучаются.
    
    kamitora Автор
    18.09.2022 23:12
    #24746182
    Так-то изучаются, да. Но чтобы пройти собеседование когда вас будут гонять по кишочкам нужно или сидеть зубрить неделями, или плотно работать от полугода. Нужно сойти за своего короче. Симфонийщики и ларавельщики друг друга не особо переваривают, а если еще фанат Yii влезет...
    
    И в этом беда - PHP-шник считает, что выучить фреймворк - это подвиг. И что его непременно нужно заучить. А не использовать документацию как справочник. И не угадаешь в чем дело - то ли для них это и правда интеллектуальный подвиг. А может быть когда человек все знает, то он может круды писать вот прямо сейчас начинать, но постойте! Если проект серьезный и большой, то эти 3 дня на въезжание в ORM фреймворка погоды не сделают. А выходит что делают, настолько длинные проекты с негорящими сроками.
    
    И главное тут в пример приводится sails, сомнительная обертка вокруг докера, artisan и nodejs, которая через версию не запускалась у меня. Вариант, что можно вести полноценную разработку на Laravel без этой параши, даже не рассматривается. А разгадка проста - к sails идет готовый буклет по дрессировке макак, включающий в себя сборку фронтенда, дебаг, деплой в облако и даже менеджмент версий php.
    
    Наверное отличный инструмент когда делает 10 сайтов с поверхностыми знаниями всего под разных заказчиков и модно деплоишь в облако. Т.е. примерный облик проектов можно представить.
1. polearnik
  16.09.2022 10:38
  #24737964
  все уже устроены.
1. zhulan0v
  16.09.2022 11:34
  #24738214
  мало денег
1. kamitora Автор
  16.09.2022 12:55
  #24738522
  +1
  Говорю же: ушел на ruby.

Tanner
16.09.2022 07:33
#24737304
-11
PHP – это шаблонизатор для Perl, написанный студентом для личного пользования, который потом некие два мошенника объявили языком программирования.

JavaScript был написан за 10 дней одним программистом-фанатом Lisp, у которого над душой при этом стояли менеджеры, следившие только за тем, чтобы у языка был модный синтаксис с фигурными скобочками.

CSS, впрочем, был спланирован и реализован комитетом, но результат получился ненамного лучше.
1. SergioShpadi
  16.09.2022 10:00
  #24737782
  +1
  И слава Богу, что автор JS был фанатом LISP - у него получилась одна из самых лучших и продуманных архитектур языков программирования, на базе которой язык развивают уже больше двадцати лет.
  1. svr_91
    16.09.2022 10:07
    #24737812
    +11
    И слава Богу, что автор C++ был фанатом C - у него получилась одна из самых лучших и продуманных архитектур языков программирования, на базе которой язык развивают уже чуть менее сорока лет.
  1. Tanner
    16.09.2022 10:22
    #24737894
    +6
    А я так полагаю, что у него получился хтонический монстр, который взял в заложники приличную долю программной индустрии.
    
    SergioShpadi
    16.09.2022 11:50
    #24738288
    +2
    Как говорил Черчиль, JavaScript - это худший язык программирования, не считая всех остальных.
    
    alcanoid
    16.09.2022 13:48
    #24738766
    +4
    Как говорил Ленин, не стоит верить цитатам из интернета.
    
    snaiper04ek
    16.09.2022 16:00
    #24739792
    Не бойтесь, моим цитатам можно верить. ©Джейсон Стетхем
    
    RH215
    16.09.2022 14:06
    #24738834
    Это случилось, в общем-то, из-то того, что его используют не так, как задумывалось.
    
    WraithOW
    16.09.2022 17:51
    #24740266
    +2
    The by-design purpose of JavaScript was to make the monkey dance when you moused over it
1. bombe
  16.09.2022 10:08
  #24737822
  +5
  Linux - это ядро GNU, замена Unix, написанное студентом, что бы пользоваться благами сети на домашнем компьютере.
1. maximw
  16.09.2022 11:23
  #24738144
  +2
  Как вам там живется в 1997? Готовитесь к проблеме 2000?

codecity
16.09.2022 07:59
#24737356
+6
По молодости ненавидел PHP. Однако же статье не хватает объективности - почему до сих пор PHP занимает место в первой десятке? Плюсы то у него тоже есть, хотя бы скорость работы и простота для небольших проектов. Взять прямого конкурента - JS и Python - попробуйте сравнить с ними, обосновать в чем PHP так уж плох. JS тоже ненавидят.
1. mivlad
  16.09.2022 08:15
  #24737382
  -3
  Скорость работы — это скорость разработки имеется в виду, надеюсь? Потому что в задачах сложнее «получить строчку из базы, заэскейпить, выдать в браузер» (где каждый шаг на самом деле не php, он тут за запятые) скорость исполнения не очень. Делал раз некую парсилку логов, скорость php показалась низковатой, переписал на C — в тридцать раз быстрее заработало. И это, насколько помню, я ещё explode'ом в php строчку разбирал, а когда из любопытства сделал как в сишном варианте побайтовый конечный автомат, всё замедлилось ещё раз в пять.
  1. nikweter
    16.09.2022 08:20
    #24737402
    А с python не сравнивали? Или JS?
    
    mivlad
    16.09.2022 08:28
    #24737430
    Нет, ещё на Go попробовал, там оказалось раза в три медленнее C.
  1. MyraJKee
    16.09.2022 08:37
    #24737456
    +4
    А на асм наверное ещё быстрее )
  1. Moraiatw
    16.09.2022 08:39
    #24737466
    +2
    Ну ясен пень, С. Еще бы с ассемблером сравнили. Надо сравнивать с Питоном, Явой, С#.
  1. SiteCenter
    16.09.2022 08:53
    #24737500
    +1
    Ну чего уж там, давайте сразу PHP с Ассемблером сравнивать по производительности, и технично не обратим внимание на тот факт, что автор комментария предлагал сравнить с прямыми конкурентами - JS и Python =) Каждый язык следует использовать для своих задач (ваш Кэп.), и PHP в задачах по типу "отдай контент пользователю по шаблону" как правило отрабатывает быстрее того же Python. Про Nodejs вообще молчу, ибо если у вас не хайлоад (т.е. в подавляющем большинстве случаев) - PHP как правило будет в разы быстрее как по скорости выполнения, так по нагрузке на железо, по скорости разработки, а также дешевле собственно в разработке. Есть прекрасная книга Игоря Симдянова и Дмитрия Котерова "PHP7 в подлиннике" - в ней хорошо раскрыт вопрос применимости языка под свои задачи, в частности сравнивается разработка на PHP и на C для клиент-серверной архитектуры.
    
    olezh
    16.09.2022 13:49
    #24738776
    -3
    Предлагаю эту прекрасную книгу отправить в печку, где ей самое место
  1. trueMoRoZ
    16.09.2022 08:54
    #24737502
    -1
    Сравнивать компилируемый язык с интерпретируемым по производительности. Эм, а что так можно было?
    
    Soo
    16.09.2022 11:52
    #24738294
    -2
    PHP, как и JS уже практически перестали быть интерпретируемыми. И нужно всегда смотреть в контексте того, где мы их применяем. И в прямоте рук применителей
  1. bombe
    16.09.2022 08:59
    #24737514
    Без примеров кода никуда. На PHP можно написать парсилку логов, которая будет кушать память как не в себя, повторяя это на каждой итерации, пока позволяют ресурсы, а можно использовать генератор и быть счастливым. Можно использовать FFI. Можно написать своё расширение на C/C++/Rust (ну просто можно, если хотите).
  1. maximw
    16.09.2022 11:24
    #24738152
    +6
    Из интерпретируемых PHP в среднем самый быстрый.
1. maximw
  16.09.2022 11:27
  #24738176
  +2
  Ну не только небольших проектов. Как раз PHP рулит на простоте разработки больших проектов. Там отлично описывается сложная и большая бизнес-логика.
  1. Hett
    18.09.2022 22:33
    #24746098
    На других языках не описывается что ли?
1. kamitora Автор
  16.09.2022 13:15
  #24738618
  +1
  По молодости ненавидел PHP.
  
  Все мы ошибаемся по молодости, ненавидя сам PHP там, где нужно ненавидеть все что идет с ним в довесок.
  
  Однако же статье не хватает объективности - почему до сих пор PHP занимает место в первой десятке? Плюсы то у него тоже есть, хотя бы скорость работы и простота для небольших проектов. Взять прямого конкурента - JS и Python - попробуйте сравнить с ними, обосновать в чем PHP так уж плох. JS тоже ненавидят.
  
  Исторически сложилось. Первый веб-ориентированый язык, что выстрелил, и не был страшной букой как perl. Та же фигня и с JS.
1. bromzh
  16.09.2022 16:47
  #24739952
  +1
  Сравнение по скорости
  1. gmtd
    16.09.2022 17:10
    #24740084
    Нормально
    
    По языкам в среднем впереди PHP, за ним Go, затем далеко где-то Node.js и Питон (Это без Java и Ко, естественно)
    
    Из распространенных PHP фреймворков впереди CodeIgniter и Yii2, остальные в 3-4+ раза медленней ( фрэймворки без swoole )

bat
16.09.2022 08:52
#24737488
+11
Всегда думал, что язык это всего лишь инструмент.
1. Aquahawk
  16.09.2022 08:55
  #24737504
  +10
  Язык это давно инструмент + комьюнити со всеми идеями, модой и отщепенцами. Нанимая людей очень хорошо удаётся почувствовать как нахождение в комьюнити определяет взгляды людей. Мало кто хочет быть несогласным с модными идеями.
  1. bat
    16.09.2022 10:26
    #24737902
    Согласен, это не только лишь сам язык. Тем не менее, технология не перестает быть инструментом, одним из многих, который нужно использовать по месту.
    
    Что касается моды. Мне кажется, как раз зрелый разработчик способен не вестись на хайп и трезво оценивать плюсы/минусы того или иного варианта.
1. dvserg
  16.09.2022 09:00
  #24737524
  +4
  В статье речь больше об комьюнити, чем о самом языке. Если нездорово сообщество, причем здесь инструмент?
  1. bombe
    16.09.2022 09:09
    #24737556
    +11
    В статье откровенный необоснованный хейт:
    
    Остальные места работы на PHP - это параши той или иной засраности, если вы работаете там даже сеньором.
    
    При чём автор, видимо работал на единственном проекте и совсем не факт, что он там видел нормальный PHP:
    
    влезть в PHP по причине жирного проекта, где я и застрял. И я много лет
    жалею об этом. В этом стэке некуда развиваться. Тут гнобят за развитие и
    критическое мышление.
    
    И если мы собираемся "разбиваться на кучки (комьюнити)", то я рад, что в "моей кучке" не будет человека, который презирает всех, только "потому что".
    
    Kengurogoff
    16.09.2022 10:22
    #24737888
    +6
    У меня то же ощущение - автор делает выводы на основе опыта работы в одном-двух проектах. Т.е. переносит недостатки конкретной конторы на всю отрасль в целом.
    
    Про рынок труда вообще огонь: "метил в район 3000-5000 $" и смотрел на собеседующего как на "петуха, который всю игру кукарекает".
    
    Ну, я работал в команде с такими людьми. Которые были вечно всем недовольны - и процесс организован не по спринтам, и встреч с обсуждениями нет, а если есть то впустую тратят время; во всех проблемах виноват или тимлид который не те задачи ставит, или девопсер который не так сервер настроил, или фронтендер который неправильно данные с бэка обрабатывает. И вообще язык гавно и архитектура ущербная.
    А при попытке обсудить эту архитектуру отвечали: "да мне пофигу что там внутри происходит и насколько правильно оно написано - я хочу побыстрее задачу закрыть, а то проект уже надоел".
    
    kamitora Автор
    16.09.2022 12:41
    #24738468
    +1
    Да, хейт. Потому что я не смогу вам донести что то что вы - это вы - это плохо. Вы такие какие вы есть. И статья о том, что если человек чужой такому коммьюнити, то лучше из него валить. Что я и сделал. Но я называю людей петухами, людьми со средним IQ не из злости, а потому что у меня нет других терминов более точно и метко описывающих их.
    
    У меня есть больше 10 компаний гдя я поработал и сотни собеседований, чтобы сделать достаточные выводы. Да, меня не было в Badoo/Facebook, но я и не говорю про сайты однодневки "Пуховики Ашота".
    
    А про засранность я понимаю весь процесс организации в целом:
    
    - чем ниже бюджеты(а в PHP они как правило ниже), тем злее и невалифицированне люди
    
    - чем больше соискателей на рынке, тем более скотское отношение к ним со стороны HR
    
    - чем меньше зависит от навыков программиста, тем больше завивисит от продажников, а значит в любой момент тебя могут выкинуть
    
    - чем сильнее у тебя печать интеллекта на собеседовании с CEO(с печатью кабаничка на лице) после 3 раундов технического собеседования, тем больше шансов, что ты зря тратил время на все 3 раунда собеседований
    
    А так да, язык всего лишь инструмент. Но ровно до тех пор пока ты не начинаешь искать на нем нормальную работу.
    
    bombe
    16.09.2022 13:39
    #24738720
    +6
    Вы гребёте всех под одну гребёнку. По Вашим словам - у меня не нормальная работа и вообще я петух со средним IQ =)
    
    Но у меня хорошая и интересная работа, хорошая зарплата, и вообще мне нравится PHP. И если Вы валите из комьюнити не сделав ничего для него, то скатертью дорога, Вас вряд ли будут ждать назад с Вашим "опытом".
    
    kamitora Автор
    16.09.2022 14:01
    #24738814
    +3
    Вы гребёте всех под одну гребёнку.
    
    И в данном случае это разумно. Считайте, что адресую эту статью себе 10 лет назад, чтобы не было места для полумер и оттенков, чтобы я понял что PHP - плохой выбор.
    
    По Вашим словам - у меня не нормальная работа
    
    Про конкретно вашу работу я ничего не знаю, может быть она у вас отличная.
    
    и вообще я петух со средним IQ =)
    
    Если бы ваш IQ был выше, вы бы наверняка пригли к выводу, что нет смысла что-то объяснять человеку написавшему, по вашему же мнению, бред в интернете. Тут одно из двух - или IQ, или вы заядлый петух-шахматист.
    
    Но у меня хорошая и интересная работа, хорошая зарплата, и вообще мне
    
    нравится PHP.
    
    А после работы вы переустанавливаете ШИНДОВС?
    
    alexzaides
    16.09.2022 14:05
    #24738830
    +4
    а что хороший выбор? Если руки кривые - то любой инструмент плох.
    
    Хотя вы правы -судя по написанному объяснять вам что либо нет смысла. Тем более если вы сами так считаете.
    
    bombe
    16.09.2022 14:19
    #24738908
    +1
    Смешно, спасибо за Ваше мнение, мне было интересно (нет) =)
    
    Я линуксом пользуюсь. Кроме PHP мне нравятся и другие языки, так что не обобщайте. Снова. Вы слишком многое себе позволяете =)
    
    TonyKentnarEarth
    16.09.2022 14:45
    #24739204
    +8
    Вижу:
    
    Но я называю людей петухами, людьми со средним IQ не из злости, а потому что у меня нет других терминов более точно и метко описывающих их
    
    Читаю как:
    
    Php-шники пидорасы, а я - Ruby-Д’Артаньян
    
    kamitora Автор
    16.09.2022 16:57
    #24740008
    -1
    Давайте сойдемся на том, что я просто покинул коммьюнити, нахождение в котором мне было некомфортно. Чего и рекомендую другим, которым в нем некомфортно, но они еще не поняли почему.
    
    А кто из нас петух наверняка знает только шахматная доска.
    
    bombe
    16.09.2022 17:05
    #24740054
    +3
    Давайте сойдемся на том, что комьюнити было даже не в курсе, что есть такой нытик, которому подсунули говно под жирным соусом.
    
    А кто из нас петух
    
    У кого что болит, тот о том и говорит. Слышали пословицу? Вас, как будто на зоне заставляли на PHP писать. При чём вообще шахматная доска? Не все на двачах зависают, извините.
  1. 2n2222
    16.09.2022 14:58
    #24739362
    В статье речь больше об комьюнити, чем о самом языке. Если нездорово сообщество, причем здесь инструмент?
    
    Автор слишком долго работал на PHP, поэтому немного притормаживает в части умения обобщать и переходить на абстрактный уровень. Я так понимаю, он хотел сказать, что комбинации средств разработки в ИТ, могут в какой-то степени определять наборы морально-этических принципов на которых будут базироваться команды разработчиков.
    
    Например, если порог входа в технологии низкий, и напряжение извилин для работы в этих технологиях доступно массам, а продукт все равно находит свою нишу, то тогда автоматически эти массы в силу инстинкта самосохранения выберут такие морально-этических принципы в которой им будет все еще более-менее комфортно, а отличающимся от них этот уровень комфортности будет неприемлем, так как они способны найти работу за пределами этой ниши.
    
    kamitora Автор
    16.09.2022 16:58
    #24740016
    Как-то так, спасибо.
1. netch80
  18.09.2022 13:51
  #24744762
  Ну вот как раз про PHP и такую позицию.

HellWalk
16.09.2022 09:19
#24737586
+7
Как человек, который работает с php с 2008 года могу сказать, что все так и есть, если иметь кругозор и критическое мышление.

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

Никому бы не порекомендовал в 22 году изучать php.
1. dvserg
  16.09.2022 15:55
  #24739774
  Я бы не согласился с Вашим утверждением. Наоборот, с PHP необходимо хотя-бы ознакомиться, чтобы понять, что Вам по душе или не по душе в языках. Очень помогает выбрать свою нишу в профессии, к чему дцша лежит больше. И далее если уж не любить, то хотя-бы уважать выбранный инструмент разработки.

s_f1
16.09.2022 09:25
#24737614
+4
Что я понял – автору не зашёл PHP.
Чего я не понял – почему автор не перешёл на Ruby после того, как понял то, что понял я, а мучился столько лет?
1. vtal007
  16.09.2022 10:41
  #24737976
  Это пост из "чудесного айти" ? :)
1. kamitora Автор
  16.09.2022 12:48
  #24738488
  Потому что была какая-никакая работа в большом количестве на PHP. Чтобы перескочить на руби не сильно теряя в зарплате нужно было хорошо так потратиться на обучение временем.
  
  Как к языку к PHP у меня претензий нет, но вот все что идет в комплекте - это капец.
  1. s_f1
    16.09.2022 15:15
    #24739576
    Но ведь в результате всё равно перешли? Вот я и не понял – зачем столько ждали? Неужели все эти 12 лет Ruby потихоньку изучали?
    
    kamitora Автор
    16.09.2022 17:57
    #24740292
    Но ведь в результате всё равно перешли? Вот я и не понял – зачем столько ждали? Неужели все эти 12 лет Ruby потихоньку изучали?
    
    Я думал, что я ошибался и в целом PHP-комьюнити лучше чем оно есть. Особенно учитывая развитие языка последних лет. Только лучше не стало - большая часть вопросов там "ай-ай-ай у меня формочка не отправляется" и ломание копий об талмуды по паттернам. Просто уже не было сил терпеть этот драмтеатр, где люди рассуждают о высоком штиле программирования в условиях когда 90% проектов на языке нужно чтобы дешево и еще вчера.
    
    Терять в зарплате не хотелось. Руби учил года 3, сделал пару сайтов, пару апи сервисов, тренировался на одноразовых скриптах, которые в хозяйстве все равно нужны.
    
    Ну и сами подумайте. Если мне нефомфортно в пыхомирке, то варианта два - либо тот, что я описал в статье, либо то что они замечательные и я им не подхожу. Так что уход в место где я со своим мировоззрением подхожу больше - это конструктивный выход с любой точки зрения.

Nelman86
16.09.2022 09:44
#24737704
+11
Ждем такую же статью про Ruby, когда у автора упадет конверсия по резюме на этот язык)))

Alexrook
16.09.2022 09:44
#24737706
+6
Я в свое время тоже пытался прорваться в сферу PHP ) Могу подтвердить, что абсолютно все интервьюеры и те, кто проверяет тестовые задания, с короной на голове. Настолько пафосных и высокомерных людей я больше нигде не встречал. И это были вакансии на 30-40 т.р.! Обычно требовали сделать CRUD приложение с нуля на Laravel или Symfony. Ты его делал, оно работало, соответствовало полностью ТЗ. Но тебе в ответ писали, что ты не учет то-то и то-то, так что пошел нафиг, хоть им и понравился твой код и бла, бла, бла. Все возражения, что в ТЗ об этом не было ни слова просто игнорировались. В этом был главный маразм - ты должен сам был додумывать ТЗ и предугадывать все возможные требования заказчика. То есть им не достаточно того, что ты день потратил на тестовое задание, им нужно, чтобы ты просидел неделю и вылизал все до мелочей. И не дай бог, если ты прикрутишь Bootstrap какой-нибудь, чтобы это все не выглядело так убого, как выглядит чистый HTML без стилей. На это сразу следовало замечание, что никто не просил тебя заниматься тем, чего в ТЗ нет. То есть в одном случае надо учитывать, чего в ТЗ нет, в другом нет. Напомню, что это вакансии на 30-40 т.р.! Для людей без опыта. То есть выходило, что просто ищут дешевую раб. силу. Иначе не понятны настолько мелочные придирки к людям без опыта. Даже если в приложении допущены некритичные ошибки, я бы даже сказал недоработки, это вполне допустимо для человека без опыта по моему мнению, особенно, когда ты ищешь человека за зарплату кассира в Пятерочке.

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

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

Заметил, что вакансии у таких компаний висят месяцами, возможно, годами, ибо есть предположение, что фраза о том, что "давайте начнем с 30 тысяч, а дальше будем смотреть по результатам" немного лживая и что такие конторы постоянно ищут людей на этот 30к и больше платить не готовы, ни через полгода, ни через год. Не буду утверждать, но сложилось именно такое впечатление по общению. Нае....вом сквозит прямо через экран монитора. Чаще всего даже на испытательный срок не готовы оформлять. А часто сразу признаются, что работа по договору ГПХ или что-нибудь в этом роде. При этом на работу надо ездить по графику. То есть налицо нарушение ТК. В общем, шарашкины конторы какие-то в большинстве своем.
1. Kengurogoff
  16.09.2022 11:26
  #24738170
  Это все-таки беды отдельных контор, и отдельных руководителей. Просто в случае с PHP они встречаются чаще - язык сильнее распространён, куча мелких проектов и массовых клиентов.
  
  Как-то делал наблюдение, что больше всего валят по теории и докапываются до деталей именно в конторах из пяти человек. Оно и понятно, им бюджет не позволяет платить большие зарплаты - вот и пытаются ценность кандидата снизить таким образом. Но тут могу быть субъективен.
  
  В общем, тут важно разделять проблемы непосредственно PHP, проблемы конкретных IT-контор, и когнитивные искажения самого работника.
1. zhulan0v
  16.09.2022 11:43
  #24738246
  +2
  Вы какое-то дно рынка описываете, оно есть в PHP, потому что он очень массовый, но на нём так же много проектов с неплохими зарплатами в районе 4-7к долларов и выше. Но туда, конечно, никто не возьмет человека, который вчера делал тестовые для вакансий за 30-40к.
  1. kamitora Автор
    16.09.2022 13:00
    #24738546
    Ой, совсем забыл про "никто не возьмет человека". В PHP-сообществе страшнючий нетворкинг, если ты в нем не участвуешь, то сразу опускаешься на дно пирамиды соискателей. Хотя принципиальной разницы в сложности проектов за 30-40 и 300-400к часто бывает что ноль. Просто у одного проекта нет денег, у другого есть. На такие жирные места, естественно, будут подтягивать своих. Потому что сложности нет и технические навыки значения не имеют.
    
    zhulan0v
    16.09.2022 14:26
    #24738948
    +5
    Не могу согласится, это какая-то абсолютизация вашего опыта или просто троллинг.
    Очевидно, проекты за 300-400к обычно имеют нагрузочку побольше, сложность домена погуще, срок жизни подольше, требования к аптайму пожестче и т.д. и т.п. Я встречал случай, когда за лендинг на тильде заплатили 2кк, но это скорее исключение.
    А на хорошие зарплаты в первую очередь смотрят на "своих" не только в PHP, это вообще везде так. Люди просто больше доверяют "рефералам" за которых кто-то поручился, чем соискателям с улицы, причем тут вообще PHP.
    
    kamitora Автор
    16.09.2022 18:16
    #24740374
    Не могу согласится, это какая-то абсолютизация вашего опыта или просто троллинг.
    
    В противном случае это будет авбсолютизация вашего опыта.
    
    Очевидно, проекты за 300-400к обычно имеют нагрузочку побольше,
    
    Правильно. И потому там есть отдельная команда девопсов, есть деньги на оборудование(если нет - земля пухом), которые парят себе мозги этим
    
    сложность домена погуще,
    
    И вы будете сидеть в команде, которая отвчает за кусочек домена, дергая другие команды в случае чего, а итоговый объем знаний будет как и небольшом проекте. На системах в сотнях классов я каждый таск забывал через неделю что я делал, потому что такой объем информации в голове не уместить, да и не нужно.
    
    срок жизни подольше,
    
    И значит у нас легаси, которое надо ковырять вилочкой
    
    требования к аптайму пожестче и т.д. и т.п.
    
    Слушайте я не понимаю при чем тут аптайм, если вы программист в большой компании, а не девопс. Ну ладно еще ведущий программист, или вас поставили дежурть на праздники. В остальных случаях аптайм программиста не касается.
    
    А на хорошие зарплаты в первую очередь смотрят на "своих" не только в PHP, это вообще везде так. Люди просто больше доверяют "рефералам" за которых кто-то поручился, чем соискателям с улицы, причем тут вообще PHP.
    
    Вы правы. Но PHP усугубляет этот эффект тем, потому что очень много соискателей с достаточными навыками. В случае пхп, если ты тимлид, то у тебя чисто из-за количества пхп-программистов больше шанс найти кого-то из знакомых, кто хочет улучшить условия. В случае руби, знакомых может не оказаться, и придется посмотреть кто там остался за забором.
    
    zhulan0v
    16.09.2022 18:56
    #24740498
    И что? Причем тут пхп? Типичный проект на любом языке ????
    
    kamitora Автор
    16.09.2022 19:05
    #24740522
    И что?
    
    И это все, что я вам хотел возразить. Если у вас нет возражений по моим возражениям, то наш с вами диалог себя исчерпал.
    
    zhulan0v
    16.09.2022 20:31
    #24740798
    -1
    Я ответил, что в вашем комменте описана типичная ситуация на проекте вне зависимости от языка, причем тут пхп вообще не ясно.
    
    kamitora Автор
    16.09.2022 20:51
    #24740904
    -3
    Да, виноват, не заметил в вас спорщика ради спора, исправляю эту досадную оплошность.
    
    zhulan0v
    16.09.2022 21:47
    #24741080
    +1
    Хорошо, одной вашей оплошностью меньше. Ещё чуть-чуть и станет совсем отлично ????
    
    Bandicoot
    16.09.2022 19:14
    #24740560
    +3
    И значит у нас легаси, которое надо ковырять вилочкой
    
    Пфф, тоже мне аргумент) Как раз-таки на легаси проектах я встречал оптимальное соотношение зарплаты и затрачиваемых усилий. Получаешь много, работаешь относительно немного, никто никуда не торопит и все всё понимают, социалка, отпуск минимум 1 месяц в год во время которого про тебя просто забывают итд. Какое-то непрофессиональное заявление, честное слово. Выбрал первый пункт в вашем первом опросе, спасибо)
    
    Легаси - это код на любом языке, который старше 5-ти минут.
    
    tommyangelo27
    16.09.2022 20:10
    #24740730
    на легаси проектах я встречал оптимальное соотношение зарплаты и затрачиваемых усилий. Получаешь много, работаешь относительно немного, никто никуда не торопит и все всё понимают
    
    Но есть и обратная сторона: поддержка легаси — это работа, которую невозможно закончить, каждый день будут новые задачи. Через пару лет начинаешь закисать.
    
    Layan
    16.09.2022 20:24
    #24740770
    поддержка легаси — это работа, которую невозможно закончить, каждый день будут новые задачи
    
    Разработка нового проекта - это работа, которую невозможно закончить, каждый день будут новые задачи.
    
    tommyangelo27
    16.09.2022 20:39
    #24740854
    Из моего субъективного опыта — обычно нет. У нового проекта есть начало, есть скоуп задач, есть запуск, после запуска период сапорта, потом новый проект. Я несколько штук запускал (и как девелопер, и как лид), и обычно оно именно так выглядело.
    
    На работе в принципе задачи будут всегда. Вопрос только в том, комфортно ли лично вам каждый день просто брать задачи из трекера и их делать, или хочется какой-то бОльшей динамики — сегодня пишем новый код, продумываем архитектуру, завтра деплоим, послезавтра правим баги.
    В моём субъективном опыте поддержка легаси обычно заключалась в исправлении багов, и редком внедрении новых фич. Кстати, встречал людей, которым исправлять баги намного интереснее, чем писать новый код, особенно если баг трудновоспроизводимый.
    
    Layan
    16.09.2022 20:50
    #24740900
    сегодня пишем новый код, продумываем архитектуру, завтра деплоим, послезавтра правим баги.
    
    Так это можно делать и на легаси проектах. Если у вас разработка проекта умирает после полугода саппорта - вам, видимо, повезло с такими работать.
    
    Я работал на проектах, первые версии которых писались за 10 лет до моего прихода. Тем не менее, проект был обновлен на самую новую версия языка, использовал современные библиотеки, подходы, да и вообще ничем не отличался от новеньких проектов, за исключением объема кода.
    
    tommyangelo27
    16.09.2022 20:55
    #24740916
    Ну это тогда не легаси-код, а живой проект. Легаси, в общепринятом понимании, это код, который работает в продакшене, но не разрабатывается активно, а только поддерживается (правятся баги, изредка добавляются новые фичи).
1. alexzaides
  16.09.2022 13:18
  #24738636
  не знаю, где вы находите такие и только такие. Я именно в этом ценовом сегменте спокойно находил подработки. При том, что я по основной специализации ни разу не ПХПшник и квалификация в PHP у меня весьма так себе. Что там творится на 7-8 килобаксов не скажу (наверное то же, что и везде - на такие зарплаты там уже не только и не столько про конкретный язык), а за денежку малую можно найти более менее адекватные требования.
1. Evgeek
  16.09.2022 14:40
  #24739104
  +1
  А «своё время» как давно было? Я проходил собесы 4 месяца назад, на 10 собесов мне предложили сделать тестовое только в двух местах, высокомерно-пафосный тон выдерживался в одном (там и оффер самый слабый оказался).
  1. alexzaides
    16.09.2022 14:46
    #24739212
    в прошлом году я с последнего проекта на PHP ушёл (поменял основную и решил на ней сосредоточиться). месяцев 8 что ли на нём отработал.. А какая разница? думаете раньше было лучше, а сейчас резко вылупились злобные начальники и стали гнобить вас ?
    
    Evgeek
    16.09.2022 15:18
    #24739598
    Это был ответ на коммент @Alexrook про сложности прохождения собесов :)
1. uhf
  16.09.2022 18:21
  #24740382
  +1
  В этом был главный маразм — ты должен сам был додумывать ТЗ и предугадывать все возможные требования заказчика
  Это не маразм, это очень востребованный в наших реалиях скилл, коррелирующий с наличием опыта. По нему, собственно, и отсеивают. А так язык/фреймворк можно выучить за пару месяцев.
1. Bandicoot
  16.09.2022 19:01
  #24740514
  +2
  В мире PHP действительно можно отхлебнуть ховна, ибо там много одноразовых проектов, много мелких заказов с фриланса итд. Но есть и другая сторона медали - хайлоад и энтерпрайз, крупные компании и долгоживущие проекты. Там уже дело обстоит ближе к миру Джавы, все серьезно, неторопливо и дорого. Работаю с пыхой уже 8-й год, зарплата перевалила за 200к и считаю, что моя жизнь в 35 лет только начинается) Выбрал пункт "Бредятина" из опроса в статье. В общей сложности прошел за свою жизнь прошел более 50 собесов на PHP разработчика, везде плюс-минус было уважительное отношение и адекватное общение. Повышайте планку, выбирайте работу в корпорациях и не работайте на мамкиных бизнесменов)
  1. kamitora Автор
    16.09.2022 19:15
    #24740564
    По поводу повышения планки и крупных компаний вопрос интересный. До войны, когда можно еще было легко устроиться в аутсорс, доллар был по 70-75, был выбор - на западную галеру за 3000-4000 $ рядовым сениором, т.е. 210 - 280 т.р. или в серьезную продуктовую компанию за 200 максимум. Все что было выше - или управленчество, или знакомства, или там был дикий финтех с хайлоадом на гошечке. Галеры же в качестве проектов предлагали типовые сайты, CRM, ERP, CMS, всякие API, где очередь сообщений нужна была скорее из-за распределенности системы, а не из-за нагрузки.
    
    zhulan0v
    16.09.2022 21:55
    #24741094
    Как раз осенью 2021 проходил много собесов, были предложения с удаленкой на МСК (не аутсорс) под 300к для пхп сеньора, их меньше, но они были и офферы вполне давались людям с улицы и никаких запредельных скиллов там не нужно было.
    
    kamitora Автор
    16.09.2022 22:29
    #24741186
    Так и на джинне вроде есть офферы 5+, только после нескольких из них складывается впечатление, что люди сами не понимают чего хотят, во всяком случае продать себя CEO на последних этапах у меня не выходило. А по ощущениям - все то же самое, что я писал выше. Куча народу, достаточного по навыкам, отбор идет уже по морде лица, софт-скилам и знаку гороскопа.
    
    Во внутренние вакансии за 300к. да еще и с улицы, да еще и на удаленку, я готов поверить, но это единичные случаи.
    
    grey_Fox
    17.09.2022 13:20
    #24742510
    +3
    
    продать себя CEO на последних этапах у меня не
    
    выходило
    
    Вот он, ключевой момент, как мне кажется. Вы написали агрессивную и хамскую статью, ноете всю дорогу и при этом сидите на php столько лет. У вас вероятно и правда есть проблемы с софт скилами, думаю любой управленец такое увидит. И задумается, зачем мне брать в команду человека, который будет вечно недоволен и зол.
    
    Если от всех воняет говном, то может это ты обосрался?!
    
    Примите взрослое и ответственное решение - переходите на ваш любимый руби и не воняйте, всем будет проще.
    
    kamitora Автор
    17.09.2022 14:08
    #24742634
    Почему вы не допускаете что писать можно в одном тоне, а разговаривать в другом? Поверьте, я бы не дошел и до 4000 если бы ирл вел себя как рассуждаю в статье.
    
    WraithOW
    17.09.2022 18:41
    #24743164
    Потому что образ мышления менять сложно и долго - если, конечно, у вас не расщепление личности. И если вы заранее считаете собеседующего говноедом, а "средний уровень интеллекта" - чем-то унизительным, то это всё равно будет сочиться.
    
    Независимо от того, зовёте вы собеседника по имени-отчеству или "петух".
    
    kamitora Автор
    17.09.2022 20:19
    #24743330
    Не нужно менять образ мышления. Есть вполне официальный деловой стиль общения и неформальный, которыми оперируют практически все люди.

izh-vii
16.09.2022 10:08
#24737818
+1
Всего лишь инструмент, либо подходящий, либо нет.

Я тоже, для довольно специфических целей, в начале карьеры выбрал пыху.
Оказалось - не то. Очень жалею, о потерянном времени.
Сам дурак.
1. alexzaides
  16.09.2022 13:21
  #24738656
  язык - это инструмент. Не бывает такого, что молоток - это плохо. Бывает, что им не удобно винтики заколачивать.
  1. netch80
    18.09.2022 13:58
    #24744788
    Берёте молоток и ужасаетесь тому, что он раздвоен с двух сторон. Он, конечно, всё ещё пригоден, я имею ввиду, что вы можете забивать гвозди серединой бойка, держась за ручку наоборот.
    
    Ну классика же.
    Или вы таки троллили?

ChessMax
16.09.2022 10:27
#24737908
+4
Есть всего два типа языков программирования: те, на которые люди всё время ругаются, и те, которые никто не использует...

Bjarne Stroustrup.

milkground
16.09.2022 10:36
#24737956
+21
Типовые вопросы на собесах по PHP - это вопросы веры и дрочки. Нужно верить в SOLID(понимать нужно также как тот кто собеседует), REST(понимание как у собеседующего).

Но все программисты на PHP, что мне попадались - люди с интеллектом дай бог чуть выше среднего, слепо верящие в догмы SOLID, patterns, GRASP(тут все настолько абстрактно, что каждый скудоум мнит себя философом-богословом, трактуя этот талмуд).

Как же хорошо от мысли, что SOLID, REST и GRASP - это проблема PHP. "Правильные" языки эта детская болячка обошла, и на "правильном" собеседовании эти вопросы стараются дипломатично обходить.

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

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

это параши той или иной засраности

шизоидный

вскукарек

главпетухом

станьте нормисом

бугуртящий

Мой совет - завязывайте с двачем - 2022 год на дворе, пора идти дальше. Я представляю уровень собеседований с вами. Не удивительно, что вы не смогли найти нормальное место работы с достойной оплатой. Язык тут вообще ни при чём.
1. vnaz
  16.09.2022 11:48
  #24738276
  +4
  чувствуется обида автора на конкретное место работы
  
  на самом деле, чувствуется обида автора природой, не более
  и можно было бы этому только посочувствовать, если бы не это его злобное и тупое кукареканье в виде статьи
1. kamitora Автор
  16.09.2022 13:11
  #24738596
  -1
  Как же хорошо от мысли, что SOLID, REST и GRASP - это проблема PHP. "Правильные" языки эта детская болячка обошла, и на "правильном" собеседовании эти вопросы стараются дипломатично обходить.
  
  В PHP - это священная корова, в других языка - нет. А знаете, почему я думаю, что так много внимания этому уделяется? Потому что в массе своей среднего PHP-шника нужно дрессировать по библии, чтобы он выдавал что-то нормальное. Потому что рефлексия на низком уровне.
  
  Сквозь весь текст чувствуется обида автора на конкретное место работы, а также травма от собеседования, которое предшествовало устройству на это
  
  место.
  
  Чувствуется ваше желание выдать желаемое за действительное.
  
  Мой совет - завязывайте с двачем - 2022 год на дворе, пора идти дальше.
  
  Да просто надеюсь, что хоть кому-то поможет не вляпаться в это на старте. Когда начинаешь карьеру, особенно как аутсорсер, PHP кажется лучшим выбором, платят все равно в несколько раз больше чем у тебя в мухосранске, работы завались. Понимание приходит чуть позже.
  
  Я представляю уровень собеседований с вами.
  
  Я вижу, что у вас богатое воображение, но боюсь, что оно ведет вас по пути желаемого, а не действительного.
  
  Не удивительно, что вы не смогли найти нормальное место работы с достойной оплатой. Язык тут вообще ни при чём.
  
  Да послушайте же, у меня было много мест работы на PHP, я их как-то находил. Но мне надоел процесс найма и люди в этом стэке. И сменив стэк, я увидел, что бывает и лучше. Об этом и статья.
  1. zhulan0v
    16.09.2022 14:34
    #24739016
    +5
    Не, статья ваша не об этом, а просто байт на комменты. Но, впрочем, вы хорошо справляетесь с этим, жаль только пользы хабру от этого мало.
  1. ShefEr
    17.09.2022 13:22
    #24742518
    +2
    Без наличия примера вашего кода на PHP, сложно отделаться от ощущения, что вы перекладываете с больной головы на здоровую
    
    bombe
    18.09.2022 21:30
    #24745952
    Есть мнение, что автор не умеет в пхп от слова "совсем". И кода не будет, просто верьте, что автор умеет)

easimonenko
16.09.2022 10:53
#24738014
+2
2 стэка

Правильно так: два стека.
1. 12rbah
  16.09.2022 12:54
  #24738520
  +6
  на какой сам сядешь ...

Vasily_Pechersky
16.09.2022 11:01
#24738052
+5
Как то Стив Джобс сказал — think different…
У меня PHP основной язык программирования, который я лучше всего знаю ( ну и обязательно JS в небольшой степени). И если подумать — я в жизни не сделал ни одного вэбсайта, но спец. программы, написанные ещё 12 лет назад — всё ещё в использовании и я их поддерживаю.

Как то не вяжется с вашими утверждениями…
Как тут сказали комментирующие — язык — всего лишь инструмент. Если вы решили работать маленьким винтиком на дядю — ваш выбор. Програмер может делать решения и их продавать — это делаю я. Ничего вам не мешает поступать так же.
1. kamitora Автор
  16.09.2022 12:53
  #24738514
  +1
  Если вы действительно умеете продавать, то язык и правда последняя проблема в вашем бизнесе. Но если сделать маленький шажочек в сторону буизнесменов с фриланса, ваяющих скрипты на PHP за мелкий прайс и *продающих* их аж паре тройке клиентов, то там трагикомедия, которую мне уже не по силам описать.

zhulan0v
16.09.2022 11:30
#24738194
+5
Когда автор не смог в пхп и застрял на рейте в 3000 usd =)
1. kamitora Автор
  16.09.2022 18:04
  #24740326
  -3
  Вообще примерно в 4000$ . Но менять работу стало очень тяжело, если приходить с улицы. Самое неприятное в этом, что я вроде бы как прохожу собеседование, и отвечаю на все вопросы, но ни ответа, ни привета, ни фидбэка. Даже когда я в конце собеседования просил быстро пройтись по ошибкам, которые я допустил. Просто я пришел к выводу, что на такие деньги программисты на PHP если и нужны, то нужны в очень малом количестве. Или что после этой планки уже отнюдь не хард-скилы влияют на вероятность найма. В руби корелляция с ответил-не ответил на вопросы и наймом выше, на мой взгляд.
  1. zhulan0v
    16.09.2022 18:42
    #24740450
    +3
    Да-да, докачался до 4к, искал работу с улицы и никуда не смог пристроится ????
    
    kamitora Автор
    16.09.2022 19:01
    #24740512
    В чем ваш вопрос?
    
    Layan
    16.09.2022 19:12
    #24740542
    +2
    Вопрос в том, что многие люди тут пишут на PHP, имеют рейты и выше 5k$, и еще и успешно меняют работу раз в год, или несколько лет. Вот у этих людей (в том числе у меня) возникает вопрос, а в чем сложность то?
    
    kamitora Автор
    16.09.2022 19:21
    #24740590
    +1
    Думаю многим было бы интересно послушать истории этих людей, насколько сильно они используют нетворкинг, из какой страны на какую работают, какую должность занимают и какой стэк используют.
    
    zhulan0v
    16.09.2022 21:45
    #24741074
    +1
    Все и так в курсе, ну кроме тех, кто желчь, хейт и обиду продуцировал вместо работы ????
    
    kamitora Автор
    16.09.2022 22:19
    #24741152
    -3
    И все равно хотелось бы конкретики. Джентельменам, конечно, принято верить на слово, но тут речь о PHP-шниках.
    
    zhulan0v
    16.09.2022 22:25
    #24741172
    +1
    Хотеть не вредно, вредно не хотеть.
    
    tendium
    17.09.2022 16:37
    #24742910
    +5
    Мой последний проект на ПХП был пару лет назад, на 6000 EUR (тогда евро был в несколько лучшей форме). Скорее всего, я получал больше любого коллеги-программиста в той конторе на тот момент.
    
    На самом деле я туда собеседовался на go, но в последний момент меня переуговорили на php. Мол, у нас надо повышать культуру и качество разработки. Я почесал репу, согласился.
    
    Проработал там год. За год избавился от некоторой части легаси. Перевел разработку на докер (что привело к если не полному, то значительному прогрессу, с решением извечной проблемы "у меня локально работает"). Сделал автотесты и автодеплой в k8s (до этого тесты никто не писал, а деплой делался ручками админом на физический сервер). Ввел стандарты разработки. Написал новый проект с нуля (который одновременно ввёл новый функционал и заменил старый совсем уж лапшевидный легаси). Перевёл пых на последнюю на тот момент релиз-версию.
    
    К концу моей работы там мне стало достаточно скучно, и я попытался получить себе немного больше полномочий и соответствующую компенсацию в организации. Увы, это не встретило понимания у техдира. На этом и распрощались.
    
    Сейчас я таки работаю на go и за значительно бóльший рейт. Но дело не в языке программирования, как вы, наверное, понимаете.
    
    Для себя какие-то мелочи я по-прежнему пишу на php, потому что на нём уже так много написано, что вместо решения каких-то фундаментальных вопросов (а-ля транспорт, форматы данных, спецификация АПИ и прочее, прочее, прочее) я могу решать исключительно свою прикладную задачу. Не то, чтобы на go всё это нельзя было написать, но кода пришлось бы написать больше.
    
    Впрочем, на go тоже кое-что пишу для себя, но по большей части это какие-то мелкие прикладные утильки.
  1. Kengurogoff
    16.09.2022 23:34
    #24741374
    Попытаюсь привести контраргументы:
    
    4000$ это неплохой уровень - на мой взгляд. Я вот шесть лет на PHP работаю, больше 60к рублей не получал. Хотя нет, это плохой пример.
    
    Собеседования тоже штука субъективная. Бывал на разных - где-то не проходил из-за недостатка опыта, а где-то прям легко и просто: вопросами не валят, улыбаются, сходу зовут работать на битриксе за те же 50к. Да блин, опять что-то не то.
    
    На должность PHP-программиста кого попало не возьмут. Вот мой одноклассник, с неоконченным высшим, дважды пытался устроится - ему не зашло, сейчас грузчиком подрабатывает и 80к получает. Это, кажется, должен был быть тезис что работать на пыхе престижно...
    
    В общем, хотел как-то конструктивно объяснить, почему я именно с этим языком работаю. Не для автора, для себя лично.
    Но, видимо, придется или согласиться с его позицией, или признать что я обычный говнокодер с IQ ниже среднего. Или все это вместе.
    
    За статью спасибо, наводит на определенные размышления. Пойду саморефлексировать.
    
    Sky4eg
    16.09.2022 23:51
    #24741404
    Вы как-то не так себя продаете. Еще в 2016 году получил несколько оферов 120к как чистый пхпшник. Возможно вам стоит поискать удаленку на мск?
    
    kamitora Автор
    17.09.2022 00:06
    #24741430
    Вы чертовски верно уловили то, о чем я уже много раз упоминал в сообщениях выше. В случае PHP ты должен себя продавать, потому что нет разницы кого взять из толпы таких же как ты. Кто лучше себя продаст, тот и победил. Но даже в СНГ, нормальные продажники всего - от машин до стройматериалов и оборудования зарабатывают сравнимо или больше программистов-аутсорщиков. Потому что продажи - это отдельный навык, очень полезный, но не имеющий ничего общего с программированием.
    
    А я выбрал вариант, когда я отвечаю на вопросы и получаю 4500 $ за то что мне нравится, не рассказывая какой я классный и повышу конверсию.
    
    И я раз за разом сталкиваюсь с искренним непониманием того, что хороший продажник это редкость, что продавать может каждый. Да, если хотите некрасивый голос уже сделает так, что у вас ничего не купит. Угрюмое лицо доставшееся генетически? Снова мимо? Нежелание врать напропалую? Следующий! Не вписались в психотип покупателя и не понимаете как он мыслит? До свидания! Выглядите недостаточно успешно? Мы вы вам перезвоним.
    
    Хороший продажник - это человек, который может продать заурядный продукт дороже чем другие. Человек, который может на вопрос "чем ты лучше 50 других программистов приславших резюме" ответить так, что нанимающему станет стыдно за свой вопрос. Хотя разницы нет. Продажи - это все про социальное взаимодействие, обман, доминирование, подмасливание и т.д. Это настолько перпендикулярно программированию, что я не понимаю людей, что на полном серьезе предъявляют программистам, что те не умеют себя продавать.
    
    Sky4eg
    17.09.2022 11:37
    #24742314
    +3
    Боюсь вы меня не совсем поняли мой посыл. Продавать надо свои знания, которые можно показать в диалоге! Нужно уметь выходить за рамки ответа "да", "нет", "какой-то кусок заученного текста перед собесом..."
    
    Из моих собесов 16 года не было ни одной конторы, которая бы вела себя неадекватно и высокомерно, а собесов было много. Я тогда только приехал в Мск и ходил на собесы каждый день по 2-3 на дню.
    
    Самый неадекватный собесе когда мне дали лист с заданием и ушли на пол часа, потом пришли забрали его и не смотря на него сказали мы перезвоним.
    
    В остальных собесах помимо общения мне запомнились совместные решения задач с техлидами, руководителями отдела после чего я получал офер не выходя с кабинета. Были и рисования на доске и алгоритмы и приславутый солид, но там не требовалась зубрежка и поклонение этому культу, а хотели услышать рассуждения, понимание предметной области, обзор кругозора!
    
    Возможно сейчас идет перегруз спецов после разных курсов и развалившихся галер на фоне СВО. Но опять же на текущей работе я провожу собеседования, в том числе и пхпшников и довольно много из них озлоблены и обладают завышенным ЧСВ на фоне опыта в 10-15 лет на пыхе считающими себя гуру языка и утверждая что он гавно, хотя их знания застряли на уровне перехода с 5 на 7 версии с явным непониманием зачем им развиваться и учить новшества языка.
    
    kamitora Автор
    16.09.2022 23:54
    #24741410
    +1
    У вас нормальный уровень зарплаты, если вы работаете в пределах РФ или питере и не хотите лезть в продажи и самопродвижение. Когда я начинал джуниором 1С мне платили баксов 100$ в середине нулевых. Локальный рынок - это дно. Если вас не устраивает текущее положение дел, не закикливайтесь на битриксе, учите Laravel - сейчас он является балансом по количеству вакансий, простоте вхождения, наличию легаси в ближайшие годы. Те же 60 к. на удаленке иметь будете. Главное помните, что то что вы узнали в битриксе и то, что узнаете в Laravel, придется через несколько лет критически переосмыслить. Поскольку оба продукта не являются примером хороших практик для построения сложных систем. Опытные пользователи Laravel со мной поспорят и будут правы с высоты своего опыта с другими фреймворками, но у вас этого опыта не будет.
    
    Sky4eg
    17.09.2022 11:41
    #24742326
    Нет это не нормальный уровень зарплаты с 6 летним опытом.

maxkain
16.09.2022 11:55
#24738308
+3
Преимущественно бред написан.

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

Проходил множество собеседований, ни разу такого не слышал.

monte1977
16.09.2022 12:01
#24738346
С автором частью согласен.

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

Если взять простой молоток. Им можно достаточно больно не умелому бить по пальцам, можно забивать гвозди, но при создании статуи Микельанджело он тоже принимал основное участие.

hlogeon
16.09.2022 12:39
#24738464
+8
Подписываюсь под каждым словом автора. Будучи ПХП-программистом я далеко не всегда с первого раза ложкой в рот попадаю.

splasher
16.09.2022 13:42
#24738738
С точки зрения программиста как наемного работника к php и Laravel, конечно, могут быть претензии. Но с точки зрения старта новых проектов Laravel - это один из лучших, мощных и высокоструктурированных инструментов для обработки запросов на стороне сервера => высокая скорость разработки и низкие затраты, плюс специалисты на рынке присутствуют. Если в приоритете вопросы не моды, а эффективности, то для этих целей оптимальный вариант (ну или один из).На мой взгляд, основная проблема php не в текущем моменте, а в перспективе, так как в спину дышит serverless, и ключевое поле деятельности для php будет плавно сокращаться...
1. bombe
  16.09.2022 13:48
  #24738770
  https://bref.sh/
  1. splasher
    16.09.2022 14:02
    #24738818
    Да, я в курсе, спасибо. IMHO эти варианты вымрут со временем, т.к. конкретно для serverless стэка есть более оптимальные решения, и новые проекты будут базироваться именно на них.
    
    bombe
    16.09.2022 14:38
    #24739060
    года два назад работал на проекте где основной бекенд это serverless Symfony + bref. Насколько мне известно - до сих пор всё работает и умирать не собирается. А хоронят много кого. Вот PHP, к примеру, уже который год.
    
    alexzaides
    16.09.2022 14:46
    #24739220
    шоб я так жил, как он умирает! :-)
    
    splasher
    16.09.2022 14:47
    #24739228
    Про работающие проекты вопросов как раз нет. Вопрос в том, какой стэк выбрать тем, кто начинает новые на serverless архитектуре. При прочих равных сейчас я бы php не выбрал для этих целей.
    
    gmtd
    16.09.2022 14:52
    #24739288
    +1
    Дался вам этот serverless...
    
    Сейчас стандарт качества веб приложений - SPA
    
    А писать API на бэкенде на PHP - одно удовольствие
    
    Фреймворк выбора - CodeIgniter
    
    splasher
    16.09.2022 15:04
    #24739444
    Дык кто-ж спорит... Прямо сейчас закончил SPA Quasar+Laravel, полностью доволен своим выбором... Но за своим серваком надо следить, это доп затраты и риски. Когда стартовал изучал возможность полного serverless, но по производительности и костам меня не устроило, хотя все развивается, и мб по другому проекту выбор уже будет другой. На полном serverless стэке я бы скорее рассматривал Node или Python...
    
    gmtd
    16.09.2022 15:07
    #24739492
    Есть отдельные задачи, которые хорошо подходят под реализацию на serverless
    
    Но не веб приложения целиком
    
    Иначе, да - дорого и заморочисто
    
    splasher
    16.09.2022 15:16
    #24739582
    Вот и я о том же, ПОКА это так. Но ситуация быстро меняется.

Ioanna
16.09.2022 13:58
#24738794
+15
Каким мерзким языком написано. Вы специально так выражаетесь, чтобы рейтинг поднять?
1. kamitora Автор
  16.09.2022 14:08
  #24738846
  -3
  Мне кажется, что данная стилистика соотвествует характеру освещаемой проблемы.
1. mapron
  17.09.2022 22:51
  #24743636
  +1
  думаю по фразе «народ принимает решение о том нравится ему специалист или нет» можно сделлать некоторые выводы. Скорее всего с автором и правда чертовски сложно работать, но фидбек он не в состоянии усвоить.
  Да, если у тебя софт скиллы на нуле, не поднимешься выше $3000 не только на PHP, но в любой другой сфере.
  1. kamitora Автор
    18.09.2022 04:59
    #24743994
    Для меня в данном случае софт скилы заключаются в "будь как мы, мысли как мы". Можно было притворяться, можно было уйти туда где не нужно притворяться. Вот собственно и весь выбор. Можно например и по-понятиям базарить так, что многих конфликтов в жизни многоуважаемых программистов, сидящих здесь, удалось бы избежать. Но, готов поспорить, они по каким-то причинам решили оставаться самими собой.

Anarchist
16.09.2022 14:21
#24738924
+4
Из наблюдений: жесткие требования к знаниям паттернов при интервью к определенной "языковой" вакансии - результат низкой средней квалификации среднего программиста на этом языке и показатель скорости превращения проекта на данном языке в помойку.

Steepik
16.09.2022 14:40
#24739112
+1
Нет плохого кода есть плохой программист :)

IvanShapa
16.09.2022 14:40
#24739122
-1
Язык лишь инструмент. (не нравится/не удобно, смени инструмент).

Да молотком наверное не удобно копать грядки.

Hawk007
16.09.2022 14:41
#24739130
+1
Я бы сказал, что у людей развивается слишком большое самомнение о себе в связи с редкими (дифицитными) профессиональными данными. И устраиваясь на работу тебя не берут( я более чем уверен), что человек себя ведет как полный мудила.
1. mapron
  17.09.2022 22:52
  #24743640
  Судя по его цитате «народ принимает решение о том нравится ему специалист или нет» в самом начале статьи у него там полный швах со софт-скиллами, так что неудивительно, что не берут.
  1. kamitora Автор
    18.09.2022 05:06
    #24743996
    Вы хотя бы допускаете, что в системе, где компетенция работников не влияет на результат, рано или поздно компетенция перестает быть критерием выбора работника и на ее место приходит что-то другое? Есть же куча исследований, где люди проявляют симпатию и антипатию на одни и те же слова, в зависимости от того, насколько красив говорящий, какой у него тембр голоса. Есть же куча ситуаций, когда выбирают по критерию лояльности, или чтобы не подсидел, или чтобы на его фоне не казаться худшим работником.

nimishin
16.09.2022 14:41
#24739136
Коллеги, вот после такого очередного собеседования, кстати, в https://www.livejournal.com/ я и ушел из perl

и перешел на java и не жалею ничуть

kadyrgulov
16.09.2022 14:42
#24739164
Странный текст с запахом нытья. Не нравится - не используй, зачем это выливать? Разные задачи у разных людей. Я предприниматель, остался без поддержки проектов из-за сво, но проекты нужны и продолжать развитие надо, решил освоить php чем собственно и занимаюсь, если я решу что язык не будет удовлетворять мои потребностям - изучу чтото новое, странный нытик.

Googlebit
16.09.2022 14:43
#24739170
+1
Думаю, любой язык и любая работа будет ошибкой, если не наслаждаться процессом и не гордиться результатом. Я вот тоже пробовал рвануть в айти как PHP программист. И тоже или игнор, или просто отказ. За все время было одно тех задание, которое я с треском провалил. Не оптимизировано по времени и вместо массиво вывел html.

Проще говоря, провалил.

Что сделал я? Создал сайт на PHP и Laravel. Так себе сайтик, но решил буду с ним работать. Переделаю его полностью, реализую свою идею на lava, рпскручу и буду зарабатывать огромные деньги. ))) И все. Для рынка it программистов я потерян, как наемный работник. Так и что, мне теперь лить грязь на все сообщество? Что ты, автор, можешь показать из своей работы? Не, работа над изменением чьего то кода или работа над кнопкой в огромном проекте, меня не интересует. Предъявляет претензии - докажи, что имеешь право предъявлять эти самые претензии. Нет? Извинись.

P.s. я до сих пор считаю, что PHP это лучший шаблонизатор для веб, а JavaScript зло. Скучно было чиоать, но зачем то написал коммент.
1. kamitora Автор
  16.09.2022 16:34
  #24739902
  Согласен с вами. Но помимо работы программиста, собственно архитектуры, тестов, написания кодов, которые приятны, где есть где разгуляться, есть и неприятные вещи. PHP в виду низких бюджетов, большого числа соискателей, простоты проектов, собирает полное булшит бинго в плане неумных коллег, херочек-принцесс. И конечно сферического в вакууме Ашота-продаца-пуховиков, который не позволит какому-то очкастому умнику обмануть его в оценке сроков.
  1. Layan
    16.09.2022 19:13
    #24740550
    HP в виду низких бюджетов, большого числа соискателей, простоты проектов, собирает полное булшит бинго в плане неумных коллег, херочек-принцесс.
    
    Видимо вы и выбирали такие проекты. А кто-то пошел в enterprise, где разработка на PHP и Java отличается примерно никак.
    
    kamitora Автор
    16.09.2022 19:25
    #24740600
    Зарплатой отличается. И опять же, таких вакансий на фоне общего количества PHP вакансий - капля в море. И все хотят попасть туда. И у очень многих людей хватает хард навыков попасть туда. Поэтому ПРОСТО взять и попасть в энтерпрайз, да еще и на нормальную зарплату это не так просто.
    
    1Tiger1
    16.09.2022 20:46
    #24740886
    да не сложно это. а какая зарплата вам нужна?
    
    zhulan0v
    16.09.2022 21:58
    #24741106
    да ничего ему не надо, это просто пятничный тролль байтит хабр на комменты
    
    kamitora Автор
    16.09.2022 22:36
    #24741192
    4500$, которая меня сейчас устраивает. Да, я мог ее получить на PHP, но я как-то уже устался усираться каждый раз когда приходится менять работу в этом стэке. И это именно что сложно.
    
    1Tiger1
    17.09.2022 03:03
    #24741728
    +2
    странно, на 5к для синьора я особых проблем не наблюдал. этой весной искал работу.

GoForBroke
16.09.2022 14:53
#24739300
-6
Полностью поддерживаю автора.
РНР не про технологии. РНР про то как транслировать ТЗ в код с минимальными затратами. И когда работаешь над проектом, все силы уходят не на развитие продукта, а на максимальное напихивание свистелок в слоя приложения (ОРМы и прочее), чтобы клепать CRUD-ы с ошеломляющей скоростью. Сущность! Create! Read! Update! Delete! Контроллер! 4 тыс методов чтения данных, 2,5 тыс методов добавления данных. Слепок над БД, который существует только потому, что фронт не может постучать в БД напрямую. Ай маладэц! Дай бох одна крон-джоба чтоб пулить какую-то инфу.
1. Layan
  16.09.2022 19:16
  #24740570
  +1
  То есть вы в своей жизни видели проекты, где максимум одна крон джоба и возмущаетесь, что язык не технологичный? Так извините, никто вас не будет знакомить с тысячами проектов, где есть и сложная бизнес-логика, и очень сложная инфраструктура. Ну какие крон-джобы чтобы пулить инфу? Для этого уже сто лет применяются очереди, а уж если что-то происходит по расписанию - применяется что-то вроде Kubernetes Scheduler
  1. GoForBroke
    16.09.2022 20:55
    #24740912
    На одну компанию, где есть кубер, приходит 40-50 компаний, где очереди это как раз из той же оперы, о чем написал автор - не усложняй проект, нам сложно будет найти разрабов за еду. Плюс под пуллом данный я имею виду сошкребание инфы из сгенерированного XML файла, который другая команда тоже генерит по крону и она костями ляжет, чтоб ты не добавил очереди.
    В 2018 я был на собесе, где мне сказали "только надеемся ты без хипстоты всякой кодишь?". Я подумал опять свидетели анти-кубера. Оказалось под хипстотой они в виду ООП! Контора делает CRM. Сейчас я в компании, где все есть РНР и все делают (не я) по канону. Но это первое место за 12 лет и 9 мест работы. Все предыдущие - как я описывал выше.
    
    1Tiger1
    16.09.2022 20:57
    #24740924
    да, вам однозначно нужно повышать умение собесов. вы знали что на собесе кандидат тоже может задавать вопросы?
    
    kamitora Автор
    16.09.2022 21:17
    #24740994
    -1
    А кто вам сказал, что он на них получит правдивые ответы?
    
    Вы описываете сейчас ситуацию когда кому-то позарез нужен специалист по цене ниже рынка. Тогда ему и на вопросы ответят, и даже посетуют что не все хорошо, но вы сможете поменять. А когда вы по рынку или выше берете зарплату, то скорее всего будете соглашаться на то что дадут. Если конечно у вас прохождение интервью не хобби.
    
    В смысле вы можете сколько угодно задавать вопросы - это просто еще сильнее сузит круг вакансий до тех где самая высокая конкуренция.
    
    1Tiger1
    17.09.2022 03:11
    #24741734
    +2
    мой опыт мне это сказал. все 18 лет. десятки собесов на которых был кандидатом. десятки собесов которых провел. если это действительно реально а не просто тролинг, мне вас искренне жаль, у вас сформировалось мышление что все кругом хотят вас обмануть и использовать. возможно вам не повезло с компаниями, возможно дело в вас. Я бы посоветовал перерыв месяца на 3 минимум. ну и психотерапевта если есть хороший.
    
    Я лично всегда общаюсь на собесе. врать там смысла нет ни одной из сторон, потому что это быстро вскроется и только зря потеряем время и деньги. и понятия не имею при чем тут ниже рынка и зп вообще.
1. 1Tiger1
  16.09.2022 20:55
  #24740914
  тяжёлая у вас жизнь. может проекты нужно нормальные выбирать?

koreychenko
16.09.2022 14:55
#24739324
+9
Да норм вброс для пятницы, что вы так серьёзно!
Автор годный тролль. Канон соблюдён на пять с плюсом. Взял самый популярный язык, про который есть "определенное мнение" и давай обсирать со всех сторон.
А то, что автор еще и рубист никто не заметил, да? :-) Они обычно обсирают всё, что не руби. И пофиг, что на руби пишет полтора человека в мире и хайп прошел лет 5 назад. Так что тут тоже прям 10 из 10 за соответствие.

Yalagin
16.09.2022 14:58
#24739366
+1
хз работаю на symfony лет 6, года 3 назад пересел на на api-platform и жизнь стала проще. Не надо писать бесконечные ввод-вывод данных с базы: написал сущности, повесил сериалайзер и группы для защиты данных, и все готово. Я не думаю, что есть где-то проще и быстрее и в то же время качественнее, чем на php разработка бекенда для приложений. Бизнес платит за часы разработки, если разработчик тратит меньше часов - у бизнеса появляется конкурентное преимущество перед более медленными в написании кода языками. Если бизнес выиграет по фичам конкурентов и в скорости написания фич - повышается ценник в час у программиста, поэтому пыха все еще будет жить, ценник на нее будет высокий. Главное - найти компанию, которая выстрелила или приложить усилия к развитию продукта. Php, по-моему, язык стартапов, а у стартапов по сравнению с enterprise меньше денег, поэтому получаем такие собеседования и условия труда. Но сам я, конечно, перешел на react next's, потому что я слишком быстро стал делать бэкенд и там зп лучше =)
1. kamitora Автор
  16.09.2022 17:06
  #24740064
  Бизнес платит за часы разработки, если разработчик тратит меньше часов - у бизнеса появляется конкурентное преимущество перед более медленными в написании кода языками. Если бизнес выиграет по фичам конкурентов и в скорости написания фич - повышается ценник в час у программиста, поэтому пыха все еще будет жить, ценник на нее будет высокий.
  
  Нет, это значит что с вам будут требовать больше фич в час. А если вам что-то не нравится - под забором еще толпа людей, которые умеют расставлять аннотации в апи платформ. Во всяком случа ставка PHP на том же upwork не самая высокая.
  
  Главное - найти компанию, которая выстрелила или приложить усилия к развитию продукта.
  
  Ресь о том, что это сделать очень тяжело в среде PHP. Во-первых придется перебрать тонны шлака, во-вторых пробиться сквозь сотни достаточных по навыкам конкурентов.

viktorart
16.09.2022 15:02
#24739412
«где пышным цветом цветут самые мразотные социальные явления.»

похоже что нужно продолжение статьи...

1Tiger1
16.09.2022 15:32
#24739678
+3
годный троль, одобряю. с душой подошёл, с эмоциями. жива ещё школа старого троллинга и холивара. Да будет его величество Срач!

xRay
16.09.2022 15:52
#24739754
+2
С PHP, Ruby завязывайте и переходите на COBOL т.к. там з.п. гораздо выше, а легаси давностью уходит в «вы еще не родились». COBOL настолько востребован, что программисты на нём обеспечены работой даже после выхода на пенсию.

amarao
16.09.2022 16:24
#24739872
+1
Ого. Я от php настолько далёк насколько могу, но такая лексика (даже малая её часть) на собеседовании напрягла бы, и я бы дал негативный фидбэк по софтскиллам.
1. kamitora Автор
  16.09.2022 16:28
  #24739882
  -1
  А вам не приходило в голову, что в рамках собеседования можно общаться по-другому? Возможно вы не так далеки от PHP, как вам кажется.
  1. amarao
    16.09.2022 16:34
    #24739906
    Приходило. Мой комментарий учитывал это. Моя далёкость от php объясняется просто - я на нём не умею ни читать, ни писать.

ReDev1L
16.09.2022 17:16
#24740092
+3
Хороший развлекательный текст) но выводы и размышления - такое себе)

С PHP 10+ лет. У php сейчас золотой век. Лучший язык для mvp с лайфтаймом 1-3 года.

Реальная помойка - это JS без TS.

joffer
16.09.2022 17:36
#24740192
+2
забавная статья

такое ощущение, что автора допекло php-комьюнити, при этом, судя по комментариям и обсуждениям, представителем этого токсичного комьюнити в основном только он и является)

что до якобы повышенной адекватности в Ruby-based проектах и компаниях - есть теория, что чем более узконаправленный и непопулярный проект, куда сильно нужны люди, тем скрупулёзнее и внимательнее рекрутёры из таких компаний готовы рассматривать потенциальных кандидатов. И наоборот - когда на "junior QA" или там "junior React", "junior Laravel" на одну вакансию присылают по 100 резюме, то можно и половину присланных резюме сразу выбрасывать в мусорное ведро с объяснением "нам не нужны неудачники".

что до собеседований - это же хорошо, когда сразу попадаются "маркеры" глупой компании. На глупом собеседовании у вас спрашивают, сколько методов работы с массивами вы помните наизусть - на умном собеседовании - сколько из них вы ясно понимаете, как они под капотом работают, можете ли объяснить это другим людям (проверка на возможного тим-лида/сениора/ментора) и можете ли реализовать вариации таких методов для каких-то специфических задач.
1. kamitora Автор
  16.09.2022 17:47
  #24740254
  А что плохого в том чтобы уйти в компанию где к людям хорошо относятся?
  1. Tatikoma
    16.09.2022 18:33
    #24740426
    Вы что, коллектив хотите бросить? А на кого по-вашему лягут обязанности? /sarcasm
  1. IvaYan
    16.09.2022 20:24
    #24740774
    То, что от вас будут тоже ожидать человеческого отношения к людям. А судя по вашему тексту -- это не ваше.

ronher
16.09.2022 18:14
#24740362
Слишком много негатива в тексте. Я бывший пхпшник. Если отбросить эмоции автора, и выделить конструктив, то я со многим согласен. Например проходя собеседование на go программиста, я ни разу не слышал глупые вопросы из разряда - как называется какая-то функция в таком-то фреймворке.

jacob1237
16.09.2022 19:17
#24740572
Интересная критика! Однако, касается ли ситуация с собеседованиями зарубежного сегмента (к примеру, США), или описанный опыт исключительно в рамках СНГ?
1. kamitora Автор
  16.09.2022 19:28
  #24740608
  Djinni, odesk, hh.ru

grigoryvp
17.09.2022 10:08
#24742070
Я только что закончил съемки RubyRussia и мне очень-очень интересно, какая именно команда рубистов из Днепра имеется в виду?

vshemarov
17.09.2022 10:18
#24742104
+6
Вброс на вентилятор засчитан. Если принять все описанное за чистую монету, то можно сделать вывод, что, автор так и не смог найти нормальной работы ни на PHP, ни на Ruby, автор получал "фидбэки", но не получил работу (иначе не было б такой статьи, или она была бы совсем другой). Может, тогда проблема не в языках?
1. kamitora Автор
  17.09.2022 14:02
  #24742610
  -2
  Так я же и говорю - не в языке, а в том, что с ним тесно связано.

poimtsev
17.09.2022 16:05
#24742862
Если ты любишь ruby, то посмотри в сторону Elixir и Phoenix framework - думаю, что тебе зайдёт. Синтаксис как у руби(что не удивительно - поскольку Jose Valim бывший участник rails core team), скорость как у эрланга(что также не удивительно)

vitiok78
18.09.2022 15:23
#24745004
Автору просто не повезло.

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

На самом же деле PHP последнее время очень стремительно развивается, фреймворки очень приятны в работе, инструментарий развит так же сильно, как у Python и JavaScript. Мне, например, нравится, что я за час могу собрать полнофункциональный REST API с полнофункциональной интерактивной документацией при помощи Symfony и API platform, а потом развивать его. Это позволяет нашей команде очень быстро вводить новые фичи в проект.

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

Почему PHP — это моя ошибка +11

Комментарии (284)

kamitora Автор

kamitora Автор

kamitora Автор

kamitora Автор

kamitora Автор

kamitora Автор

kamitora Автор

kamitora Автор

kamitora Автор

kamitora Автор

kamitora Автор