Comments 338
это вопросы веры и дрочки. Нужно верить в SOLID(понимать нужно также как тот кто собеседует), REST(понимание как у собеседующего). Нужно задрочить именно определенную версию фреймворка.
слепо верящие в догмы SOLID, patterns, GRASP(тут все настолько абстрактно, что каждый скудоум мнит себя философом-богословом, трактуя этот талмуд). Конечно, нужно задрочить фреймворк
Ох как же это в точку... но не только про php. Я не буду называть технологию, не общепринят сейчас такой взгляд. Тот же js не отличается молитвами на паттерны, в нём всё ещё слишком мало корпоратов. Как Typescript избежал тлетворного влияния шарпов мне не известно, но он отлично с этим справился.
Мой ответ в голосовании: в некоторых местах то же самое, но не везде.
Паттерны не зависят от языка. Если Вы будете делать условный наблюдатель или фабрику - то это совсем не про язык. То же можно сказать и про SOLID, GRASP, DDD, и прочие модные словечки. Вот к примеру, инверсия зависимостей. Если программист понимает, зачем оно, то ему не составит проблем использовать этот паттерн а большинстве языков. А если нет - то на любом языке будет костылить, пока не поймёт.
Лично я PHP программист. Мое мнение - человек просто сдался. Не язык помойка, а автор слабак =)
С автором во многом согласен, но я сдался тоже… когда попробовал Go и обнаружил, что многие боли php там решены на уровне языка и об них можно просто забыть. Сдашься тут, когда столько лет учишься ходить в одном ботинке и вдруг обнаруживаешь, что можно надеть второй.
Например? Какие боли у PHP по Вашему мнению? Нет асинхронности и корутин из коробки? Но в целом же есть (и асинхронность, и файберы, и множество библиотек добавляющих функционал). Я не пробовал го, мне нечего сказать о его плюсах/минусах. Я только знаю, что там нет нормальной обработки ошибок/исключений, и это для меня огромный dealbreaker.
Для меня это, пожалуй, в первую очередь строгая типизация. Очень уж нравится, когда по сигнатуре сразу видно, что туда надо передавать, допустим, массив интов.
Асинхронность и ко/горутины в общем-то и не каждый день нужны, но когда нужны — здорово, если они есть. Делал на Go одну штуку, куда клиенты приходят за неким расчётом, и если он первый в очереди и расчёт укладывается в таймаут, то клиент получает результат в рамках этого же запроса, иначе возвращается ответ «приходите позже». На Go эта логика в экрана полтора влезает, на PHP же как такое сделать, я даже и не представляю (может быть и можно, но надо крепко подумать).
А еще на нем можно просто взять, и начать писать код вместо выдумывания очередного слоя абсьракции
За абсЬракцию, извините. Опечатался
Хотел бы попросить минусующих прокомментировать в чем я не прав. Ведь в go система типов стимулирует сначала писать код, а затем, где это необходимо использовать абстракции на стороне потребителя данного кода. В php все наоборот так как система типов требует реализовать интерфейс явно
Не стимулирует вообще. Dependency Inversion можно делать везде, где есть "интерфейсы".
В PHP просто нет утиной типизации, но вам никто не мешает сначала писать интерфейсы, использовать и только потом их имплементировать. Но если совсем надо, то можно просто не указывать у аргументов тип вообще.
В Go точно так же мы можем просто указывать тип структуры, а не интерфейса, никакой стимуляции нет.
Вы меня наверное не верно поняли. Представим ситуацию что вы используете внешний пакет. В нем нет интерфейсов вообще. Вы можете его использовать в своем коде и при этом спокойно написать к нему интерфейсы и замокать его. В php весь уровень абстракции нужно закладывать на этапе проектирования внешнего пакета, и вы на это не можете повлиять из вне.
В том то и речь что в go мы используем тип структуры пока не понадобится ввести абстракцию. При этом можем это делать для кода от которого мы зависим но не можем изменить
В PHP есть строгая типизация (strict_types), правда нет дженериков (которые можно указать в аннотациях). Есть type hint, return type. Есть статические анализаторы phpstan/psalm/phan. В общем, язык сам по себе может обеспечить явную строгую типизацию, имея даже специальное исключение TypeError.
Асинхронность и корутины можно добавить, но если нужен воркер - то тут очевидно лучше выбрать golang, хотя и на PHP всё возможно сделать: файберы, ReactPHP, разные реализации серверов, типа RoadRunner, swoole, в общем - выбор имеется.
То что Вы описали - вечно крутящийся воркер. Да, на PHP тоже такое можно. И, например, прикрутить еще Temporal. да, не просто всё, но можно =)
В целом хочется добавить, что у PHP есть своя ниша. Я считаю, что PHP - хороший язык программирования, который хоть и не идеален, но лично мне нравится таким, какой он есть =)
Про strict_types знаю, массив интов как описать? :-)
Эмм: int[]
Так не работает) по крайней мере средствами языка
Средствами языка — да.
Но есть Psalm и PHPStan, там даже дженерики сейчас можно описать с помощью аннотаций в PHPDoc, это уже нативно поддерживается IDE, устанавливается и настраивается локально и в CI за полчаса.
Я согласен с комментом выше про "автор слабак".
Я в PHP почти 10 лет и это хороший инструмент, если его использовать правильно.
Да, я также иногда пишу код на TypeScript и Go. Да, есть что-то в этих языках, что мне нравится больше, чем в PHP, но есть разные задачи, а ЯП — инструмент и его нужно использовать правильно.
Как писал товарищ @bombe, есть ещё и Temporal, например, где вы можете вдоволь попрограммировать на том же Go в своём PHP-приложении, если очень хочется или того требует задача.
В докблок. И использовать статический анализатор. Он не пропустит ничего, кроме int, иначе выдаст ошибку. Да, не совсем то, что ожидалось, но массив int на самом деле редко передаётся. Скорее это будет коллекция по интерфейсу коллекции. И, на самом деле, докблок для типизации редко используется, но бывает, как вот этот конкретный случай. Как минимум, Вы точно не сможете вызвать эту функцию с аргументом, отличным от массива. А то что там инты - берёт на себя анализатор.
<?php
declare(strict_types=1);
/** @param int[] $integers */
function doSomethingWithIntegers(array $integeres): void
{
}
Вот, без внешних подпорок сам язык не позволяет. И если мы делаем библиотеку для использования неограниченным кругом лиц, то вопрос об использовании коллекции начинает уже слегка выходить в моральную плоскость. Ну да, хоть про докблоки более-менее все договорились.
Как я говорил, такая типизация в докблоке - редкое явление. Это скорее индикатор того, что можно сделать лучше.
Позволяет
function doSomethingWithIntegers(int ...$integers): void
{
var_dump($integers);
}
doSomethingWithIntegers(1, 2, 3);
doSomethingWithIntegers(...[4, 5, 6]);
Кстати да. Отличный пример, спасибо, я как-то даже не подумал. У PHP, на самом деле, очень много крутых фич подъехало с 8.0/8.1.
Судя по-всему, это vararg
, тем забавнее на самом деле - чтобы решить проблему отсутствия дженериков вы на вход принимаете не массив, а набор объектов. Стоит понимать, что это костыль, а не решение, потому что я (если я правильно понял) не смогу сделать класс на базе дженерика и передать его с сохранением этого дженерика. Также, как я не могу передать массив объектов со своими дженериками.
P. S. Поправьте меня, если я в чем-то не прав
Это variadic, и integers
будет именно массивом int. Аргументом функции нельзя будет передать что-либо кроме int.
не смогу сделать класс на базе дженерика и передать его с сохранением этого дженерика
можете пример на другом языке, что именно Вы хотите? В PHP нет дженериков, выкручиваемся как можем =)
Это variadic, и integers будет именно массивом int. Аргументом функции нельзя будет передать что-либо кроме int.
Да, я это и имел ввиду :) фактически это костыль :)
можете пример на другом языке, что именно Вы хотите? В PHP нет дженериков, выкручиваемся как можем =)
class Sample<T> {
T someData;
}
function someFun(input: Array<Sample<String>>)
В примере выше у нас будет класс Sample
с дженериком T
. Когда мы знаем, что класс Sample
имеет своим дженериком String
- мы знаем, что его поле someData
- это String
и ничто иное
Нет, именно так, вроде нельзя. Но с другой стороны, я смогу создать SampleInterface
, унаследовать нужные T
от интерфейса, и использовать их:
<?php
interface SampleInterface {}
final class SampleString implements SampleInterface {}
function someFun(SampleInterface ...$samples) {}
function someFunString(SampleString ...$stringSamples) {}
Можно быть точно уверенным, что там именно массив элементов, наследующих SampleInterface
(someFun) или SampleString
(someFunString). В данном случае PHP более "многословен", но вроде как решает задачу. При чём someFunString
в принципе и не нужно, если Вам не нужна специфическая реализация. Возможно есть способ и получше. Можно передавать как массив. Тогда нужен докблок (для указания типа элементов) и, возможно, проверка. Костыли, да. Но ведь можно хоть немного абстрагироваться.
Можно и так, но на каждый тип не создашь :)
Практика показывает, что когда возникает подобная необходимость, то там не так уж и много наследников получается, да и поддерживать все-все возможные типы не так уж и нужно.
Справедливости ради, у вас два пути - либо использовать костыли вроде variadic (которые не везде получится использовать), либо уповать на то, что статические анализаторы всех спасут. Оба варианта являются костылями и не решают проблему отсутствия обобщений до конца
А variadic и не нужен. Это как пример. Вариантов, на самом деле достаточно. Можно как аргумент передать коллекцию, в которой все элементы гарантированно будут типизированы. Можно передать простой массив и проверять instance of элемента (или использовать статический анализ). А можно просто вызвать someFun на всех элементах массива, что тоже избавляет от необходимости иметь такой дженерик.
Но в целом Вы правы. Иногда не хватает подобного функционала, но с этим жить можно =)
Да, так нельзя, но нас спасают статические анализаторы:
/**
* @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)]);
Это статический анализ, а не фича языка :) хорошо, если такой анализ во время билда/запуска работает, а если только в редакторе кода - ну, ок, как костыль пойдет
По хорошему такой анализ всегда добавляется в CI =)
То, что вы называете фичей языка - статический анализатор компилятора. Та же хрень, только у в PHP это отдельно статический анализатор и интерпретатор.
И спасибо, что напомнили еще и про это - из-за него разработка на PHP сейчас настолько IDE-oriented, что на человека без PHP Storm косо смотрят.
предлагаете вернуться в far/mc/..? брр...
Погодите, как Psalm связан с PHPStorm?
Я хочу донести мысль, что PHP для проверки типов излишне полагается на внешние инструменты. Наиболее частым из них явяляется PHPStorm. А так да, есть psalm и phpstan и codesniffer, но большая часть сидит в пыхосторме.
Это кстати еще одна вещь, от которой у меня дичайше горело - мой форкфлоу на работе включал в себя vscode + phpstan + phpmd. Остальная команда считала, что я страдаю херней, а нормальные люди должны использовать PHPStorm. Ну удобнее мне один раз перед коммитом все прогнать и починить, не отвлекаясь на подсвечивания все время. Производительность была одинаковая, но за мной стойко ходили слухи, что я не осилил IDE.
А так да, есть psalm и phpstan и codesniffer, но большая часть сидит в пыхосторме.
То, что есть PHPStorm умеет интегрироваться с данными инструментами, это типа что-то плохое?
Производительность была одинаковая, но за мной стойко ходили слухи, что я не осилил IDE.
Это бессмысленные холивары. Если вам удобно работать в VSCode, работайте там.
Тем не менее у постоянной подсветки недочетов и ошибок есть один, на мой взгляд, плюс. Он корректирует стиль кодинга. В конечном итоге линтеры и статик-анализаторы всё меньше будут ловить недостатков в вашем коде. А значит вы будете по итогу чуть быстрее работать. Но на это нужно время. Сразу ничего не бывает.
Лично я пользуюсь продукцией JetBrains просто потому, что там удобнее делать рефакторинг, лучше сделана индексация кода и, соответственно, навигация по коду получается быстрее. Но тут действительно нужно освоить предлагаемый функционал. Иначе разницы между VSCode и PHPStorm действительно не будет заметно.
То, что есть PHPStorm умеет интегрироваться с данными инструментами, это типа
что-то плохое?
Вы же сами пишете ниже, что PHPStorm имеет собственный линтер показывающий нечто, что не под силам этим инструментам. Да, я считаю плохо, когда коммерческая компания диктует де-факто стандарт как должен писаться код на языке, к которому она не имеет никакого отношения. Особенно умиляет, что половина народу в СНГ сидит на самых крутых версиях с торрентов. Прямо ностальгия по временам Delfi 7.
Это бессмысленные холивары. Если вам удобно работать в VSCode, работайте там. Тем не менее у постоянной подсветки недочетов и ошибок есть один, на мой взгляд, плюс. Он корректирует стиль кодинга. В конечном итоге линтеры и статик-анализаторы всё меньше будут ловить недостатков в вашем коде. А значит вы будете по итогу чуть быстрее работать. Но на это нужно время. Сразу ничего не бывает.
И тем не менее вы неявно намекаете, что PHPStorm лучший вариант. И вот такие намеки я слышал постоянно. И даже в тех конторах где был код-стандарт, и я и мои коллеги ему соответствовали, используя разные инструменты. Но все равно постоянно чувствуется давление, если ты не используешь PHPStorm. Выбиваешься из коллектива. Короче обычная ксенофобия и страх, что твой выбор не самый лучший и желание навязать его всем.
Лично я пользуюсь продукцией JetBrains просто потому, что там удобнее делать рефакторинг, лучше сделана индексация кода и, соответственно, навигация по коду получается быстрее.
И поэтому только для рефакторингов я его и использую, потому что, увы, альтернатив нет. Навигацию можно сделать хоть через LSP, хоть через ctags.
Но тут действительно нужно освоить предлагаемый функционал. Иначе разницы между VSCode и PHPStorm действительно не будет заметно.
Любой редактор кода типа vim, emacs, vscode и даже PHPStorm нужно осваивать. И ввиду разрозненности инструментов из которых приходится собирать себе IDE из редактора, степень освоения там будет повыше, чем в PHPStorm. Единственное чем кардинально отличается вся линейка JIdea-based IDE, так это тем, что там есть нормальный API для индексатора и рефакторинга. Но за кучу лет я припомню только один раз когда мне это пригодилось. И то по затраченному времени, возможно, codemod был эффективней.
Вы же сами пишете ниже, что PHPStorm имеет собственный линтер показывающий нечто, что не под силам этим инструментам.
Где я это написал?
Да, я считаю плохо, когда коммерческая компания диктует де-факто стандарт как должен писаться код на языке, к которому она не имеет никакого отношения.
Откуда такой вывод? Стандарты определяют мейнтейнеры проекта (ну или не определяют и пишут кто как попало). PHPStorm лишь помогает придерживаться тех стандартов, которые определены в проекте.
Да, PHPStorm может подсказывать по коду что-то сверх настроенных линтеров (хотя я об этом не писал), но
- во-первых, это отключаемо,
- во-вторых, программист волен им следовать или не следовать,
- в-третьих, JetBrains "немного" имеет к PHP отношение — погуглите кто такой Никита Попов (Никита, правда, уже не работает в JetBrains, но его вклад в развитие php непереоценим).
И уж точно в дополнительных подсказках от IDE нет никакого криминала.
И тем не менее вы неявно намекаете, что PHPStorm лучший вариант.
Для меня — да. Но для вас может быть по-другому. Это нормально. Свобода выбора и всё такое.
Если бы мы работали удаленно в одной команде, я бы, возможно, так и не узнал, какой IDE вы пользуетесь. Вот у меня сейчас в команде 5 человек. Я понятия не имею, кто из них каким IDE пользуется. Зачем мне это знать?
Где я это написал?
Он корректирует стиль кодинга. В конечном итоге линтеры и статик-анализаторы всё меньше будут ловить недостатков в вашем коде.
Извините, я вас неправильно понял. Думал, вы имели 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. А еще есть не-удаленка, где норма что кто-то подойдет и будет работать за твоим компом, чтобы по быстрому перескочить в код, по которому у тебя вопросы.
Спасибо вам за диалог, но на дальнейшие ваши сообщения в этой ветке я не вижу смысла отвечать.
И даже если у тебя в команде условный 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. И вам спасибо.
А дженерики-то недозавезли в 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)".
Ниже можно не читать. Уже дали пример, не заметил.
Если вы хотите гарантировать, что вы получите на вход инты (или любой другой тип), вы можете сделать функцию с вариадическими аргументами:
public function callme(int ...$ints)
{
$this->ints = $ints;
}
Вызывать эту функцию так:
$ints = [1, 2, 3, 4];
$obj->callme(...$ints);
Да, это несколько не то, чего хотелось бы от языка. Но технически возможность имеется. Без посторонних средств.
int ... $var
Если нужно, можно эту логику вынести в VO
многие боли php там решены на уровне языка
первую очередь строгая типизация
я правильно поимаю, что вы называете болью отсутствие типизации в нетипизированном языке?
Ну оно не перестаёт быть болью, даже будучи by design :-)
И все эти попытки типизацию там изобразить говорят о том, что не мне одному без неё некомфортно.
Если вы вегетарианец - вы едите блюда без мяса
Если вам нужна строгая типизация - вы программируете на языках, которые основаны на ней
А вегетарианцы пусть едят искусственную говядину (те, кому нужен вкус плоти)
Все довольны
p.s. Нежелание вегетарианцев есть мясо - это не их боль.
В смысле, это вообще не боль
Никто не изображает. Она там есть. На проектах, в которых я работаю везде включена строгая типизация и везде используются статические анализаторы (ну и плюс cs, phpunit, deptrac). У Вас не получиться просто взять и передать int, где ожидается string.
На ваших проектах строгая статическая типизация. В самом языке она слабая динамическая с кучей неявных преобразований типов.
Если я в начале скрипта укажу 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 позволяет не делать этого, что является по умолчанию и чем, собственно, пользуются. Всё зависит от разработчика.
Это помогает конечно, но не меняет картину. Скажем в PHP есть великолепная структура хешмапамассив, которую можно задать при помощи []. Вроде бы обсуждали тут в комментариях и в языке нет способов указать явно без костылей, что нам нужно, массив настоящий (как во всех языках) или хешмапа с ключами и значениями. В этом месте как минимум при любых настройках проявляется натура слабой типизации, хотя если любой массив php воспринимать как хешмпапу и забыть о существовании массивов в принципе, то может быть и нормально.
если любой массив php воспринимать как хешмпапу и забыть о существовании массивов в принципе, то может быть и нормально.
Как только вы такое принимаете к сведению, вы делаете невозможным (или затруднительным) решение ряда задач, где важен порядок элементов в массиве (ибо в классической hashmap порядок не гарантирован).
Начиная с PHP 8.1 есть функция array_is_list
. Она может проверить тип вашего массива. В своем коде вы можете делать валидацию данных и действовать соответственно. Да, это при неаккуратной работе с данными может привести к ошибкам, но на то уже есть тесты и код-ревью. Возможно, в будущем добавят более строгий массив. А пока как есть.
вы делаете невозможным (или затруднительным) решение ряда задач, где важен порядок элементов в массиве
$a=[];
for($i=0;$i++;$i<10) $a[$i]=something;
если индексы — числа, то порядок будет. Или как?
Порядок, разумеется, можно получить. Но, скажем, получать первых 1000 элементов вы как будете? По одному будете вычитывать из hashmap? Какова будет эффективность такого кода?
И да, если вам надо отрезать кусок от массива с начала. Вы в хвосте массива имена элементов будете переименовывать? Или где-то хранить значение наименьшего индекса?
Понимаю, просто без этого простого типа данных в принципе гарантии "сильной" типизации уже не такие существенные, потому что эти две структуры применяются очень часто при написании кода.
В стандартной библиотеке есть класс с массивом, но он статический в стиле си, нельзя в него нельзя динамически добавлять лишние элементы. И он довольно вербозный, в реальной кодовой базе не видел, чтобы его применяли.
я правильно поимаю, что вы называете болью отсутствие типизации в нетипизированном языке?
Тут еще была отдельная боль на собеседованиях. Когда с приходом семерки и типов ты судорожно пытался угадать, кто твой интервьюер - адепт старой школы, считающий, что PHP - язык динамический и енти типы бесовские нам тут не нужны. Или же человек джва года ждавший типизацию и не видящий жизни без нее. Оба типа выдавал вопрос: используете ли вы типы? Ответ, что буду использовать в зависимости от кодостиля вашей компани, обычно не устраивал.
буду использовать в зависимости от кодостиля вашей компани
скорее, конкретного проекта, а не компании
в любом случае, если собеседующему надо чтобы вы угадали его позицию, а не озвучили свою - это звоночек, там делать нечего
Лол, не вводите людей в заблуждение байками многолетней давности. PHP7 вышел 7 лет назад, PHP8 уже года два как релизнулся. И у меня есть огромные сомнения, что Вы вообще видели его в глаза с битриксом и ларавелем =)
Мил человек, прямо сейчас еще хватает легаси, которое работает на 5.6 . Семерка сейчас - основная версия в куче дистров. А в Ubuntu 20.04, которая LTS, которая по планам будет поддерживаться до 2030, там версия php 7.4.
Конечно, когда скачал под винду последнюю версию php с сайта, можно и восьмеркой полакомиться с ее типизированными полями класса. Но когда дело доходит до реальный серверов, то выходит "ой!". Потому что продукт старый и большой и его части завязаны на старую версию. Или у вас по контракту сервер заказчика, на котором вы вообще за пределами своей дирекетории ничего менять не можете, а админы не хотят возиться phpbrew и phpenv, и с докером разбираться не хотят.
там версия php 7.4
восьмеркой полакомиться с ее типизированными полями класса
Типы для полей класса как раз в 7.4 появились
Ну поменяйте поля класса на компактные annotations, которые точно из восьмерки, не суть.
facepalm.jpg
Аттрибуты в PHP8. Не аннотации. О каких паттернах может идти речь, если в таких элементарных понятиях путаетесь =)
Я же написал компактные аннотации, а не те которые в Javadoc, что передает суть. По-моему вполне простительная ошибка - вы же тоже наверняка не помните название всех операторов PHP наизусть, или еще какую-гнибудь хрень, без знания которой дальше говорить не о чем.
Вы кстати живой пример того буквоедства, которое я не любил в вашем сообществе. В этом желании заучивать, что авторитетов паттерналистики, что инконсистентую стандартную либу. Если кто-то дочитал настолько глубоко до этой ветки комментариев, то подумайте, а хотите ли вы работать с людьми, которые будут считать вас нубом из-за того, что вы не помните название очередной фичи, в очередной версии языка.
Как я уже подмечал, у Вас не было опыта работы з нормальным проектом PHP, что бы ныть. То что Вы работали с битрикс/ларавел легаси - ничего не говорит о PHP в целом. Это только говорит о том, что Ваша предыдущая работа - говно, или Вы просто нуб с огромным ЧСВ, ибо 10 лет. Лол.
Репы с PHP8 beta и RC были доступны еще до релиза (по крайней мере в SUSE точно), а не только бинарник для винды, лол (эти Ваши рассуждения, кстати, хорошо демонстрируют Ваши познания линукс и предпочтения в использовании OS). Как выше верно подметил @TonyKentnarEarth- строгая типизация есть уже минимум года 3, а то и больше (с каждой версией идёт улучшение в эту сторону).
У нас PHP8 активно юзается на проде (несколько проектов) уже минимум как год, и переезд на PHP8 был довольно прост из-за того, что у нас используются дев-тулзы и строгая типизация (внезапно). И не просто, что бы был PHP7 код с PHP8 интерпретатором, а с изменениями по необходимости.
Как я уже подмечал, у Вас не было опыта работы з нормальным проектом PHP, что бы ныть. То что Вы работали с битрикс/ларавел легаси - ничего не говорит о PHP в целом. Это только говорит о том, что Ваша предыдущая работа - говно, или Вы просто нуб с огромным ЧСВ, ибо 10 лет. Лол.
Нет, вы подметили неправильно, у меня был опыт с разными проектами на PHP.
Репы с PHP8 beta и RC были доступны еще до релиза (по крайней мере в SUSE точно), а не только бинарник для винды (лол). Как выше верно подметил @TonyKentnarEarth [/users/tonykentnarearth]- строгая типизация есть уже минимум года 3, а то и больше (с каждой версией идёт улучшение в эту сторону).
Признаю, что ошибся насчет версии, когда это было введено. Но мой посыл был в другом - разброс версий PHP, который используется в проде огромен и не всегда есть возможность их поменять. А вы удобно зацепились за мою ошибку с номером версии и полезли рассказывать какая в языке замечательная типизаци. Да, замечательная, но речь не о том.
У нас PHP8 активно юзается на проде (несколько проектов) уже минимум как год, и переезд на PHP8 был довольно прост из-за того, что у нас используются дев-тулзы и строгая типизация (внезапно). И не просто, что бы был PHP7 код с PHP8 интерпретатором, а с изменениями по необходимости.
Я рад за вас, но все равно продолжаю считать, что так как у вас далеко не везде.
у меня был опыт с разными проектами на PHP
И все они, очевидно были говном. Или Вы нуб.
По крайней мере вы не отрицаете наличие в среде PHP-шников нубов и говеных проектов, это уже кое что.
Они везде есть. По крайней мере, я не сру на всех подряд, потому что я не умею в их инструменты.
Они везде есть. По крайней мере, я не сру на всех подряд, потому что я не умею в их инструменты.
Вы правы, вопрос в процентном содержании. И для PHP есть вполне объективные предпросылки к тому, чтобы плохого здесь было много. И заметьте, у меня нет претензий к иструменту, мне было нечего предъявить уже PHP 7, восьмерке тем паче. И я не сру, а называю вещи своими именами:
- низкий порог входа? да
- низкий порог входа как фактор определяющий низкий уровень людей, закрепляющихся в стэке? да
- куча дно-кандидаторв? да
- перенасыщение рынка кандидатами? да
- потребность в макаках-программистах знающих только и только свой фреймворк до корки? да
- куча версий в продакшене, на который не всегда можно повлиять? да
- низкие бюджеты? да
- неадекватные заказчики? да
- инструмент для стартапов, 95% из которых мусор? да
- натаскивание кодеров на методичку REST-SOLID-GRASP? да
- сколько-то прошаренные люди уходят из PHP на GO, но не обратно? да
А знаете, что самое ироничное? Если бы вы вдруг смогли волшебной палочкой сделать так, чтобы все пересели программисты PHP на условный Symfony, Docker, PHP 8 с обязательной типизацией, то стоимость разработки бы сразу выросла так, что отсекла бы кучу народу от PHP, сделав его второй явой. А так стэк PHP и останется одним большим базаром, где будут проекты и команды на любой вкус. Только где нормальные - места знать надо.
И заметьте, у меня нет претензий к иструменту
ну да, ну да, я заметил
PHP - это одна большая помойка. От языка до инфраструктуры. От инфраструктуры до мест работы. От мест работы до людей, которые с вами работают
Остальные места работы на PHP - это параши той или иной засраности, если вы работаете там даже сеньором.
PHP-шник мало того что всю игру кукарекает
Но все программисты на PHP, что мне попадались - люди с интеллектом дай бог чуть выше среднего
В этом стэке некуда развиваться. Тут гнобят за развитие и критическое мышление.
Это гребаный тупик
Один Вы Д'Артаньян
Хороший у Вас подход. Сначала обосрать как можно, а потом удивляться, с чего бы это Вас в ответ гнобили, лол. А почему? - да потому что Вы не так хороши в PHP, как себе возомнили. И не имеете никакого права критиковать то, с чем не умеете работать.
И все ж PHP, как к инструменту, претензий у меня лично нет. Как язык его можно разбирать долго, многие вещи со времен "фрактала плохо дизайна", все еще актуальны, и потому это помойка. Там тезисов было достаточно.
Вы кстати продолжаете упорно игнорировать мои другие аргументы, срываясь на ВРЕТИ, ДЕЛО В ТЕБЕ, и прочую демагогию типа "Один я Д'Артаньян". Зачем мне по вашему рассказывать о проблемах, которых не существует? Зачем кто-то писал статью про "фрактал"?
Эдак мы придём к тому, что у разных языков разная область применения :-)
Вроде чекаута на маркетплейсе.
Может я чего-то не понимаю, можете пояснить почему go не подходит для этой задачи, и почему не подходит для сложной бизнес логики, ну или хотя бы раскрыть, что подразумевается под сложной бизнес логикой?
Я подразумеваю большое число объектов (десятки и иногда сотни) и их коллекции, а также их взаимодействия друг с другом. Лично мне в Go не хватает наследования и эксепшенов.
Я подразумеваю большое число объектов (десятки и иногда сотни) и их коллекции, а также их взаимодействия друг с другом.
В целом это можно реализовать, да это будет труднее чем в пхп или питоне, но как по мне это не особая проблема.
Лично мне в Go не хватает наследования
В целом, что-то близкое к обычному ООП наследованию можно сделать через интерфейсы и встраивание, но опять же реализация будет труднее.
и эксепшенов.
Это довольно холиварный вопрос(не только в го). В ряде языков - это довольно легкая конструкция, которую можно использовать для обработки обычных ошибок (например если не можешь подключиться к базе, то кидаешь эксепшен), но например в c++ их рекомендуют использовать только в крайних случаях, имеется ввиду случаи, которые не может предусмотреть программист, например, что-то в сторонней либе упало, но многие все равно используют для простых случаев, т.к. удобно. В го вы также можете делать через panic/recover, но в современном коде использовать паники не считается хорошим подходом (кроме некоторых случаев, в которых паника не должна восстанавливаться), поэтому они обычно бывают когда что-то с nil делаешь или проблема находится в сторонней либе. Просто я еще помню как на парах по c++ препод учил обрабатывать деление на 0 при помощи исключений, но в реальности такой подход оказался неправильным, кода конечно меньше получается, но ситуация на самом деле не является исключительной.
В целом это можно реализовать, да это будет труднее чем в пхп или питоне, но как по мне это не особая проблема.Так я и не утверждаю, что нельзя. Просто в условиях постоянно меняющихся бизнес-требований код на том же PHP (или на C#/Java) получается более понятным (в смысле откуда что берётся) и проще поддается модификации.
У меня на Go отлично получается реализовать задачи в стиле SRP, когда есть конкретный сценарий с несколькими условиями, который нужно обслужить. Такой себе сферический микросервис в вакууме.
А вот когда в одном месте сценариев может несколько десятков, требования к ним могут меняться каждые пару месяцев, в реализации нужно учесть зависимость от фазы луны, первой буквы имени собаки покупателя и дня недели — код на Go получается слишком многословным и запутанным. Обычные ООПшные классы имхо лучше справляются с сокрытием сложности в своих недрах.
Вполне допускаю, что я просто плохо умею в Go ?
В целом, что-то близкое к обычному ООП наследованию можно сделать через интерфейсы и встраивание, но опять же реализация будет труднее.
В go встроенная структура не имеет ни знаний о том, куда она встроена, ни доступа к встраивающей её структуре. Это, соответственно, делает невозможным абстрактные функции. Это так же делает невозможной работу с обрамляющей структурой во встроенной (т.е. вы не сможете встроить структуру и её методы применять не к ней самой, а к обрамляющей структуре).
P.S. Да, можно заранее предусмотреть во встроенной структуре механизмы — типа переменных с типом функции, куда вы будете присваивать свои функции, меняя тем самым поведение. Вы можете также передавать во встроенную структуру указатель на обрамляющую. Но как-то это уже сильно много возни. О хрупкости и избыточной связности такого кода уже и говорить не приходится. Да и на ООП это уже как-то не очень похоже будет.
У exception в php есть принадлежность к определенному типу, например в зависимости от типа exception можно обрабатывать логику по разному. В go я пока не на столько силен, но все складывается в то что нужно обрабатывать текст ошибки чтобы понять что это, как по мне не очень надежный механизм.
Паттерны действительно не зависят от языка, но у разных языков разные комьюнити, и в некоторых из них наблюдается явные перегиб в отношении молитв на божественные паттерны и вера в то, что напихивание всех паттернов. которые они знают, сделает их код лучше просто само по себе. Это так не работает. Ещё раз, я не говорю что паттерны это плохо. Это как таблетки, применённые по делу в нужной дозировке очень полезны, применённые от балды в неумеренных количествах - безусловный вред. Я говорю именно о бездумном применение паттернов, и комьюнити разных языков болеют этим в разной степени, а некоторые почти не болеют.
Паттерны таки зависят от языка. Если вы на Питоне будете реализовывать условный синглтон по канонам банды четырех, с переопределением конструктора и фабричным методом, — это будет выглядеть несколько странно. Ещё более странно будет выглядеть классический итератор, реализующий next() без нижних подчеркиваний.
Мало знать что такое фабрика в принципе, нужно уметь выразить это при помощи средств языка и в рамках общепринятых хороших практик.
Если перефразировать - от языка зависит, сможете ли Вы адекватно реализовать конкретный паттерн на конкретном языке, и нужен ли он Вам. Как пример - тот же синглтон в PHP (да и не только) считается антипаттерном и не используется.
Но паттерн от языка никак не зависит.
Слышал мнение, что паттерн — это просто эмуляция того, что отсутствует в языке синтаксически, другими средствами. Например, где-то функтор это целый паттерн, а где-то самая обычная лямбда.
Паттерны нужны для тех языков, где вне объектной модели нельзя достичь таких же результатов. Паттерны Haskell, Scala, Common Lisp, SML, Ocaml и т.д. могут отличаться и отличаться довольно сильно от паттернов принятых на мейнстримных Java-like объектных языках.
Вы мне напомнили о моём давнем желании написать эссе о дрочке на "гибкость" и "расширяемость" "архитектуры". Про электрика с очень гибкой и расширяемой резиновой лестницей.
А что не так? Архитектура современного [серверного] приложения должна быть гибкой и расширяемой
Иначе будешь переписывать код несколько раз
Квайны - очень гибкие приложения, можно запускать на разных языках. Давайте делать сервер так чтобы его можно было запустить и питоном и пыхой и явой, нам же нужна гибкость. Давайте сделаем так, чтобы сервер мог работать и с ораклом и постгрёй и монгой и с локальными файликами без бд, очень же гибко, вдруг бд нет. Я надеюсь вы поняли. Гибкость часто превращена в карго-культ. Гибкость стоит закладывать там где надо и в необходимых пределах. Иначе получаются очень гибкие лестницы из резинок от трусов. Не работает, не держит нагрузку, зато гибко.
Гибкость стоит закладывать там где надо и в необходимых пределах.Это очень правильно. Думаю, любого разработчика спроси — он согласится, что, конечно, гибкость важна, но только в необходимых пределах, и что оверинжиниринг — это, конечно, плохо.
Но есть одна проблема: каждый под необходимым уровнем гибкости понимает что-то своё (весь код не в одном файле? слишком сложно). Так что без описания способа понять, когда стоит остановиться, и разбора конкретных кейсов эти рассуждения не очень полезны.
С гибкостью и расширяемостью тоже меры надо знать. Мало в каком проекте действительно нужны очередные AbstractSingletonProxyFactoryBean. А время на разработку и поддержку этой очередной точки расширения или слоя абстракции нужно.
Меру, конечно, надо знать
Но очень много денег заказчики теряют именно из-за плохой изначально архитектуры, в том числе (если не в первую очередь) недостаточно гибкой и расширяемой
Но это знание приходит только с опытом. У автора такого опыта, похоже, еще не было
Мой прошлый проект длиной 5 лет был сконвертировать игру написанную на flash 11 лет назад на webgl и typescript и подсадить ей новый движок, и мы успешно выполнили эту работу, поверьте я видел много проектов со сроком поддержки 10+ лет. И нет, они не работают за счёт резиновых лестниц. Там много расширяемости там где она нужна, и там много жесткости, тоже там где она нужна. В том числе для поддержания единообразия расшинерий, чтобы их не лепили во все места какие только можно. Там много синглтонов, там много статики которая работает единственно верным образом и либо меняется в проекте раз и на всегда, тогда мы идём и правим код, либо работает как есть, и ей абсолютно вредна расширяемость. И да эти проекты работают на десятках платформ, там десятки языков, чёрт возьми с поддержкой склонений числительных и каких-то извратов с предлогами зависящими от пола в французском, локализованная графика и сюжет, всё это гибко и удобно, с софт рестартами, бексовместимостью минимум на 6 месяцев, а иногда на 3 года. Мне повезло работать уже 11й год в одной компании и я могу видеть как развиваются решения сделанные 10 лет назад. Как рождаются и умирают проекты. Код это текст, код расширяем в том числе способом переписывания. И если начать смотреть про деньги и стоимость поддержки, то весь из себя расширяемый код который через 8 генераторов конфигураций со стратегиями сконфигурирован единственным образом и работает так 5 лет, вреден. Это стоит поддержки. Новым людям гораздо понятнее был бы прямой линейный код в котором прямо написано что он делает. Я не говорю что расширяемость - плохо. Я говорю что расширяемость там где она не нужна это плохо. А искусство видеть где она нужна или нет приходит только с опытом, и не надо бояться ошибиться - перепишете. Делать расширяемым каждый чих, только потому что вы боитесь взять на себя ответственность за то что вдруг, о боже, код придётся удалить и переписать не нужно. Кстати подумалось тут, люди любят делать рефакторинги (т.е. переписывать код без изменения апи и функционала) но боятся переписать код с изменением функционала, им приятнее сделать плагинабильно и потом налепить новый плагин. А то что ушло 10 раз больше кода на одну простую херню которую будут менять хрен знает когда, это норм.
Вы под расширяемостью понимаете что-то свое. Причем тут генераторы конфигураций?
Для меня гибкость это когда ты с одного фреймворка можешь без особых сложностей уйти на другой (не меняя язык, естественно). Или поменять базу данных. А расширяемость - "раскидать" приложение по нескольким серверам, когда понадобится из-за возросшей нагрузки. Или так же поступить с БД. Добавление нового функционала производится легко, и т.д.
Я расширяемость употребляю здесь как полный синоним гибкости. "Расширить" приложение по серверам называется масштабируемость. Про неё мы тут вообще не говорим.
когда ты с одного фреймворка можешь без особых сложностей уйти на другой
зачем? Чтобы что? Как часто вы меняете фреймворк под приложением, какие бизнес задачи это решает?
Или поменять базу данных.
Зачем? Любая конкретная база крута своими фишками, постгря транзакциями, работой с json и ещё кучей фишек, кликхаус способностью переваривать конские нагрузки при ограничении функционала. Хорошее приложение и архитектура выдерживающая большие нагрузки как правило будет так или иначе привязана к базе, просто потому что использует по полной её преимущества. Не, мы меняли базы под приложениями когда они нас переставали устраивать, но это было всегда сопряжено с изменениями в некоторых местах кода просто потому что с другой базой нужно по-другому работать. А если вы выберете просто пересечение функционала разных баз и будете использовать только то, что есть у всех, так получится тормозное чудище, зато базу каждый вторник менять можно. Если просто подсадите вместо постгри клик, клик офигеет.
Ну вот когда вам придёт в голову / понадобится взять приложение с одного фреймворка (потому что он устарел, например) и перенести на другой, или поменять базу с реляционной на гибридную (потому что так удобней для изменившейся модели данных), вот тогда вы и задумаетесь, гибкое ли у вас приложение и насколько вам удобно всё это сделать.
А пока не понадобилось - разговор беспредметный
потому что он устарел, например
Если фреймворк устарел, как вы перепишите на новый, не устаревший? Если новый, не устаревший фреймворк использует новые модные паттерны программирования (иначе, почему старый фреймворк устарел)
Но почему вы закладываете в приложение возможность замены фреймвёрка и базы, а почему не закладываете возможность замены системы счисления, вдруг в мы перейдём на двенадцатиричную? А язык почему бы не поменять, потому что он устарел, например.
Не, увы, так не работает. Вы предлагаете заранее заложиться под нечто неизвестное — "новый фреймворк на смену старому", "новая модель данных". Как вы можете написать эффективную абстракцию поверх того, о чем вы ничего не знаете? А если знаете — зачем вам абстракция, почему сразу не использовать то что лучше и новее?
Пример
Vuetify - библиотека визуальных компонентов
Прекрасно работала на Vue 2
Но уже давно Vue 3, а Vuetify всё тормозит перейти на нее
И те, у кого проект на Vue 2 и Vuetify не могут перейти на Vue 3
Хотя очень сильно хотят!
И они решают использовать другую библиотеку компонентов
И тут вопрос - насколько они привязаны к Vuetify. Насколько в нее "встроились"
Сколько её "фич" они использовали
Например, обменяли ли они простой CSS на ихние стилевые атрибуты элементов
Если нет - стили им портить не надо
Если да - полностью переписывать стили придется
Первый вариант - более гибкая архитектура чем второй
Модная Vuetify за пару лет превратилась в оковы.Хотя по вашему казалась "лучшим и новым"
Как говорится, "знал бы прикуп — жил бы в Сочи".
На момент, когда человек начал свой проект с Vuetify, это действительно мог быть новый и самый лучший для его целей UI-фреймворк, позволивший тогда сэкономить значительное количество времени и сил. Предугадать заранее, что его разрабы застрянут с портированием под Vue3, на тот момент было невозможно.
Сделать из этого вывод, что все фреймворки зло — юношеский максимализм. Современный проект невозможно сделать, не опираясь вообще ни на кого: а вдруг сам Vue помрет, давайте писать на голом джиесе. А вдруг сам джиес помрет, давайте сразу на wasm. И так далее до бесконечности. Тем более, что некоторые фреймворки все-таки продолжают работать десятилетиями и все еще поддерживаются, как какой-нибудь jQuery или Windows Forms, поэтому проблема с устареванием некоторых обходит стороной.
Короче говоря, все меняется, и код тоже должен меняться. Не нужно ставить себе невыполнимые требования и стараться заранее все предугадать. Переписывать рано или поздно приходится всем, никакого зашквара в этом нет.
Собственно, пример выше — из той же оперы: библиотека предлагает собственный, якобы очень удобный способ задания стилей взамен стандартного. То есть, пытается залезть куда-то вне сферы своей прямой ответственности.
С таким же успехом мог бы и весь vue сдохнуть.
Изначально по задумке языка SQL, сменить базу должно быть довольно легко, если писать в рамках стандарта SQL. Но что-то пошло не так...
Также довольно легко менять фреймворк и библиотеки, если их стараться не использовать. Фреймворк по факту вас в какой-то степени вендор-локают своей "гибкостью", перенести бизнес логику между фреймворками может быть не так просто, как вам кажется.
>не меняя язык, естественно
А если придумают новые модные языковые конструкции, но в вашем конкретном языке нет? Есть ли у вас возможность дополнять его синтаксис, подгонять под современные реалии (скажем придумают лучшую замену парадигмы ООП)? Скорее всего нет. Но в рамках дискуссии о PHP это не имеет смысла, так как в языке даже стандартную библиотеку без костылей переопределить нельзя, не то что добавить языковые конструкции. Говорит ли это о том, что PHP негибкий язык? Скорее да. Перестают ли из-за этого использовать этот язык? Скорее нет.
Абсолютное большинство проектов даже не доживает до того момента, что бы поиметь проблемы с этой мифической "расширяемостью". Часто как раз из-за оверинжениринга на начальных этапах, когда надо было просто склеить из чего кто умеет прототип, прощупать бизнес модель, понять, что есть ROI и вот только на базе этого опыта лепить что-то сложнее. И я чаще видел переписывание проектов на совсем новые рельсы на модных актуальных технологиях в виде отдельных сервисов, чем "расширение" этого сложного и неподдерживаемого "расширяемого" монолита, который быстро превращается в легаси.
так она потому и гибкая и расширяемая, если ты можешь на ней переписать несколько раз ))
Опыт показывает, как бы ты там не извращался с гибкостью и расширяемостью рано или поздно прилетит задача которая не влезет в твою гибкость и придется переписывать полностью. И такое случается примерно раз в три года.
Гибкой и расширяемой архитектура должна быть в отношении
Интерфейсов сетевого взаимодействия компонентов. Ведь даже для простого магазина у нас могут быть отдельные сервисы (часто 3rd party) для
Авторизации
Аналитики
А/Б - тестов
Логистики
Обработки информации со складов и от внешних поставщиков
В отношении систем хранения. Мы можем
Поменять старую СУБД полностью (от появившейся необходимости нормальной работы с JSON до импортозамещения)
Вынести часть данных в специализированную СУБД (для какой-нибудь аналитики)
Вынести хранение в какую-то облачную систему
В отношении разделения разработки и деплоя
раздельный деплой компонентов, из-за разных требований к скорости разработки фич и надежности (например потребовалось в архивной системе одного банка, где блок заявок в архив меняли редко и им пользовались постоянно, а блок со стороны архива меняли часто)
разделения проекта на разные репозитории и раздельная разработка (например маловажный функционал решили отдать на аутсорс)
В отношении смены языка программирования / фреймворка, например из-за прекращения поддержки, либо просто потери популярности (например Delphi, Perl, AngularJS)
И у каждого приложения комбинация будет своей.
В отношении смены языка программирования / фреймворка, например из-за
прекращения поддержки, либо просто потери популярности (например Delphi,
Perl, AngularJS)
Если проект не на 3000 строк, то например переход с ангуляра на вью или реакт будет довольно проблемным и затратным, т.к. у каждого фреймоврка есть свои особенности, а переписать на другой ЯП часто означает очень большие затраты, т.к. хотя они и похожи синтаксически, чаще всего на них пишут по разному, сравните яву/php/python/c++/go, более менее можно переписать только с питона на пхп(или обратно) и с c++ на го(обратное не работает). Попроще дела обстоят с микросервисами( и с некоторыми монолитами), где можно переписать кусок кода на другой язык.
Есть утка. Птица, которая умеет ходить, плавать и летать. только делает она это всё как то не очень. Так и приложение, которое гибко может расширяться на любые фреймворки, языки, БД и чего тут ещё упоминали вероятно на всех них будет работать одинаково плохо.
Всё хорошо на своём месте и в своё время. И тут нужно чувствовать грань, когда нужна гибкость, а когда нужно взять одну технологию и выжать из неё максимум.
К сожалению, гибкость очень во многих местах стала священной коровой. "А если мы захотим поменять базу, всё должно продолжать работать". Зачем мы захотим поменять базу данных? Как часто в проектах просто так берут и меняют базы? мне ни разу такого не встречалось. Было, меняли. Но это был длительный процесс с вдумчивой доработкой кода напильником и оптимизацией запросов. процедур и триггеров под заморочки новой базы.
Да, вы всё правильно поняли, именно эту мысль я и пытался донести.
только эту мысль, к сожалению, до очень многих очень сложно донести.
Если какая то идея входит в моду, то во многих местах она начинает считаться серебряной пулей. Даже если авторы и популяризаторы этой идеи прямо пишут, что она применима не всегда, а в некоторых случаях даже вредна. Такое впечатление иногда, что куча народа читает в умных книгах только предисловие и начало первой главы, где описываются преимущества подхода. А главы, где пишут недостатки и границы применимости уже не осиливают.
Лично для меня это источник непроходящей боли - в проектах бывает всплывает куча проблем из за того, что очевидное решение не соответствует очередной моде
"Почему автор - это ошибка PHP"
Не так давно искал Ларавель спеца на 250 т.р. на удалёнку, и не нашёл
Где вы?
Нафига тебе laravel спец? Чем не подходит symfony/yii/phalcon/любой-фреймворк спец?
чтобы "спец" не тратил времени на изучение ларавельных изворотов типа sail
В пхп фреймворки за пару дней изучаются.
Так-то изучаются, да. Но чтобы пройти собеседование когда вас будут гонять по кишочкам нужно или сидеть зубрить неделями, или плотно работать от полугода. Нужно сойти за своего короче. Симфонийщики и ларавельщики друг друга не особо переваривают, а если еще фанат Yii влезет...
И в этом беда - PHP-шник считает, что выучить фреймворк - это подвиг. И что его непременно нужно заучить. А не использовать документацию как справочник. И не угадаешь в чем дело - то ли для них это и правда интеллектуальный подвиг. А может быть когда человек все знает, то он может круды писать вот прямо сейчас начинать, но постойте! Если проект серьезный и большой, то эти 3 дня на въезжание в ORM фреймворка погоды не сделают. А выходит что делают, настолько длинные проекты с негорящими сроками.
И главное тут в пример приводится sails, сомнительная обертка вокруг докера, artisan и nodejs, которая через версию не запускалась у меня. Вариант, что можно вести полноценную разработку на Laravel без этой параши, даже не рассматривается. А разгадка проста - к sails идет готовый буклет по дрессировке макак, включающий в себя сборку фронтенда, дебаг, деплой в облако и даже менеджмент версий php.
Наверное отличный инструмент когда делает 10 сайтов с поверхностыми знаниями всего под разных заказчиков и модно деплоишь в облако. Т.е. примерный облик проектов можно представить.
все уже устроены.
мало денег
Говорю же: ушел на ruby.
PHP – это шаблонизатор для Perl, написанный студентом для личного пользования, который потом некие два мошенника объявили языком программирования.
JavaScript был написан за 10 дней одним программистом-фанатом Lisp, у которого над душой при этом стояли менеджеры, следившие только за тем, чтобы у языка был модный синтаксис с фигурными скобочками.
CSS, впрочем, был спланирован и реализован комитетом, но результат получился ненамного лучше.
И слава Богу, что автор JS был фанатом LISP - у него получилась одна из самых лучших и продуманных архитектур языков программирования, на базе которой язык развивают уже больше двадцати лет.
И слава Богу, что автор C++ был фанатом C - у него получилась одна из самых лучших и продуманных архитектур языков программирования, на базе которой язык развивают уже чуть менее сорока лет.
А я так полагаю, что у него получился хтонический монстр, который взял в заложники приличную долю программной индустрии.
Linux - это ядро GNU, замена Unix, написанное студентом, что бы пользоваться благами сети на домашнем компьютере.
Как вам там живется в 1997? Готовитесь к проблеме 2000?
По молодости ненавидел PHP. Однако же статье не хватает объективности - почему до сих пор PHP занимает место в первой десятке? Плюсы то у него тоже есть, хотя бы скорость работы и простота для небольших проектов. Взять прямого конкурента - JS и Python - попробуйте сравнить с ними, обосновать в чем PHP так уж плох. JS тоже ненавидят.
Скорость работы — это скорость разработки имеется в виду, надеюсь? Потому что в задачах сложнее «получить строчку из базы, заэскейпить, выдать в браузер» (где каждый шаг на самом деле не php, он тут за запятые) скорость исполнения не очень. Делал раз некую парсилку логов, скорость php показалась низковатой, переписал на C — в тридцать раз быстрее заработало. И это, насколько помню, я ещё explode'ом в php строчку разбирал, а когда из любопытства сделал как в сишном варианте побайтовый конечный автомат, всё замедлилось ещё раз в пять.
А с python не сравнивали? Или JS?
А на асм наверное ещё быстрее )
Ну ясен пень, С. Еще бы с ассемблером сравнили. Надо сравнивать с Питоном, Явой, С#.
Сравнивать компилируемый язык с интерпретируемым по производительности. Эм, а что так можно было?
Без примеров кода никуда. На PHP можно написать парсилку логов, которая будет кушать память как не в себя, повторяя это на каждой итерации, пока позволяют ресурсы, а можно использовать генератор и быть счастливым. Можно использовать FFI. Можно написать своё расширение на C/C++/Rust (ну просто можно, если хотите).
Из интерпретируемых PHP в среднем самый быстрый.
Ну не только небольших проектов. Как раз PHP рулит на простоте разработки больших проектов. Там отлично описывается сложная и большая бизнес-логика.
По молодости ненавидел PHP.
Все мы ошибаемся по молодости, ненавидя сам PHP там, где нужно ненавидеть все что идет с ним в довесок.
Однако же статье не хватает объективности - почему до сих пор PHP занимает место в первой десятке? Плюсы то у него тоже есть, хотя бы скорость работы и простота для небольших проектов. Взять прямого конкурента - JS и Python - попробуйте сравнить с ними, обосновать в чем PHP так уж плох. JS тоже ненавидят.
Исторически сложилось. Первый веб-ориентированый язык, что выстрелил, и не был страшной букой как perl. Та же фигня и с JS.
Нормально
По языкам в среднем впереди PHP, за ним Go, затем далеко где-то Node.js и Питон (Это без Java и Ко, естественно)
Из распространенных PHP фреймворков впереди CodeIgniter и Yii2, остальные в 3-4+ раза медленней ( фрэймворки без swoole )
Всегда думал, что язык это всего лишь инструмент.
Язык это давно инструмент + комьюнити со всеми идеями, модой и отщепенцами. Нанимая людей очень хорошо удаётся почувствовать как нахождение в комьюнити определяет взгляды людей. Мало кто хочет быть несогласным с модными идеями.
В статье речь больше об комьюнити, чем о самом языке. Если нездорово сообщество, причем здесь инструмент?
В статье откровенный необоснованный хейт:
Остальные места работы на PHP - это параши той или иной засраности, если вы работаете там даже сеньором.
При чём автор, видимо работал на единственном проекте и совсем не факт, что он там видел нормальный PHP:
влезть в PHP по причине жирного проекта, где я и застрял. И я много лет
жалею об этом. В этом стэке некуда развиваться. Тут гнобят за развитие и
критическое мышление.
И если мы собираемся "разбиваться на кучки (комьюнити)", то я рад, что в "моей кучке" не будет человека, который презирает всех, только "потому что".
У меня то же ощущение - автор делает выводы на основе опыта работы в одном-двух проектах. Т.е. переносит недостатки конкретной конторы на всю отрасль в целом.
Про рынок труда вообще огонь: "метил в район 3000-5000 $" и смотрел на собеседующего как на "петуха, который всю игру кукарекает".
Ну, я работал в команде с такими людьми. Которые были вечно всем недовольны - и процесс организован не по спринтам, и встреч с обсуждениями нет, а если есть то впустую тратят время; во всех проблемах виноват или тимлид который не те задачи ставит, или девопсер который не так сервер настроил, или фронтендер который неправильно данные с бэка обрабатывает. И вообще язык гавно и архитектура ущербная.
А при попытке обсудить эту архитектуру отвечали: "да мне пофигу что там внутри происходит и насколько правильно оно написано - я хочу побыстрее задачу закрыть, а то проект уже надоел".
Да, хейт. Потому что я не смогу вам донести что то что вы - это вы - это плохо. Вы такие какие вы есть. И статья о том, что если человек чужой такому коммьюнити, то лучше из него валить. Что я и сделал. Но я называю людей петухами, людьми со средним IQ не из злости, а потому что у меня нет других терминов более точно и метко описывающих их.
У меня есть больше 10 компаний гдя я поработал и сотни собеседований, чтобы сделать достаточные выводы. Да, меня не было в Badoo/Facebook, но я и не говорю про сайты однодневки "Пуховики Ашота".
А про засранность я понимаю весь процесс организации в целом:
- чем ниже бюджеты(а в PHP они как правило ниже), тем злее и невалифицированне люди
- чем больше соискателей на рынке, тем более скотское отношение к ним со стороны HR
- чем меньше зависит от навыков программиста, тем больше завивисит от продажников, а значит в любой момент тебя могут выкинуть
- чем сильнее у тебя печать интеллекта на собеседовании с CEO(с печатью кабаничка на лице) после 3 раундов технического собеседования, тем больше шансов, что ты зря тратил время на все 3 раунда собеседований
А так да, язык всего лишь инструмент. Но ровно до тех пор пока ты не начинаешь искать на нем нормальную работу.
Вы гребёте всех под одну гребёнку. По Вашим словам - у меня не нормальная работа и вообще я петух со средним IQ =)
Но у меня хорошая и интересная работа, хорошая зарплата, и вообще мне нравится PHP. И если Вы валите из комьюнити не сделав ничего для него, то скатертью дорога, Вас вряд ли будут ждать назад с Вашим "опытом".
Вы гребёте всех под одну гребёнку.
И в данном случае это разумно. Считайте, что адресую эту статью себе 10 лет назад, чтобы не было места для полумер и оттенков, чтобы я понял что PHP - плохой выбор.
По Вашим словам - у меня не нормальная работа
Про конкретно вашу работу я ничего не знаю, может быть она у вас отличная.
и вообще я петух со средним IQ =)
Если бы ваш IQ был выше, вы бы наверняка пригли к выводу, что нет смысла что-то объяснять человеку написавшему, по вашему же мнению, бред в интернете. Тут одно из двух - или IQ, или вы заядлый петух-шахматист.
Но у меня хорошая и интересная работа, хорошая зарплата, и вообще мне
нравится PHP.
А после работы вы переустанавливаете ШИНДОВС?
а что хороший выбор? Если руки кривые - то любой инструмент плох.
Хотя вы правы -судя по написанному объяснять вам что либо нет смысла. Тем более если вы сами так считаете.
Смешно, спасибо за Ваше мнение, мне было интересно (нет) =)
Я линуксом пользуюсь. Кроме PHP мне нравятся и другие языки, так что не обобщайте. Снова. Вы слишком многое себе позволяете =)
Вижу:
Но я называю людей петухами, людьми со средним IQ не из злости, а потому что у меня нет других терминов более точно и метко описывающих их
Читаю как:
Php-шники пидорасы, а я - Ruby-Д’Артаньян
Давайте сойдемся на том, что я просто покинул коммьюнити, нахождение в котором мне было некомфортно. Чего и рекомендую другим, которым в нем некомфортно, но они еще не поняли почему.
А кто из нас петух наверняка знает только шахматная доска.
Давайте сойдемся на том, что комьюнити было даже не в курсе, что есть такой нытик, которому подсунули говно под жирным соусом.
А кто из нас петух
У кого что болит, тот о том и говорит. Слышали пословицу? Вас, как будто на зоне заставляли на PHP писать. При чём вообще шахматная доска? Не все на двачах зависают, извините.
В статье речь больше об комьюнити, чем о самом языке. Если нездорово сообщество, причем здесь инструмент?
Автор слишком долго работал на PHP, поэтому немного притормаживает в части умения обобщать и переходить на абстрактный уровень. Я так понимаю, он хотел сказать, что комбинации средств разработки в ИТ, могут в какой-то степени определять наборы морально-этических принципов на которых будут базироваться команды разработчиков.
Например, если порог входа в технологии низкий, и напряжение извилин для работы в этих технологиях доступно массам, а продукт все равно находит свою нишу, то тогда автоматически эти массы в силу инстинкта самосохранения выберут такие морально-этических принципы в которой им будет все еще более-менее комфортно, а отличающимся от них этот уровень комфортности будет неприемлем, так как они способны найти работу за пределами этой ниши.
Как человек, который работает с php с 2008 года могу сказать, что все так и есть, если иметь кругозор и критическое мышление.
Знакомых которые перешли с php на другие языки или которые планируют перейти масса, а хотя бы одного, кто с других языков перешел на php - нет. Это как бы показатель.
Никому бы не порекомендовал в 22 году изучать php.
Чего я не понял – почему автор не перешёл на Ruby после того, как понял то, что понял я, а мучился столько лет?
Это пост из "чудесного айти" ? :)
Потому что была какая-никакая работа в большом количестве на PHP. Чтобы перескочить на руби не сильно теряя в зарплате нужно было хорошо так потратиться на обучение временем.
Как к языку к PHP у меня претензий нет, но вот все что идет в комплекте - это капец.
Но ведь в результате всё равно перешли? Вот я и не понял – зачем столько ждали? Неужели все эти 12 лет Ruby потихоньку изучали?
Я думал, что я ошибался и в целом PHP-комьюнити лучше чем оно есть. Особенно учитывая развитие языка последних лет. Только лучше не стало - большая часть вопросов там "ай-ай-ай у меня формочка не отправляется" и ломание копий об талмуды по паттернам. Просто уже не было сил терпеть этот драмтеатр, где люди рассуждают о высоком штиле программирования в условиях когда 90% проектов на языке нужно чтобы дешево и еще вчера.
Терять в зарплате не хотелось. Руби учил года 3, сделал пару сайтов, пару апи сервисов, тренировался на одноразовых скриптах, которые в хозяйстве все равно нужны.
Ну и сами подумайте. Если мне нефомфортно в пыхомирке, то варианта два - либо тот, что я описал в статье, либо то что они замечательные и я им не подхожу. Так что уход в место где я со своим мировоззрением подхожу больше - это конструктивный выход с любой точки зрения.
Ждем такую же статью про Ruby, когда у автора упадет конверсия по резюме на этот язык)))
Это все-таки беды отдельных контор, и отдельных руководителей. Просто в случае с PHP они встречаются чаще - язык сильнее распространён, куча мелких проектов и массовых клиентов.
Как-то делал наблюдение, что больше всего валят по теории и докапываются до деталей именно в конторах из пяти человек. Оно и понятно, им бюджет не позволяет платить большие зарплаты - вот и пытаются ценность кандидата снизить таким образом. Но тут могу быть субъективен.
В общем, тут важно разделять проблемы непосредственно PHP, проблемы конкретных IT-контор, и когнитивные искажения самого работника.
Вы какое-то дно рынка описываете, оно есть в PHP, потому что он очень массовый, но на нём так же много проектов с неплохими зарплатами в районе 4-7к долларов и выше. Но туда, конечно, никто не возьмет человека, который вчера делал тестовые для вакансий за 30-40к.
Ой, совсем забыл про "никто не возьмет человека". В PHP-сообществе страшнючий нетворкинг, если ты в нем не участвуешь, то сразу опускаешься на дно пирамиды соискателей. Хотя принципиальной разницы в сложности проектов за 30-40 и 300-400к часто бывает что ноль. Просто у одного проекта нет денег, у другого есть. На такие жирные места, естественно, будут подтягивать своих. Потому что сложности нет и технические навыки значения не имеют.
Не могу согласится, это какая-то абсолютизация вашего опыта или просто троллинг.
Очевидно, проекты за 300-400к обычно имеют нагрузочку побольше, сложность домена погуще, срок жизни подольше, требования к аптайму пожестче и т.д. и т.п. Я встречал случай, когда за лендинг на тильде заплатили 2кк, но это скорее исключение.
А на хорошие зарплаты в первую очередь смотрят на "своих" не только в PHP, это вообще везде так. Люди просто больше доверяют "рефералам" за которых кто-то поручился, чем соискателям с улицы, причем тут вообще PHP.
Не могу согласится, это какая-то абсолютизация вашего опыта или просто троллинг.
В противном случае это будет авбсолютизация вашего опыта.
Очевидно, проекты за 300-400к обычно имеют нагрузочку побольше,
Правильно. И потому там есть отдельная команда девопсов, есть деньги на оборудование(если нет - земля пухом), которые парят себе мозги этим
сложность домена погуще,
И вы будете сидеть в команде, которая отвчает за кусочек домена, дергая другие команды в случае чего, а итоговый объем знаний будет как и небольшом проекте. На системах в сотнях классов я каждый таск забывал через неделю что я делал, потому что такой объем информации в голове не уместить, да и не нужно.
срок жизни подольше,
И значит у нас легаси, которое надо ковырять вилочкой
требования к аптайму пожестче и т.д. и т.п.
Слушайте я не понимаю при чем тут аптайм, если вы программист в большой компании, а не девопс. Ну ладно еще ведущий программист, или вас поставили дежурть на праздники. В остальных случаях аптайм программиста не касается.
А на хорошие зарплаты в первую очередь смотрят на "своих" не только в PHP, это вообще везде так. Люди просто больше доверяют "рефералам" за которых кто-то поручился, чем соискателям с улицы, причем тут вообще PHP.
Вы правы. Но PHP усугубляет этот эффект тем, потому что очень много соискателей с достаточными навыками. В случае пхп, если ты тимлид, то у тебя чисто из-за количества пхп-программистов больше шанс найти кого-то из знакомых, кто хочет улучшить условия. В случае руби, знакомых может не оказаться, и придется посмотреть кто там остался за забором.
И что? Причем тут пхп? Типичный проект на любом языке ?
И значит у нас легаси, которое надо ковырять вилочкой
Пфф, тоже мне аргумент) Как раз-таки на легаси проектах я встречал оптимальное соотношение зарплаты и затрачиваемых усилий. Получаешь много, работаешь относительно немного, никто никуда не торопит и все всё понимают, социалка, отпуск минимум 1 месяц в год во время которого про тебя просто забывают итд. Какое-то непрофессиональное заявление, честное слово. Выбрал первый пункт в вашем первом опросе, спасибо)
Легаси - это код на любом языке, который старше 5-ти минут.
на легаси проектах я встречал оптимальное соотношение зарплаты и затрачиваемых усилий. Получаешь много, работаешь относительно немного, никто никуда не торопит и все всё понимают
Но есть и обратная сторона: поддержка легаси — это работа, которую невозможно закончить, каждый день будут новые задачи. Через пару лет начинаешь закисать.
поддержка легаси — это работа, которую невозможно закончить, каждый день будут новые задачи
Разработка нового проекта - это работа, которую невозможно закончить, каждый день будут новые задачи.
На работе в принципе задачи будут всегда. Вопрос только в том, комфортно ли лично вам каждый день просто брать задачи из трекера и их делать, или хочется какой-то бОльшей динамики — сегодня пишем новый код, продумываем архитектуру, завтра деплоим, послезавтра правим баги.
В моём субъективном опыте поддержка легаси обычно заключалась в исправлении багов, и редком внедрении новых фич. Кстати, встречал людей, которым исправлять баги намного интереснее, чем писать новый код, особенно если баг трудновоспроизводимый.
сегодня пишем новый код, продумываем архитектуру, завтра деплоим, послезавтра правим баги.
Так это можно делать и на легаси проектах. Если у вас разработка проекта умирает после полугода саппорта - вам, видимо, повезло с такими работать.
Я работал на проектах, первые версии которых писались за 10 лет до моего прихода. Тем не менее, проект был обновлен на самую новую версия языка, использовал современные библиотеки, подходы, да и вообще ничем не отличался от новеньких проектов, за исключением объема кода.
не знаю, где вы находите такие и только такие. Я именно в этом ценовом сегменте спокойно находил подработки. При том, что я по основной специализации ни разу не ПХПшник и квалификация в PHP у меня весьма так себе. Что там творится на 7-8 килобаксов не скажу (наверное то же, что и везде - на такие зарплаты там уже не только и не столько про конкретный язык), а за денежку малую можно найти более менее адекватные требования.
А «своё время» как давно было? Я проходил собесы 4 месяца назад, на 10 собесов мне предложили сделать тестовое только в двух местах, высокомерно-пафосный тон выдерживался в одном (там и оффер самый слабый оказался).
в прошлом году я с последнего проекта на PHP ушёл (поменял основную и решил на ней сосредоточиться). месяцев 8 что ли на нём отработал.. А какая разница? думаете раньше было лучше, а сейчас резко вылупились злобные начальники и стали гнобить вас ?
В этом был главный маразм — ты должен сам был додумывать ТЗ и предугадывать все возможные требования заказчикаЭто не маразм, это очень востребованный в наших реалиях скилл, коррелирующий с наличием опыта. По нему, собственно, и отсеивают. А так язык/фреймворк можно выучить за пару месяцев.
В мире PHP действительно можно отхлебнуть ховна, ибо там много одноразовых проектов, много мелких заказов с фриланса итд. Но есть и другая сторона медали - хайлоад и энтерпрайз, крупные компании и долгоживущие проекты. Там уже дело обстоит ближе к миру Джавы, все серьезно, неторопливо и дорого. Работаю с пыхой уже 8-й год, зарплата перевалила за 200к и считаю, что моя жизнь в 35 лет только начинается) Выбрал пункт "Бредятина" из опроса в статье. В общей сложности прошел за свою жизнь прошел более 50 собесов на PHP разработчика, везде плюс-минус было уважительное отношение и адекватное общение. Повышайте планку, выбирайте работу в корпорациях и не работайте на мамкиных бизнесменов)
По поводу повышения планки и крупных компаний вопрос интересный. До войны, когда можно еще было легко устроиться в аутсорс, доллар был по 70-75, был выбор - на западную галеру за 3000-4000 $ рядовым сениором, т.е. 210 - 280 т.р. или в серьезную продуктовую компанию за 200 максимум. Все что было выше - или управленчество, или знакомства, или там был дикий финтех с хайлоадом на гошечке. Галеры же в качестве проектов предлагали типовые сайты, CRM, ERP, CMS, всякие API, где очередь сообщений нужна была скорее из-за распределенности системы, а не из-за нагрузки.
Как раз осенью 2021 проходил много собесов, были предложения с удаленкой на МСК (не аутсорс) под 300к для пхп сеньора, их меньше, но они были и офферы вполне давались людям с улицы и никаких запредельных скиллов там не нужно было.
Так и на джинне вроде есть офферы 5+, только после нескольких из них складывается впечатление, что люди сами не понимают чего хотят, во всяком случае продать себя CEO на последних этапах у меня не выходило. А по ощущениям - все то же самое, что я писал выше. Куча народу, достаточного по навыкам, отбор идет уже по морде лица, софт-скилам и знаку гороскопа.
Во внутренние вакансии за 300к. да еще и с улицы, да еще и на удаленку, я готов поверить, но это единичные случаи.
продать себя CEO на последних этапах у меня не
выходило
Вот он, ключевой момент, как мне кажется. Вы написали агрессивную и хамскую статью, ноете всю дорогу и при этом сидите на php столько лет. У вас вероятно и правда есть проблемы с софт скилами, думаю любой управленец такое увидит. И задумается, зачем мне брать в команду человека, который будет вечно недоволен и зол.
Если от всех воняет говном, то может это ты обосрался?!
Примите взрослое и ответственное решение - переходите на ваш любимый руби и не воняйте, всем будет проще.
Почему вы не допускаете что писать можно в одном тоне, а разговаривать в другом? Поверьте, я бы не дошел и до 4000 если бы ирл вел себя как рассуждаю в статье.
Потому что образ мышления менять сложно и долго - если, конечно, у вас не расщепление личности. И если вы заранее считаете собеседующего говноедом, а "средний уровень интеллекта" - чем-то унизительным, то это всё равно будет сочиться.
Независимо от того, зовёте вы собеседника по имени-отчеству или "петух".
Всего лишь инструмент, либо подходящий, либо нет.
Я тоже, для довольно специфических целей, в начале карьеры выбрал пыху.
Оказалось - не то. Очень жалею, о потерянном времени.
Сам дурак.
язык - это инструмент. Не бывает такого, что молоток - это плохо. Бывает, что им не удобно винтики заколачивать.
Берёте молоток и ужасаетесь тому, что он раздвоен с двух сторон. Он, конечно, всё ещё пригоден, я имею ввиду, что вы можете забивать гвозди серединой бойка, держась за ручку наоборот.
Ну классика же.
Или вы таки троллили?
Но бывает ведь плохой молоток
Есть всего два типа языков программирования: те, на которые люди всё время ругаются, и те, которые никто не использует...
Bjarne Stroustrup.
Типовые вопросы на собесах по PHP - это вопросы веры и дрочки. Нужно верить в SOLID(понимать нужно также как тот кто собеседует), REST(понимание как у собеседующего).
Но все программисты на PHP, что мне попадались - люди с интеллектом дай бог чуть выше среднего, слепо верящие в догмы SOLID, patterns, GRASP(тут все настолько абстрактно, что каждый скудоум мнит себя философом-богословом, трактуя этот талмуд).
Как же хорошо от мысли, что SOLID, REST и GRASP - это проблема PHP. "Правильные" языки эта детская болячка обошла, и на "правильном" собеседовании эти вопросы стараются дипломатично обходить.
Меня самого угораздило в свое время влезть в PHP по причине жирного проекта, где я и застрял. И я много лет жалею об этом. В этом стэке некуда развиваться. Тут гнобят за развитие и критическое мышление. Тут развитие - задрачивание очередной спеки и повторение догмы.
Сквозь весь текст чувствуется обида автора на конкретное место работы, а также травма от собеседования, которое предшествовало устройству на это место.
это параши той или иной засраности
шизоидный
вскукарек
главпетухом
станьте нормисом
бугуртящий
Мой совет - завязывайте с двачем - 2022 год на дворе, пора идти дальше. Я представляю уровень собеседований с вами. Не удивительно, что вы не смогли найти нормальное место работы с достойной оплатой. Язык тут вообще ни при чём.
чувствуется обида автора на конкретное место работы
на самом деле, чувствуется обида автора природой, не более
и можно было бы этому только посочувствовать, если бы не это его злобное и тупое кукареканье в виде статьи
Как же хорошо от мысли, что SOLID, REST и GRASP - это проблема PHP. "Правильные" языки эта детская болячка обошла, и на "правильном" собеседовании эти вопросы стараются дипломатично обходить.
В PHP - это священная корова, в других языка - нет. А знаете, почему я думаю, что так много внимания этому уделяется? Потому что в массе своей среднего PHP-шника нужно дрессировать по библии, чтобы он выдавал что-то нормальное. Потому что рефлексия на низком уровне.
Сквозь весь текст чувствуется обида автора на конкретное место работы, а также травма от собеседования, которое предшествовало устройству на это
место.
Чувствуется ваше желание выдать желаемое за действительное.
Мой совет - завязывайте с двачем - 2022 год на дворе, пора идти дальше.
Да просто надеюсь, что хоть кому-то поможет не вляпаться в это на старте. Когда начинаешь карьеру, особенно как аутсорсер, PHP кажется лучшим выбором, платят все равно в несколько раз больше чем у тебя в мухосранске, работы завались. Понимание приходит чуть позже.
Я представляю уровень собеседований с вами.
Я вижу, что у вас богатое воображение, но боюсь, что оно ведет вас по пути желаемого, а не действительного.
Не удивительно, что вы не смогли найти нормальное место работы с достойной оплатой. Язык тут вообще ни при чём.
Да послушайте же, у меня было много мест работы на PHP, я их как-то находил. Но мне надоел процесс найма и люди в этом стэке. И сменив стэк, я увидел, что бывает и лучше. Об этом и статья.
Не, статья ваша не об этом, а просто байт на комменты. Но, впрочем, вы хорошо справляетесь с этим, жаль только пользы хабру от этого мало.
Без наличия примера вашего кода на PHP, сложно отделаться от ощущения, что вы перекладываете с больной головы на здоровую
2 стэка
Правильно так: два стека.
У меня PHP основной язык программирования, который я лучше всего знаю ( ну и обязательно JS в небольшой степени). И если подумать — я в жизни не сделал ни одного вэбсайта, но спец. программы, написанные ещё 12 лет назад — всё ещё в использовании и я их поддерживаю.
Как то не вяжется с вашими утверждениями…
Как тут сказали комментирующие — язык — всего лишь инструмент. Если вы решили работать маленьким винтиком на дядю — ваш выбор. Програмер может делать решения и их продавать — это делаю я. Ничего вам не мешает поступать так же.
Если вы действительно умеете продавать, то язык и правда последняя проблема в вашем бизнесе. Но если сделать маленький шажочек в сторону буизнесменов с фриланса, ваяющих скрипты на PHP за мелкий прайс и *продающих* их аж паре тройке клиентов, то там трагикомедия, которую мне уже не по силам описать.
Когда автор не смог в пхп и застрял на рейте в 3000 usd =)
Вообще примерно в 4000$ . Но менять работу стало очень тяжело, если приходить с улицы. Самое неприятное в этом, что я вроде бы как прохожу собеседование, и отвечаю на все вопросы, но ни ответа, ни привета, ни фидбэка. Даже когда я в конце собеседования просил быстро пройтись по ошибкам, которые я допустил. Просто я пришел к выводу, что на такие деньги программисты на PHP если и нужны, то нужны в очень малом количестве. Или что после этой планки уже отнюдь не хард-скилы влияют на вероятность найма. В руби корелляция с ответил-не ответил на вопросы и наймом выше, на мой взгляд.
Да-да, докачался до 4к, искал работу с улицы и никуда не смог пристроится ?
В чем ваш вопрос?
Вопрос в том, что многие люди тут пишут на PHP, имеют рейты и выше 5k$, и еще и успешно меняют работу раз в год, или несколько лет. Вот у этих людей (в том числе у меня) возникает вопрос, а в чем сложность то?
Думаю многим было бы интересно послушать истории этих людей, насколько сильно они используют нетворкинг, из какой страны на какую работают, какую должность занимают и какой стэк используют.
Все и так в курсе, ну кроме тех, кто желчь, хейт и обиду продуцировал вместо работы ?
Мой последний проект на ПХП был пару лет назад, на 6000 EUR (тогда евро был в несколько лучшей форме). Скорее всего, я получал больше любого коллеги-программиста в той конторе на тот момент.
На самом деле я туда собеседовался на go, но в последний момент меня переуговорили на php. Мол, у нас надо повышать культуру и качество разработки. Я почесал репу, согласился.
Проработал там год. За год избавился от некоторой части легаси. Перевел разработку на докер (что привело к если не полному, то значительному прогрессу, с решением извечной проблемы "у меня локально работает"). Сделал автотесты и автодеплой в k8s (до этого тесты никто не писал, а деплой делался ручками админом на физический сервер). Ввел стандарты разработки. Написал новый проект с нуля (который одновременно ввёл новый функционал и заменил старый совсем уж лапшевидный легаси). Перевёл пых на последнюю на тот момент релиз-версию.
К концу моей работы там мне стало достаточно скучно, и я попытался получить себе немного больше полномочий и соответствующую компенсацию в организации. Увы, это не встретило понимания у техдира. На этом и распрощались.
Сейчас я таки работаю на go и за значительно бóльший рейт. Но дело не в языке программирования, как вы, наверное, понимаете.
Для себя какие-то мелочи я по-прежнему пишу на php, потому что на нём уже так много написано, что вместо решения каких-то фундаментальных вопросов (а-ля транспорт, форматы данных, спецификация АПИ и прочее, прочее, прочее) я могу решать исключительно свою прикладную задачу. Не то, чтобы на go всё это нельзя было написать, но кода пришлось бы написать больше.
Впрочем, на go тоже кое-что пишу для себя, но по большей части это какие-то мелкие прикладные утильки.
Попытаюсь привести контраргументы:
4000$ это неплохой уровень - на мой взгляд. Я вот шесть лет на PHP работаю, больше 60к рублей не получал. Хотя нет, это плохой пример.
Собеседования тоже штука субъективная. Бывал на разных - где-то не проходил из-за недостатка опыта, а где-то прям легко и просто: вопросами не валят, улыбаются, сходу зовут работать на битриксе за те же 50к. Да блин, опять что-то не то.
На должность PHP-программиста кого попало не возьмут. Вот мой одноклассник, с неоконченным высшим, дважды пытался устроится - ему не зашло, сейчас грузчиком подрабатывает и 80к получает. Это, кажется, должен был быть тезис что работать на пыхе престижно...
В общем, хотел как-то конструктивно объяснить, почему я именно с этим языком работаю. Не для автора, для себя лично.
Но, видимо, придется или согласиться с его позицией, или признать что я обычный говнокодер с IQ ниже среднего. Или все это вместе.
За статью спасибо, наводит на определенные размышления. Пойду саморефлексировать.
Вы как-то не так себя продаете. Еще в 2016 году получил несколько оферов 120к как чистый пхпшник. Возможно вам стоит поискать удаленку на мск?
Вы чертовски верно уловили то, о чем я уже много раз упоминал в сообщениях выше. В случае PHP ты должен себя продавать, потому что нет разницы кого взять из толпы таких же как ты. Кто лучше себя продаст, тот и победил. Но даже в СНГ, нормальные продажники всего - от машин до стройматериалов и оборудования зарабатывают сравнимо или больше программистов-аутсорщиков. Потому что продажи - это отдельный навык, очень полезный, но не имеющий ничего общего с программированием.
А я выбрал вариант, когда я отвечаю на вопросы и получаю 4500 $ за то что мне нравится, не рассказывая какой я классный и повышу конверсию.
И я раз за разом сталкиваюсь с искренним непониманием того, что хороший продажник это редкость, что продавать может каждый. Да, если хотите некрасивый голос уже сделает так, что у вас ничего не купит. Угрюмое лицо доставшееся генетически? Снова мимо? Нежелание врать напропалую? Следующий! Не вписались в психотип покупателя и не понимаете как он мыслит? До свидания! Выглядите недостаточно успешно? Мы вы вам перезвоним.
Хороший продажник - это человек, который может продать заурядный продукт дороже чем другие. Человек, который может на вопрос "чем ты лучше 50 других программистов приславших резюме" ответить так, что нанимающему станет стыдно за свой вопрос. Хотя разницы нет. Продажи - это все про социальное взаимодействие, обман, доминирование, подмасливание и т.д. Это настолько перпендикулярно программированию, что я не понимаю людей, что на полном серьезе предъявляют программистам, что те не умеют себя продавать.
Боюсь вы меня не совсем поняли мой посыл. Продавать надо свои знания, которые можно показать в диалоге! Нужно уметь выходить за рамки ответа "да", "нет", "какой-то кусок заученного текста перед собесом..."
Из моих собесов 16 года не было ни одной конторы, которая бы вела себя неадекватно и высокомерно, а собесов было много. Я тогда только приехал в Мск и ходил на собесы каждый день по 2-3 на дню.
Самый неадекватный собесе когда мне дали лист с заданием и ушли на пол часа, потом пришли забрали его и не смотря на него сказали мы перезвоним.
В остальных собесах помимо общения мне запомнились совместные решения задач с техлидами, руководителями отдела после чего я получал офер не выходя с кабинета. Были и рисования на доске и алгоритмы и приславутый солид, но там не требовалась зубрежка и поклонение этому культу, а хотели услышать рассуждения, понимание предметной области, обзор кругозора!
Возможно сейчас идет перегруз спецов после разных курсов и развалившихся галер на фоне СВО. Но опять же на текущей работе я провожу собеседования, в том числе и пхпшников и довольно много из них озлоблены и обладают завышенным ЧСВ на фоне опыта в 10-15 лет на пыхе считающими себя гуру языка и утверждая что он гавно, хотя их знания застряли на уровне перехода с 5 на 7 версии с явным непониманием зачем им развиваться и учить новшества языка.
У вас нормальный уровень зарплаты, если вы работаете в пределах РФ или питере и не хотите лезть в продажи и самопродвижение. Когда я начинал джуниором 1С мне платили баксов 100$ в середине нулевых. Локальный рынок - это дно. Если вас не устраивает текущее положение дел, не закикливайтесь на битриксе, учите Laravel - сейчас он является балансом по количеству вакансий, простоте вхождения, наличию легаси в ближайшие годы. Те же 60 к. на удаленке иметь будете. Главное помните, что то что вы узнали в битриксе и то, что узнаете в Laravel, придется через несколько лет критически переосмыслить. Поскольку оба продукта не являются примером хороших практик для построения сложных систем. Опытные пользователи Laravel со мной поспорят и будут правы с высоты своего опыта с другими фреймворками, но у вас этого опыта не будет.
Преимущественно бред написан.
Я не единожды с огорчением слышал от собеседующих фразу "эти вопросы надо знать наизусть, а не рассказывать своими словами".
Проходил множество собеседований, ни разу такого не слышал.
С автором частью согласен.
Применение языка ограничивается только твоим воображением при этом у каждого свой вид на это, соответственно ищут новых людей.
Если взять простой молоток. Им можно достаточно больно не умелому бить по пальцам, можно забивать гвозди, но при создании статуи Микельанджело он тоже принимал основное участие.
Подписываюсь под каждым словом автора. Будучи ПХП-программистом я далеко не всегда с первого раза ложкой в рот попадаю.
С точки зрения программиста как наемного работника к php и Laravel, конечно, могут быть претензии. Но с точки зрения старта новых проектов Laravel - это один из лучших, мощных и высокоструктурированных инструментов для обработки запросов на стороне сервера => высокая скорость разработки и низкие затраты, плюс специалисты на рынке присутствуют. Если в приоритете вопросы не моды, а эффективности, то для этих целей оптимальный вариант (ну или один из).На мой взгляд, основная проблема php не в текущем моменте, а в перспективе, так как в спину дышит serverless, и ключевое поле деятельности для php будет плавно сокращаться...
Да, я в курсе, спасибо. IMHO эти варианты вымрут со временем, т.к. конкретно для serverless стэка есть более оптимальные решения, и новые проекты будут базироваться именно на них.
года два назад работал на проекте где основной бекенд это serverless Symfony + bref. Насколько мне известно - до сих пор всё работает и умирать не собирается. А хоронят много кого. Вот PHP, к примеру, уже который год.
шоб я так жил, как он умирает! :-)
Про работающие проекты вопросов как раз нет. Вопрос в том, какой стэк выбрать тем, кто начинает новые на serverless архитектуре. При прочих равных сейчас я бы php не выбрал для этих целей.
Дался вам этот serverless...
Сейчас стандарт качества веб приложений - SPA
А писать API на бэкенде на PHP - одно удовольствие
Фреймворк выбора - CodeIgniter
Дык кто-ж спорит... Прямо сейчас закончил SPA Quasar+Laravel, полностью доволен своим выбором... Но за своим серваком надо следить, это доп затраты и риски. Когда стартовал изучал возможность полного serverless, но по производительности и костам меня не устроило, хотя все развивается, и мб по другому проекту выбор уже будет другой. На полном serverless стэке я бы скорее рассматривал Node или Python...
На мой взгляд, основная проблема в том, что существуют два мира: мир работодателей и мир работников. Идеал работодателя: за дверью стоит очередь желающих наняться, примерно с одинаковым уровнем скиллов. Можно не спеша покопаться, выбрать, кто согласен на худшие условия. проект от этого особо не пострадает. Идеал работника: есть 100500 вакансий, на которые вы подходите. Можно повыбирать, там не нравится, там поинтереснее, но платят маловато...
В PHP набралось достаточно много работников, вероятно, как раз из-за его массовости. Поэтому в выигрыше оказались работодатели. (ИМХО)
Может быть, поэтому не считают нужным отвечать соискателю (это уже топикстартеру), но это проблема не языка, а культуры работодателей. Когда за дверью этих соискателей как плесени, можно и обращаться с ними как с плесенью. Извиняюсь за обобщение, это опыт 90-х и 0-х, когда на 40 e-mail'ов разосланных на свежие вакансии двое отвечали вежливым отказом: "Ваши данные мы занесли в базу, возможно, бла-бла-бла", третий предлагал чернорабочую вакансию вместо того, на что заявлялся. Потом один руководитель объяснил, что существует негласное распоряжение не брать на работу старше 35. Искусственная безработица и очередь за дверью. Изменилось ли что-то сейчас? Где-то да, где-то нет, но культуры, уж точно, не прибавилось. Время такое, что не до культуры.
Согласен. Особенно умиляет, что выше меня назвали слабаком, за то что я не побежал своим буром пронзать небеса, ради того чтобы угодить работодателям, а выбрал стезю попроще. И ведь я пишу те же самые API, что писал бы и на PHP, т.е. ни развития, ни деградации, просто переход в другое коммьюнити.
Я рад за людей, которые любят свою работу, но глупо отрицать, что в основе рынка труда лежит все тот же спрос и предложение рабочей силы. И чем больше предложение, тем более скотское отношение к работнику, какую бы работу он не выполнял.
выбрал стезю попроще
Слабак)
И хватит говорить о комьюнити. Вы совсем не понимаете, что это такое. Это не групка людей, которых можно обосрать, только потому что Вы не способны решить задачи, которые способен решить инструмент.
И хватит говорить о комьюнити. Вы совсем не понимаете, что это такое. Это не групка людей, которых можно обосрать,
У меня не было цели "обосрать" коммьюнити, я описал как я вас вижу, и коммьюнити это часть инфраструктуры вокруг языка.
только потому что Вы не способны решить задачи, которые способен решить инструмент.
Я не вижу смысла решать задачи, которые никак не связаны с программированием в условиях работы с приятными для меня людьми. Ради какой цели я должен превозмогать, по вашему?
Каким мерзким языком написано. Вы специально так выражаетесь, чтобы рейтинг поднять?
Мне кажется, что данная стилистика соотвествует характеру освещаемой проблемы.
Да, если у тебя софт скиллы на нуле, не поднимешься выше $3000 не только на PHP, но в любой другой сфере.
Для меня в данном случае софт скилы заключаются в "будь как мы, мысли как мы". Можно было притворяться, можно было уйти туда где не нужно притворяться. Вот собственно и весь выбор. Можно например и по-понятиям базарить так, что многих конфликтов в жизни многоуважаемых программистов, сидящих здесь, удалось бы избежать. Но, готов поспорить, они по каким-то причинам решили оставаться самими собой.
Из наблюдений: жесткие требования к знаниям паттернов при интервью к определенной "языковой" вакансии - результат низкой средней квалификации среднего программиста на этом языке и показатель скорости превращения проекта на данном языке в помойку.
Нет плохого кода есть плохой программист :)
Язык лишь инструмент. (не нравится/не удобно, смени инструмент).
Да молотком наверное не удобно копать грядки.
Я бы сказал, что у людей развивается слишком большое самомнение о себе в связи с редкими (дифицитными) профессиональными данными. И устраиваясь на работу тебя не берут( я более чем уверен), что человек себя ведет как полный мудила.
Вы хотя бы допускаете, что в системе, где компетенция работников не влияет на результат, рано или поздно компетенция перестает быть критерием выбора работника и на ее место приходит что-то другое? Есть же куча исследований, где люди проявляют симпатию и антипатию на одни и те же слова, в зависимости от того, насколько красив говорящий, какой у него тембр голоса. Есть же куча ситуаций, когда выбирают по критерию лояльности, или чтобы не подсидел, или чтобы на его фоне не казаться худшим работником.
Коллеги, вот после такого очередного собеседования, кстати, в https://www.livejournal.com/ я и ушел из perl
и перешел на java и не жалею ничуть
Странный текст с запахом нытья. Не нравится - не используй, зачем это выливать? Разные задачи у разных людей. Я предприниматель, остался без поддержки проектов из-за сво, но проекты нужны и продолжать развитие надо, решил освоить php чем собственно и занимаюсь, если я решу что язык не будет удовлетворять мои потребностям - изучу чтото новое, странный нытик.
Думаю, любой язык и любая работа будет ошибкой, если не наслаждаться процессом и не гордиться результатом. Я вот тоже пробовал рвануть в айти как PHP программист. И тоже или игнор, или просто отказ. За все время было одно тех задание, которое я с треском провалил. Не оптимизировано по времени и вместо массиво вывел html.
Проще говоря, провалил.
Что сделал я? Создал сайт на PHP и Laravel. Так себе сайтик, но решил буду с ним работать. Переделаю его полностью, реализую свою идею на lava, рпскручу и буду зарабатывать огромные деньги. ))) И все. Для рынка it программистов я потерян, как наемный работник. Так и что, мне теперь лить грязь на все сообщество? Что ты, автор, можешь показать из своей работы? Не, работа над изменением чьего то кода или работа над кнопкой в огромном проекте, меня не интересует. Предъявляет претензии - докажи, что имеешь право предъявлять эти самые претензии. Нет? Извинись.
P.s. я до сих пор считаю, что PHP это лучший шаблонизатор для веб, а JavaScript зло. Скучно было чиоать, но зачем то написал коммент.
Согласен с вами. Но помимо работы программиста, собственно архитектуры, тестов, написания кодов, которые приятны, где есть где разгуляться, есть и неприятные вещи. PHP в виду низких бюджетов, большого числа соискателей, простоты проектов, собирает полное булшит бинго в плане неумных коллег, херочек-принцесс. И конечно сферического в вакууме Ашота-продаца-пуховиков, который не позволит какому-то очкастому умнику обмануть его в оценке сроков.
HP в виду низких бюджетов, большого числа соискателей, простоты проектов, собирает полное булшит бинго в плане неумных коллег, херочек-принцесс.
Видимо вы и выбирали такие проекты. А кто-то пошел в enterprise, где разработка на PHP и Java отличается примерно никак.
Зарплатой отличается. И опять же, таких вакансий на фоне общего количества PHP вакансий - капля в море. И все хотят попасть туда. И у очень многих людей хватает хард навыков попасть туда. Поэтому ПРОСТО взять и попасть в энтерпрайз, да еще и на нормальную зарплату это не так просто.
да не сложно это. а какая зарплата вам нужна?
да ничего ему не надо, это просто пятничный тролль байтит хабр на комменты
4500$, которая меня сейчас устраивает. Да, я мог ее получить на PHP, но я как-то уже устался усираться каждый раз когда приходится менять работу в этом стэке. И это именно что сложно.
Полностью поддерживаю автора.
РНР не про технологии. РНР про то как транслировать ТЗ в код с минимальными затратами. И когда работаешь над проектом, все силы уходят не на развитие продукта, а на максимальное напихивание свистелок в слоя приложения (ОРМы и прочее), чтобы клепать CRUD-ы с ошеломляющей скоростью. Сущность! Create! Read! Update! Delete! Контроллер! 4 тыс методов чтения данных, 2,5 тыс методов добавления данных. Слепок над БД, который существует только потому, что фронт не может постучать в БД напрямую. Ай маладэц! Дай бох одна крон-джоба чтоб пулить какую-то инфу.
То есть вы в своей жизни видели проекты, где максимум одна крон джоба и возмущаетесь, что язык не технологичный? Так извините, никто вас не будет знакомить с тысячами проектов, где есть и сложная бизнес-логика, и очень сложная инфраструктура. Ну какие крон-джобы чтобы пулить инфу? Для этого уже сто лет применяются очереди, а уж если что-то происходит по расписанию - применяется что-то вроде Kubernetes Scheduler
На одну компанию, где есть кубер, приходит 40-50 компаний, где очереди это как раз из той же оперы, о чем написал автор - не усложняй проект, нам сложно будет найти разрабов за еду. Плюс под пуллом данный я имею виду сошкребание инфы из сгенерированного XML файла, который другая команда тоже генерит по крону и она костями ляжет, чтоб ты не добавил очереди.
В 2018 я был на собесе, где мне сказали "только надеемся ты без хипстоты всякой кодишь?". Я подумал опять свидетели анти-кубера. Оказалось под хипстотой они в виду ООП! Контора делает CRM. Сейчас я в компании, где все есть РНР и все делают (не я) по канону. Но это первое место за 12 лет и 9 мест работы. Все предыдущие - как я описывал выше.
да, вам однозначно нужно повышать умение собесов. вы знали что на собесе кандидат тоже может задавать вопросы?
А кто вам сказал, что он на них получит правдивые ответы?
Вы описываете сейчас ситуацию когда кому-то позарез нужен специалист по цене ниже рынка. Тогда ему и на вопросы ответят, и даже посетуют что не все хорошо, но вы сможете поменять. А когда вы по рынку или выше берете зарплату, то скорее всего будете соглашаться на то что дадут. Если конечно у вас прохождение интервью не хобби.
В смысле вы можете сколько угодно задавать вопросы - это просто еще сильнее сузит круг вакансий до тех где самая высокая конкуренция.
мой опыт мне это сказал. все 18 лет. десятки собесов на которых был кандидатом. десятки собесов которых провел. если это действительно реально а не просто тролинг, мне вас искренне жаль, у вас сформировалось мышление что все кругом хотят вас обмануть и использовать. возможно вам не повезло с компаниями, возможно дело в вас. Я бы посоветовал перерыв месяца на 3 минимум. ну и психотерапевта если есть хороший.
Я лично всегда общаюсь на собесе. врать там смысла нет ни одной из сторон, потому что это быстро вскроется и только зря потеряем время и деньги. и понятия не имею при чем тут ниже рынка и зп вообще.
тяжёлая у вас жизнь. может проекты нужно нормальные выбирать?
Да норм вброс для пятницы, что вы так серьёзно!
Автор годный тролль. Канон соблюдён на пять с плюсом. Взял самый популярный язык, про который есть "определенное мнение" и давай обсирать со всех сторон.
А то, что автор еще и рубист никто не заметил, да? :-) Они обычно обсирают всё, что не руби. И пофиг, что на руби пишет полтора человека в мире и хайп прошел лет 5 назад. Так что тут тоже прям 10 из 10 за соответствие.
хз работаю на symfony лет 6, года 3 назад пересел на на api-platform и жизнь стала проще. Не надо писать бесконечные ввод-вывод данных с базы: написал сущности, повесил сериалайзер и группы для защиты данных, и все готово. Я не думаю, что есть где-то проще и быстрее и в то же время качественнее, чем на php разработка бекенда для приложений. Бизнес платит за часы разработки, если разработчик тратит меньше часов - у бизнеса появляется конкурентное преимущество перед более медленными в написании кода языками. Если бизнес выиграет по фичам конкурентов и в скорости написания фич - повышается ценник в час у программиста, поэтому пыха все еще будет жить, ценник на нее будет высокий. Главное - найти компанию, которая выстрелила или приложить усилия к развитию продукта. Php, по-моему, язык стартапов, а у стартапов по сравнению с enterprise меньше денег, поэтому получаем такие собеседования и условия труда. Но сам я, конечно, перешел на react next's, потому что я слишком быстро стал делать бэкенд и там зп лучше =)
Бизнес платит за часы разработки, если разработчик тратит меньше часов - у бизнеса появляется конкурентное преимущество перед более медленными в написании кода языками. Если бизнес выиграет по фичам конкурентов и в скорости написания фич - повышается ценник в час у программиста, поэтому пыха все еще будет жить, ценник на нее будет высокий.
Нет, это значит что с вам будут требовать больше фич в час. А если вам что-то не нравится - под забором еще толпа людей, которые умеют расставлять аннотации в апи платформ. Во всяком случа ставка PHP на том же upwork не самая высокая.
Главное - найти компанию, которая выстрелила или приложить усилия к развитию продукта.
Ресь о том, что это сделать очень тяжело в среде PHP. Во-первых придется перебрать тонны шлака, во-вторых пробиться сквозь сотни достаточных по навыкам конкурентов.
«где пышным цветом цветут самые мразотные социальные явления.»
похоже что нужно продолжение статьи...
годный троль, одобряю. с душой подошёл, с эмоциями. жива ещё школа старого троллинга и холивара. Да будет его величество Срач!
Ого. Я от php настолько далёк насколько могу, но такая лексика (даже малая её часть) на собеседовании напрягла бы, и я бы дал негативный фидбэк по софтскиллам.
Хороший развлекательный текст) но выводы и размышления - такое себе)
С PHP 10+ лет. У php сейчас золотой век. Лучший язык для mvp с лайфтаймом 1-3 года.
Реальная помойка - это JS без TS.
забавная статья
такое ощущение, что автора допекло php-комьюнити, при этом, судя по комментариям и обсуждениям, представителем этого токсичного комьюнити в основном только он и является)
что до якобы повышенной адекватности в Ruby-based проектах и компаниях - есть теория, что чем более узконаправленный и непопулярный проект, куда сильно нужны люди, тем скрупулёзнее и внимательнее рекрутёры из таких компаний готовы рассматривать потенциальных кандидатов. И наоборот - когда на "junior QA" или там "junior React", "junior Laravel" на одну вакансию присылают по 100 резюме, то можно и половину присланных резюме сразу выбрасывать в мусорное ведро с объяснением "нам не нужны неудачники".
что до собеседований - это же хорошо, когда сразу попадаются "маркеры" глупой компании. На глупом собеседовании у вас спрашивают, сколько методов работы с массивами вы помните наизусть - на умном собеседовании - сколько из них вы ясно понимаете, как они под капотом работают, можете ли объяснить это другим людям (проверка на возможного тим-лида/сениора/ментора) и можете ли реализовать вариации таких методов для каких-то специфических задач.
Слишком много негатива в тексте. Я бывший пхпшник. Если отбросить эмоции автора, и выделить конструктив, то я со многим согласен. Например проходя собеседование на go программиста, я ни разу не слышал глупые вопросы из разряда - как называется какая-то функция в таком-то фреймворке.
Интересная критика! Однако, касается ли ситуация с собеседованиями зарубежного сегмента (к примеру, США), или описанный опыт исключительно в рамках СНГ?
Я только что закончил съемки RubyRussia и мне очень-очень интересно, какая именно команда рубистов из Днепра имеется в виду?
Вброс на вентилятор засчитан. Если принять все описанное за чистую монету, то можно сделать вывод, что, автор так и не смог найти нормальной работы ни на PHP, ни на Ruby, автор получал "фидбэки", но не получил работу (иначе не было б такой статьи, или она была бы совсем другой). Может, тогда проблема не в языках?
Если ты любишь ruby, то посмотри в сторону Elixir и Phoenix framework - думаю, что тебе зайдёт. Синтаксис как у руби(что не удивительно - поскольку Jose Valim бывший участник rails core team), скорость как у эрланга(что также не удивительно)
Автору просто не повезло.
Проблема в том, что PHP очень сильно распространён и у PHP было очень сложное детство. В результате этого крайне высок шанс попасть на проект, где огромная куча неперевариваемого легаси, тупые коллеги, неадекватное руководство. Так получается во всех очень популярных сферах человеческой деятельности.
На самом же деле PHP последнее время очень стремительно развивается, фреймворки очень приятны в работе, инструментарий развит так же сильно, как у Python и JavaScript. Мне, например, нравится, что я за час могу собрать полнофункциональный REST API с полнофункциональной интерактивной документацией при помощи Symfony и API platform, а потом развивать его. Это позволяет нашей команде очень быстро вводить новые фичи в проект.
Конечно же, есть у этого языка недостатки и особенности, но они есть у всех языков. PHP неидеален, но он не так плох, как его малюют.
Php он как JS, был рожден для одного, а потом стал использоваться для другого. Да, из-за этого какие-то библиотечные вещи кажутся плохо продуманными. Лично мне кажется, что php используют не для того, для чего он предназначен, в этом вся беда. В этом плане тот же Ruby выглядит более идеологически выдержанным.
Что касается разрабов и мест работы. Мне близка мысль про то, что везде оно одно и тоже примерно. Есть хорошие специалисты, а есть весьма странные личности.
Лет 10 назад процент этих странных личностей в php зашкаливал, т.к. для php очень низкий порог входа, чтобы потом считать себя разработчиком.
Однако сейчас положение дел немного поменялось. С появлением всяких java-курсов и течения "войти в ИТ", появилось куча java-истов, которые ну немного до разраба не дотягивают. Можно тоже самое сейчас сказать про java, внятный хорошо сделанный проект с хорошей командой(ну то есть хорошее место работы) нужно ещё поискать. Про интервьюверов вообще молчу...
Те странные личности пришедшие в PHP 10 лет назад, о которых вы говорите, прошли удивительный путь. Они все так же считают себя разработчиками по формальным признакам. Теперь правда эти формальные признаки - разглагольствования на тему SOLID и REST, и прочих вещах выжимка из которых занимает 1 лист А4; или же настолько абстрактных что каждый может бесконечно трактовать их в рамках своей глупости, или ограниченного опыта.
Такие же твердолобые люди, но уже дослужившиеся до регламентов.
А что по поводу явистов-шарпистов. Да, у них тоже куча посредственностей. Но даже мне, буквально несколько раз и по ошибке, попавшему на собеседования на эти должности, даже самые вахтеры показались адекватнее чем пыховики. Там больше гоняют по языку, да, но и сам язык замкнутая экосистема, а не часть чего-то. Там языки более консистентые, что упрощает додумывание. Там выше бюджеты, что вообще способствует доброте.
Я могу ошибаться, абсолютизируя свой опыт, но, по сравнению с PHP-шниками, джависты и шарповики - милейшие люди. Они, по крайней мере, не такие воинственные.
Автор явно не заботился о политкорректности, но тема очень интересная. Психологический портрет кодера, тимлида, компании в зависимости от языка, на котором пишут. Полагаю в топе будет что-то типа Rust и Golang.
У популярных языков всегда будет проблема - на волне популярности они привлекают многих фанатов. Фанаты, глядя на свое количество, начинают думать: ну не может же такое количество людей ошибаться. Дальше логическая цепочка доходит до того, что мы выбрали самое лучшее раз нас много, а остальные - плохие, тупые, ретрограды, утята и т.п.
Есть те, кто пишет о том, как он отказался от какой-то технологии. А есть те, кто просто пишут код
Частично согласен. php - это синоним низкобюджетной разработки из-за которой страдают процессы в принципе. Качество кода, архитектура, тесты - это то чего не увидишь в подавляющем большинстве проектов. Про низкие зарплаты и так многим известно, но в последние года ситуация ощутимо начала исправляться из-за слабого притока новичков в данный стек. Мое мнение лучше выберите что-то более серьезное.
Дружище, ты видимо слишком много времени проводишь в цифровом мире из-за чего тебе просто не хватает обычного, человеческого общения и внимания ) Внимания и понимания от друзей и близких.
Автору советую попить валерьянки, или к врачу. Просто спичхейт
Исповедь неудачника.
PHP сейчас топчик вакансий куча, hr'ы сами пишут в больших количествах, а с достаточным уровнем синьорити на 3-5К можно претендовать без особых сложностей
Исповедь неудачника.
Скажите, почему я неудачник, если смог без потери уровня дохода изменить свою жизнь так как мне бы того хотелось? Ну вот устал я от хамского и наплевательского отношения рекрутеров к PHP-шникам из-за количества последних. Зачем мне это терпеть? В чем тут успех? Устал от коллег, большая часть из которых настолько ограничены, что при общении с ними постоянно приходится загонять себя в рамки?
PHP сейчас топчик вакансий куча,
Криптостартапы, мелкобизнес, обычные стартапы, где вам будут платить хоть 10 000 $ в месяц, при условии что вы запилите за месяц проект и он начнет приносить прибыль. Конвееры, где нужно делать по 3 сайта в месяц. В лучшем случае загнивающее легаси за кучу денег на какой-то пятой версии языка. MVP, которые мы когда-то перепишем. И постоянно горят сроки и очень много фич и очень мало денег, чтобы покрыть этот поток фич достаточным количеством разработчиков.
hr'ы сами пишут в больших количествах
То что вам пишет HR не значит ровным счетом ничего, кроме того что вы напихали в резюме достаточно ключевиков. Половина набирает базу резюме, остаток отваливается когда слышит зарплатную вилку, единицы готовы продолжить разговор.
а с достаточным уровнем синьорити на 3-5К можно претендовать без особых сложностей
Можно, но для этого требуется слишком много качеств, не связанных собственно с разработкой ПО, которой я и хотел как раз заниматься.
sed 's/PHP/<любой язык>/g;s/Laravel/<любой фреймворк>/g'
Суть статьи не поменяется.
В словах английского происхождения нет звука е, поэтому в скалькированных словах пишется е, но произносится э. Собственно на этом можно и закончить.
Не очень понимаю, к чему здесь ваш комментарий, но всё-таки: а что такое звук [е]? И чем он отличается от звука [э]?
Звук е есть в слове если, звук э есть в слове эти.
Поэтому Лайма Вайкуле произносится со свуком э в конце. Но у вас сейчас другая лигвистическая проблема, нужно учиться правильно произносить паляница.
Ещё с первого класса изучают, что буква е может обозначать один звук и 2 звука. В слове если это [йэ].
А с последним вашим предложением вы, по-моему, вообще заблудились.
Знаю я типаж таких программистов как этот автор. Обычно их возраст ближе к сорока, это в основной своей массе, проблемные люди, за редким исключением. Возраст конечно не главное (я сам ближе к 40), но тут больше риска. Они упёртые как бараны, верят в какую-то фигню и считают всех остальных, и вообще все PHP сообщество дебилами. Типа все такие дураки в мире, придумали всякие бесполезные SOLID, Паттерны, PSR, фреймворки и т.д., и только "я все шарю". Это низковалифицированные, оторванные от реальности люди, говнокодеры. Обычно про таких людей все становтися понятно после 5-10 минут интервью. После этого их проганяют ссаной тряпкой ("вопросов больше нет, мы дадим наш ответ") и они идут на следующее собеседование. Автор этой статьи точно такой же, он сам утверждает что прошел 200 собеседований за последние 10 лет. Ни один вменяемый человек не ходит на такое кол-во собеседований за 10 лет. Это человек, который ни в одном коллективе не может ужиться, и горе той компании, у который некомпетентный HR все-таки взял его на работу.
Именно. Я вот с PHP работаю с 2008-го года. Был от силы на трёх десятках собеседований за всю карьеру. И то большинство было когда я усиленно искал работу (и когда работал с D7 битрикса, лол).
Знаю я типаж таких программистах как этот автор. Обычно их возраст ближе к сорока, это в основной своей массе, проблемные люди, за редким исключением. Возраст конечно не главное (я сам ближе к 40), но тут больше риска. Они упёртые как бараны, верят в какую-то фигню и считают всех остальных, и вообще все PHP сообщество дебилами. Типа все такие дураки в мире, придумали всякие бесполезные SOLID, Паттерны, PSR, фреймворки и т.д., и только "я все шарю". Это низковалифицированные, оторванные от реальности люди, говнокодеры.
Вы верно описали типаж в принципе, но это не про меня. Во-первых я сам ругаюсь на упертость(швитой SOLID, твой любимый паттерн). Во-вторых я против того чтобы меня считали дебилом-неосилятором например за то, что я не использую IDE. В третьих я не считаю, что я все шарю. Возможно чуть больше из-за того что у меня 2 ст[еэ]ка и много амбиций по деньгам, вследствие чего много мест работы и собеседований.
Обычно про таких людей все становтися понятно после 5-10 минут интервью. После этого их проганяют ссаной тряпкой ("вопросов больше нет, мы дадим наш ответ") и они идут на следующее собеседование.
Нет, такого не припомню.
Автор этой статьи точно такой же, он сам утверждает что прошел 200 собеседований за последние 10 лет. Ни один вменяемый человек не ходит на такое кол-во собеседований за 10 лет.
Ну смотрите, одна смена места работы у меня может занять до 30 собеседований, в каждом может быть несколько раундов, литкод, общие вопросы, СЕО. Повторюсь, если просить 4000-5000 $ . Если брать ниже - то на первом-втором уже можно пройти. В связи с ковидом и СВО многие компания сокращали штат, закрывались, отказывались работать с выходцами из РФ, что участило поиск мной работы. И я подвел итог.
Это человек, который ни в одном коллективе не может ужиться, и горе той компании, у который некомпетентный HR все-таки взял его на работу.
Воистину, горе той компании, где решение о принятии на работу принимает HR. Я уживаюсь в коллективах не хуже других, но делать вид что я верю в то, во что не верю для меня достаточно некомфортно.
IMHO, всю статью можно было свести к простому тезису: рынок PHP пересыщен, что позволяет работодателю выпендриваться, а на рынке Ruby пока ещё спрос выше предложения, что позволяет выпендриваться уже соискателю.
Почему PHP — это моя ошибка