Вы так говорите, будто фреймворк — это что-то особо сложное, что нужно прям учить. Я полагаю, под фреймворком вы понимаете такой набор: роутер, шаблонизатор, тесты, читалку конфигов, какой-нибудь событийный компонент, обёртку вокруг крона, ну и конечно же ормку.
А теперь скажите, за сколько я должен разобраться с новой читалкой конфигов, роутером или ормкой, если я их видел уже штук 20 и они делают примерно одно и то же? Вы вероятно скажете «ну полчаса, документацию глянуть и несколько примеров посмотреть».
То же самое и в целом. Нет ничего в этих ваших веб-фреймворках такого уж сложного, всё везде у всех одинаковое, только методы по-другому называются и внутренняя структура немного разнится. И нормальный опытный разработчик, сев за очередной такой фрейморк через пару часов (если тот прям очень сильно похож на остальные) в лучшем случае и пару дней (если где-то много магии наворотили) в худшем вполне сможет выдавать нормальный код с приемлемой скоростью.
Так что нет, ничего поверхностного здесь нет, как и ничего сложного в обсуждаемом вопросе.
С го это чуть более оправданно, потому что слово слишком короткое и очень часто используется, и просто в разговорной речи и в названиях продуктов (pokemon go, amazon go, тд) в итоге что-то гуглить становится очень сложно. Пусть лучше уж golang, это более уникальное слово, сразу задаётся нужный контекст.
С контекстами есть такая проблема, что они не дают возможности управлять порядком завершения компонентов, а также отследить момент, когда они все успешно завершаться. Примерно как если бы вы заглянули в комнату, крикнули «эй, завершитесь!», и пошли дальше, не интересуясь, что там дальше будет (ломанутся ли они все вместе одновременно в дверь, начав конфликтовать, очнутся ли только через сутки и тд и тп).
Я не так давно писал статью об том, как это делать: habr.com/ru/company/vivid_money/blog/531822
Думаю, вы сможете переиспользовать какие-то паттерны из последнего рассмотренного мной подхода.
Не понял, к чему здесь «вашесть» рынка. Я говорю о том, что при приёме работу зачастую учитываются незначимые вещи и при этом упускаются из виду значимые. К примеру, знание фреймворка Х часто ничего не стоит, но легко проверяется. А знания системного дизайна как правило крайне важны в работе, но их не так просто проверить и поэтому их просто игнорируют.
Если уж меряться ресурсами, то я бы не останавливался на PHP, а взял бы тот же Golang, который (имхо) будет в целом производительнее и куда экономичнее.
А насчёт джавы, то там сразу начинается много вопросов: а как настроили JVM, а какой сборщик мусора взяли и тд и тп. Но да, не спорю, вероятно она будет «есть» больше. С другой стороны, там внутри столько оптимизаций (кстати, стало любопытно и я сходу не смог нагуглить, в PHP есть к примеру векторизация циклов?), то я бы ожидал, что в работе она будет производительнее.
Вы ошибочно посчитали, что главная мысль статьи заключается в том, что «PHP не нужен». При этом даже я сам так не считаю и таких утверждений не писал. Более того, мне нравится и PHP, и то, куда он идет.
О чём статья писалась, так это о том, что PHP пытается быть «серьезным» языком с ООП, дженериками и прочими штуками, что хорошо для энтерпрайза, но противоречит тому, что и сделало PHP популярным: простоте. Потому что если новичок должен для того, чтобы найти свою первую работу, знать кучу всего, то ему сразу очень сложно и очень многие уйдут туда, где проще.
Детальное же сравнение PHP и Java давайте оставим какой-нибудь отдельной статье, я специально не углублялся в детали, чтобы не раздувать текст техническими подробностями. Да и статья бы тогда называлась «сравнение PHP и Java», больно уж много всего придётся затронуть.
Ну, во-первых, я не писал, что вообще все фреймворки всегда учатся за 2 часа, также не упоминая и что есть «изучение». А во вторых, они все одинаковые. Роутеры, конфиги, контроллеры, миграции, папочки с кодовыми именами, стандарты… Если вы достаточно опытны, то вы любую задачу разобьете на набор технических подзадач и сможете легко их загуглить, вида «как объявить хендлер во фреймворке Х», ну или подглядеть их в каком-нибудь из опубликованных демонстрационных проектов.
В итоге эти 2 часа вы потратите на то, чтобы в целом изучить архитектуру фреймворка и набор его компонентов, а потом сможете сравнительно легко нагуглить нужный рецепт.
Также не очень понятно, чем «осознанно рулить ситуацией» в проекте на Х будет отличаться в «осознанном рулении ситуацией» в проекте на Y. Набор подходов везде примерно один и тот же, проблемы и методы их решения тоже (даже не упоминая волшебного слова «паттерн»).
Наверное, вызубривать наизусть все хитрости и какие-нибудь особенно тонкие тонкости (кстати, какие?) вы будете немного дольше, но для большинства задач этого просто не требуется.
Но даже допустим вы правы и изучение фреймворка до уровня неписанных правил/практик/etc и полной осознанности занимает пару недель и вам необходим именно такой уровень. В такой ситуации, вы действительно откажете сеньору, который за всего полмесяца способен стать идеальным сотрудником? При том, что он скорее всего несет в себе многолетний багаж пользы? Звучит по-прежнему странно.
Всегда очень удивляюсь, когда компания отвергает кандидатов по признаку "не знал фреймворк Х". Ну не знал, и что?
Фреймворков тысячи и все примерно одинаковые. Знание от незнания отделяет в лучшем случае пара дней изучения, а чаще пара часов.
Так вот: вы действительно готовы оказать сеньору (то есть человеку с огромным опытом решения задач и глубокими познаниями в разных технических областях) только из-за того, что он не знает свистелку Х?
Мне казалось, что сеньор на то и сеньор, что способен эффективно решить (или научиться эффективно решать) в целом любую задачу любым инструментом.
Думал о том же, пока читал исходный комментарий.
Пример с машиной некорректен потому, что в нем просят продемонстрировать вождение, то есть то, что и будет делать водитель.
В случае же с кодом, практически никто и практически никогда не пишет сортировку массива руками. Да, это несложно, но это не тот навык, который требуется в повседневной работе, если несколько лет не писал ту же быструю сортировку, то мелочи забываются, нужно перед собеседованием их из головы достать и дома повспоминать, чтобы не тупить потом за столом.
В конечном счёте это означает, что кандидату нужно поддерживать два набора навыков, отдельно для рабрты и отдельно для прохождения собеседований. А это странно.
А теперь скажите, за сколько я должен разобраться с новой читалкой конфигов, роутером или ормкой, если я их видел уже штук 20 и они делают примерно одно и то же? Вы вероятно скажете «ну полчаса, документацию глянуть и несколько примеров посмотреть».
То же самое и в целом. Нет ничего в этих ваших веб-фреймворках такого уж сложного, всё везде у всех одинаковое, только методы по-другому называются и внутренняя структура немного разнится. И нормальный опытный разработчик, сев за очередной такой фрейморк через пару часов (если тот прям очень сильно похож на остальные) в лучшем случае и пару дней (если где-то много магии наворотили) в худшем вполне сможет выдавать нормальный код с приемлемой скоростью.
Так что нет, ничего поверхностного здесь нет, как и ничего сложного в обсуждаемом вопросе.
Я не так давно писал статью об том, как это делать: habr.com/ru/company/vivid_money/blog/531822
Думаю, вы сможете переиспользовать какие-то паттерны из последнего рассмотренного мной подхода.
А насчёт джавы, то там сразу начинается много вопросов: а как настроили JVM, а какой сборщик мусора взяли и тд и тп. Но да, не спорю, вероятно она будет «есть» больше. С другой стороны, там внутри столько оптимизаций (кстати, стало любопытно и я сходу не смог нагуглить, в PHP есть к примеру векторизация циклов?), то я бы ожидал, что в работе она будет производительнее.
О чём статья писалась, так это о том, что PHP пытается быть «серьезным» языком с ООП, дженериками и прочими штуками, что хорошо для энтерпрайза, но противоречит тому, что и сделало PHP популярным: простоте. Потому что если новичок должен для того, чтобы найти свою первую работу, знать кучу всего, то ему сразу очень сложно и очень многие уйдут туда, где проще.
Детальное же сравнение PHP и Java давайте оставим какой-нибудь отдельной статье, я специально не углублялся в детали, чтобы не раздувать текст техническими подробностями. Да и статья бы тогда называлась «сравнение PHP и Java», больно уж много всего придётся затронуть.
В итоге эти 2 часа вы потратите на то, чтобы в целом изучить архитектуру фреймворка и набор его компонентов, а потом сможете сравнительно легко нагуглить нужный рецепт.
Также не очень понятно, чем «осознанно рулить ситуацией» в проекте на Х будет отличаться в «осознанном рулении ситуацией» в проекте на Y. Набор подходов везде примерно один и тот же, проблемы и методы их решения тоже (даже не упоминая волшебного слова «паттерн»).
Наверное, вызубривать наизусть все хитрости и какие-нибудь особенно тонкие тонкости (кстати, какие?) вы будете немного дольше, но для большинства задач этого просто не требуется.
Но даже допустим вы правы и изучение фреймворка до уровня неписанных правил/практик/etc и полной осознанности занимает пару недель и вам необходим именно такой уровень. В такой ситуации, вы действительно откажете сеньору, который за всего полмесяца способен стать идеальным сотрудником? При том, что он скорее всего несет в себе многолетний багаж пользы? Звучит по-прежнему странно.
Всегда очень удивляюсь, когда компания отвергает кандидатов по признаку "не знал фреймворк Х". Ну не знал, и что?
Фреймворков тысячи и все примерно одинаковые. Знание от незнания отделяет в лучшем случае пара дней изучения, а чаще пара часов.
Так вот: вы действительно готовы оказать сеньору (то есть человеку с огромным опытом решения задач и глубокими познаниями в разных технических областях) только из-за того, что он не знает свистелку Х?
Мне казалось, что сеньор на то и сеньор, что способен эффективно решить (или научиться эффективно решать) в целом любую задачу любым инструментом.
Думал о том же, пока читал исходный комментарий.
Пример с машиной некорректен потому, что в нем просят продемонстрировать вождение, то есть то, что и будет делать водитель.
В случае же с кодом, практически никто и практически никогда не пишет сортировку массива руками. Да, это несложно, но это не тот навык, который требуется в повседневной работе, если несколько лет не писал ту же быструю сортировку, то мелочи забываются, нужно перед собеседованием их из головы достать и дома повспоминать, чтобы не тупить потом за столом.
В конечном счёте это означает, что кандидату нужно поддерживать два набора навыков, отдельно для рабрты и отдельно для прохождения собеседований. А это странно.