×Закрыть

PHP чи Python в 2019?

Всім привіт!

Ситуація наступна: 2 роки в моушн дизайні та відео едітингу дали мені зрозуміти що мій склад розуму швидше аналітичний ніж творчий.

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

Так вот питання, яку мову обрати? Десятки відео, статей і тд не дали мені чіткого розуміння що ж краще php чи python? Може тут допоможуть... Дивлюся на перспективу а не тільки на ситуацію на ринку зараз...

LinkedIn

Лучшие комментарии пропустить

Я позащищаю пыху, поскольку она с каждым релизом начиная с ноября 2015 года становится всё лучше и быстрее и заслуживает того, чтобы отмыться от дерьма, налипшего на неё в нулевых и ранних десятых (небезосновательно). Сейчас последняя пыха значительно быстрее последнего пайтона, например: (и не только пайтона, а и руби и nodeJs тоже!)
benchmarksgame-team.pages.debian.net/...​marksgame/faster/php.html

И с каждой версией пыхи её производительность растёт на 10-15%.
www.phoronix.com/...​.3-Performance-Benchmarks

В ней появились статические типы данных (необязательные, но появились), наконец-то полностью устранили все утечки памяти и можно писать демоны, не перезапуская их раз в час (у меня в продакшне демоны на php 7.2 живут в среднем 14 дней (от релиза спринта до релиза следующего без перезапуска), а отдельные — по месяцу и более). И нет утечек. Вообще.

Веб-фреймворк симфони на голову превосходит джанго по абстрактности (гибкости) объектных моделей, в нем нет повсеместных статических вызовов как laravel, в нем принудительно везде dependency injection, он заставляет писать объектно и тестируемо.

Работы именно по вебу на PHP/Symfony столько же или больше, чем на Django, на PHP/Laravel — больше в разы. Если брать в весь PHP-мир, включая CMS — в десяток раз.

Тебе я бы порекомендовал вкатываться в PHP-мир через Laravel, там очень низкий порог входа и можно начать зарабатывать сразу, но при этом не такой низкий, как у CMS, чтобы не конкурировать с индусами. Когда в голове уложится OOP, DI и научишься писать без статики — велкам в симфу. Ап по зарплате приложится.

Что до пайтона — ему нет равных в разной околонауке, куча либ для неё, если захочешь вкатываться с целью потом в machine learning задержаться или в распознавании образов, то лучше с пайтона начинать. Но есть риск неосилить порог.

Здравствуйте. Меня зовут Вячеслав, мне 22 года и я пхп программист. Я сижу на пхп с 18 лет. Первый раз я попробовал пхп с другом. Мы сидели, обсуждали веб-технологии и тут он сказал, что недавно пробовал пхп. Он предложил попробовать мне. Поначалу я не согласился, ведь это пхп, я слышал много плохих слухов про него, слышал, что он вызывает зависимость. Но друг настаивал, говорил, что в жизни нужно попробовать все и я сдался. Он предложил бесплатный скрипт, выводящий «Hello world!». Он казался совсем безобидным, но как потом оказалось, я уже не мог остановиться.

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

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

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

Папа, а шо лучче — пулімьот чи танк?

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Вы сравниваете теплое с мягким

А може пояснити свою думку? Конкретніше — чому на один рівень Go і Rust ставите.

Бо і Go і Rust мають хорошу швидкодію, тести з коробки, бенчмарки, автоформатування коду, збираються в один бінарник так що Docker image важить ~ 20-30 мегабайт

Тільки от автор питає про дві інші мови. За які Rust значно складніший, як мені здалося. Плюс на ньому ще поки не так багато бекенду пишуть. Хіба автор на далеку перспективу обирає мову...

Так складніше але й ресурсів значно меньше споживає, мене бентежить, що власникам бізнесу простіше докупити RAM та CPU на ~100$ ніж розробити якісний продукт

Імхо, справа не тільки в тому, скільки врешті продукт ресурсів споживає, а ще й в швидкості розробки, вже існуючому стеку технологій у кастомера, вартості девелоперів і ще купа факторів.
А щодо Rust, як мені здається, хайпу не буде доки великі компанії не почнуть його адоптити. Він же відносно молодий. Схоже, його ще бояться широко впроваджувати. Але це не точно :)

ЯП — это инструмент, кому-то нравится что-бы класно лежал в руке, кому-то тяжелее-медленее, другим легче и быстрее. Есть универсальные и узкоспециализированные. К первому относится python, ко второму php. Перейти на другой язык, это плевое дело. Концепция программирования не в ЯП, а в подходе, у всех ЯП подход пересекается. Другими словами, какая нафиг разница что сейчас выберешь, потом сможешь поменять если достанет.

Однозначно PHP, смотри на кол. фреймворков, существование CMS. А что есть есть в python для web? только dajngo и flask. Также вакансий у php в разы больше, и что бы там не говорили, так оно и будет далее по вакансиям. PHP не умрет. Работы как в конторах, веб студиях и на фрилансе куча по php/framework/cms. А ситуация python/django скудная.

А что есть есть в python для web? только dajngo и flask.

Не только. Есть еще Bottle.py, Toprnado, CherryPy, Web2py, и еще несколько. Хотя да, для PHP фреймворков в разы больше.

Не залазя в механику самих языков и их окружения ... зависит от того какие перспективы хочется.

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

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

Бекенд это уже точно осознанный выбор?
Потому что PHP это только веб-бекенд.
А Python это потенциально много что(и десктоп, и железо,...). Кроме того его популярность сейчас растет в первую очередь за счет AI/ML и это потенциально перспективно
(но конечно это не та сфера куда стоит соваться сразу после видеодизайна)

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

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

Десятки відео, статей і тд не дали мені чіткого розуміння що ж краще php чи python?

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

.net конечно же)))) Причем тут java, человек про нее не спрашивал.

Может он просто не знает, что есть такой язык программирования)

Конечно питон. Если ты выбираешь пыху то ты обречен заниматься только веб разработкой. Питон же это: веб, машинное обучение, биг дата, ДевОпс штучки, геймдев и даже эмбеддед разработка, так что если тебе надоест двигаться в каком-то направлении ты всегда можешь попробовать что-то новое не меняя языка программирования.

Так ніби мова програмування має велике значення в перечисленому, і не можна іншу вивчити при зміні області.

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

Приветствую любителей языка Python! Вот тут (codeby.net/...​-na-python-chast-1.65954) можно подробно почитать как писать графическую оболочку на Python.

PHP можно сравнить с телефонами Xiaomi. «Норм за свои деньги».

Я теперь без слёз не смогу на свой телефон смотреть :(
Придется его менять...

через 5 лет то что ты написал на пыхе уже не будет работать
потому что пыхари выкинут нафиг из пыхи все методы которые им не нравятся

Не те що пітоністи з backward compatibility в python 3

Сумісність 2 і 3 гілок — це загальновідома проблема.
Але у межах гілок 2.x та 3.x вона зразкова — коли приїжджають апдейти і піднімають мінорну версію пітона, то можна не боятись, що щось поламається.

также как и php 5 и 7 веток — «це загальновідома проблема»

ні, там ще гірше — навіть мінорні версії php 5.x мали зворотні несумісності, через які ми до сих пір маємо тримати на хостах зоопарк з 5.2, 5.3, 5.6

сподіваюсь, хоч із 7.x такого не буде

Для этого на сайте PHP есть «Migrating from PHP 5.x to PHP 5.y» — было бы желание допилить продукт...

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

Внимательно изучите эту статистику и должно Вам всё стать понятно dou.ua/...​language-rating-jan-2019

Если хочется окунуться в мир WebDev — попробуйте PHP7 + Symfony/Laravel + MySQL/memcache и для полной картины JavaScript (HTML/CSS — само собой). Под PHP сразу щупайте Swoole — тут вам и асинхронность и всё такое «интересное», чего не было в PHP начала нулевых и что породило массу хейтеров и фукальщиков. А дальше Node.js + Angular/React/Vue/... В идеале — пощупать всю мощь языков без использования фреймворков, так сказать развивать «умение писать с нуля», используя базовые средства но без фанатизма. Главное — НЕ ЧИТАТЬ книги по PHP 3х-летней давности или более древние. Удачи!
P.S.: и не вздумай в HTML использовать inline CSS или inline JavaScript — уж лучше сразу оторви себе руки, чтоб не пополнять мир говнокодерами.

Замутил бы голосовалку. Вообще учить php довольно муторно. Питон проще. На переспективу учите многопоточное программирование, основы БД или математику, а не язык.

С чего вдруг PHP стало муторно учить? Дока на php.net с примерами вполне исчерпывающая. Синтаксис приятный, классы С-подобные. Правда, иногда, присутствует 101 неочевидный способ выстрелить себе в ногу, но это лишь подчёркивает гибкость языка и неумение некоторых его готовить. Если быть объективным, то всё то за что ругают PHP, очень часто нахваливают в JavaScript/ECMAScript, при том что туда нормальные классы только-только начали подвозить...

По сравнению с python и если начинать с 7-го муторно. А если не начинать с 7-го — то смотрите другие коменты. «нормальные классы» это шикарное определение. Не пофиг ли вам, какие классы если они все признаки классов имеют и работают?

...классы С-подобные... всё то за что ругают PHP, очень часто нахваливают в JavaScript/ECMAScript, при том что туда нормальные классы только-только начали подвозить...

Культ карго?

Ломай систему, не будь как все crystal-lang.org

Очередной «нетакой как все» язык, тысячи их. Рынка нет, сообщества нет. Зато не как все.

Ну так, потому что все боятся потому и нет. Взяли бы и свичнулись всем стеком)

crystal — це рубі-подібна мова, яка компілюється в бінарний код, так що вона і не дуже вже «не така».

ТС, скажу просто, на чем нравится больше на том и пиши, разберешся хорошо,будешь деньги получать в любом случае

«Склад розуму» це ілюзія. Той факт, що ти стрибаєш між різними видами діяльності означає, що у тебе (як й у багатьох) лінивий мозок, який вигадує будь що, аби нічого не робити :)

Логіка в цьому є, проте, мабуть, це не про мій випадок. Заробляти в дизайні як мідли в софтдеві і вже плюс мінус шарити як там все працює і вирішити почати все з повного нуля в далеко не найлегшому напрямку, як от програмування... не впевнений що це ознака ліні)

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

Не знаешь какой язык учить — учи английский.
При любом раскладе, если решите идти в бекенд — начните с HTML/CSS, в этом поможет htmlacademy.ru

Вільно спілкуюсь англійською, досить добре розбираюсь в html css...
Тому й виникло питання вибору найоптимальнішої мови для входу в вебдев.
Компетентність в питанні мінімальна, тому й постановка питання мабуть не до кінця правильна. Але тут ітак 90% тролінгу або холівару, хоча 10% коментарів були корисними. Всім дякую.

досить добре розбираюсь в html css...

Фронтенд. Кадрів толкових напевно брак, вакансій більше ніж на будь-якій бекенд мові. Зарплати доганяють джавовські.

если решите идти в бекенд — начните с HTML/CSS

Што, простите?

То. Нужно понимать что такое теги и принцип их стилизации. Чтобы при малейшем чихе не тупить и не звать эникейщика — фронтендера.

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

При любом раскладе, если решите идти в бекенд — начните с HTML/CSS

Ты чето попутал слегка

ничего я не попутал, видел бекендров, которые с наскоку лезли в похапэ и не видели вложенность/не закрытость тегов

зачем тебе хтмл и цсс, если ты пишешь бэк для мобилы, например?

Что лучше преферанс или очко?

З бейсіка почни;)

Папа, а шо лучче — пулімьот чи танк?

танк, по пулімьоту раз п***не й п**дарики)))

Я отцу действительно этот вопрос задавал в три года. На что он мне сначала рассказал, выражаясь по-взрослому, об основах боевого применения и пулемета, и танка, но итоговый ответ был таков: «вообще, конечно, танк, потому что у танка самого есть пулемет».

А если у танка некомплект и пулемет снят?)

А если у танка некомплект и пулемет снят?)

Хошь верь, хошь нет, а про снятый пулемет мне отец тоже упомянул тогда. И еще добавил «а пехота с гранатометами».

Гловне в танку буде ахвіцер чи командір

в танку головне не всратися

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

Судя по тому, что человек никому ничего пока не ответил, то могу предположить что это «пятничная тема».
Если по сути, то все зависит от приоритетов:
1. Если задача «найти работу побыстрее», то стоит смотреть на php — работы все же больше.
2. Если хочется программировать на том языке, который нравиться, то что мешает попробовать оба, а по ходу решить какой больше нравиться. Для «быстрой пробы» советую metanit.com
Если говорит о «перспективе», то тут тоже все зависит от приоритетов.

Задача стоїть в виборі мови, яка буде найоптимальнішою для входу в веб програмування... а з досвідом подібні дурні питання зникнуть і з’явиться бачення який напрямок ближчий і куди рухатись далі...

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

Так вот питання, яку мову обрати?

Если таки сомневаетесь, то могу посоветовать изучить... haxe.org :-)
Ну хотя бы потому, что Haxe (как показано вот здесь haxe.org/...​ion/compiler-targets.html ) может компилировать и в PHP, и в Python. ;-) А также в JS, C++, C#, Java, Lua и даже в некогда популярный, но уже мало кому нужный и умирающий Flash.

Ну прям шестизарядник (Greatoshoto) — был такой, пожалуй, самый универсальный трансформер в одноименном аниме.

А python тоже можно скомпилировать в php и php в питон. И что? Вопрос в качестве полученного кода.

И каково качество полученного кода у предлагаемых Вами вариантов (из пхп в питон и из питона в пхп) по сравнению с Haxe?

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

Выбери PHP чтобы всю жизнь доказывать «это в ранние десятые он был дерьмом, сейчас уже все хорошо».
Выбери Python чтобы получать от программирования удовольствие (и никому ничего не доказывать).

Выбери php и начни зарабатывать на ранних стадиях, выбери python для web и может за лет так 5 проканает какая-то вакансия по питону(и ясен пень джуном).

Охтыжлол... А потом они удивляются, что у пыха такая репутация.

Так а php процентов так 70 если не больше начинающих веб разрабов выбирают только для того что бы начать по быстрее зарабатывать, изучив основы и немного oop. Сейчас какой видеоурок по php не открой так везде вбивают в голову что мол учите php и сможете заработать уже первые деньги через 2 месяца. Пока заказчик не заявит что хочу что то на фреймворке, и тут все, понимаешь что не такой уже и низкий порог вхождения сейчас в php, смотря на то какие стеки требуются в вакансиях, что бы зарабатывать уже не копейки за простые визитки.

відео едітингу
яку мову обрати?

Українську. :)

PHP > 7 версии отличный язык все Хейтеры застрял в начале нулевых.

1 коментар і в підтримку php.

Бот детектед!!! Скільки тобі Расмус Лердорф заплатив?!

Та біда ж в тому що більшість программістів там само застрягли
Ну і якщо вже бути точним то в початку десятих ;)
3 December 2015 — дата релізу PHP 7.0

Однозначно Python, на нем сейчас пишут все и везде, классный и простой синтаксис, удобно и не напряжно)
Удачи!)

>>классный и простой синтаксис
>>синтаксис с отступами
Выберите одно

Це ви певно синтаксис з фігурними дужками і крапка з комою не пробували ;)

Пробовал, сейчас полностью на плюсах сижу, но с Python в сердце)

А что, там уже классы нормальные родили, хотя бы на уровне того же PHP? Или традиционно через *опу к звёздам как в ECMA Script (JavaScript)?

А универсальность Python не нравится?)
Классы это отдельный разговор в этом языке, отличие от других.) Почему-то всё больше и больше компаний на него переходит.

Человек под WebDev спрашивает. Более того, в PHP подвезли FFI, а это значит что ты можешь использовать теперь любую системную *.so либу — универсальности полные штаны на перспективу ))) Как по мне, так python после классических ЯП отпугивает своим синтаксисом, меня отсутствие «{» и «}» в логических блоках просто загоняет в ступор. Второй момент: многие рассматривают PHP исключительно в связке с web-сервером, что ошибочно. Есть вполне зрелый и самодостаточный CLI-SAPI, и на нём используя SWOOLE или ReactPHP можно таки писать взрослые сервисы, которые практически ноздря в ноздрю топают с тем же Node.js. Открою секрет, JIT тоже подвезли в PHP ещё с 5.6 (или даже раньше) только толку от него не в CLI-SAPI мало.

Со всем согласен, кроме jit’а. Не подвезли его в php ещё, если речь про opcache, то это несколько другое.

Но есть и хорошая новость, относительно свежая:
wiki.php.net/rfc/jit

we propose to consider including JIT in PHP 7.4 as an experimental feature

Да, вы правы, с JIT я таки погорячился )))

Переписываем продукт с РНР на Python:
jobs.dou.ua/...​s/lun-ua/vacancies/72327

Ну таке. І з джави знають переписувати, і з шарпа. І напевне з пітона теж переписують, хоча не на пхп скоріше.

DOU спочатку був на PHP (WordPress), а потім переписали на Python (Django).

А зачем Go? может сразу на java ? :)

Шоб потім на Kotlin а з Kotlin на Go?

Ну так может проблема не в PHP а в морально устаревшем фреймворке?..

Я думаю, что проблема в том, что там Yii, а не в PHP. Это редкое дерьмо, начинал с него. Ну либо околонаучные либы в проекте понадобились. Я думаю, и то и другое.

Коли проект скотився в какаху і приходиться робити повний рефакторинг — ніщо не заважає взяти інший стьок, якщо є серйозне бажання і час його вивчити. Один фіг з нуля писати.

Любопытно по каким критериям вы Yii к дерьму отнесли ? К примеру у меня был некоторый культурный шок когда обнаружил, что в симфони использовать комментарии как код в порядке вещей. На Yii я давненько ничего не писал, но в сравнении с codigniter, yii, symfony, laravel. Мне трудно выделить какой-то из них в совсем уже булшит. Расмус так вообще их все с говном смешал за дикую избыточность.

док блок не комментарии, аннотации — код

Расмус так вообще их все с говном смешал за дикую избыточность.

И правильно сделал, мне кажется
Все что больше Slim дико избыточно

Любопытно по каким критериям вы Yii к дерьму отнесли ?

Во-первых, я к дерьму отношу только Yii1. У Yii2 были использованы гораздо лучшие практики и вообще он выглядит сегодня довольно современно и хорошо (на уровне с ларавелом), но его основная проблема, ИМХО, те, кто переехал на него с Yii1 и продолжает писать как раньше. И в чем самая большая проблема, ИМХО, Yii2 не заставляет писать правильно, более того, в официальных кукбуках пишут способы, которые прямо нарушают SOLID. А разрабы Yii ссылаются потом на свои кукбуки и следовательно пишут говно. Сейчас, может, стало лучше, время не стоит на месте, но когда только Yii2 вышел и я приглядывался к нему, от кукбуков у меня наворачивались слезы.

Во-вторых, если говорить про Yii1, то лично я нахлебался их концепции «толстых моделей» по самое небалуйся. Открываешь какую-нибудь модель Order, а там 3000 строк и всё вперемешку — бизнес-логика, запросы в базу через activeRecord, какие-то кастомные сеттеры/геттеры, валидация пользовательского ввода и всё public static. При этом по проекту к этой модели куча обращений к несуществующим свойствам и методам, типа должны разрулить магические методы.

В-третьих, опять же, где-то в глубине форумов Yii1 от серьезных дядь в постах годов так 2009ых я все-таки встречал правильные, но жутко непопулярные концепции организации слоистой архитектуры, выделения бизнес-логики туда, запросов в БД — сюда, валидаций в третье место и использование для связки всего этого контейнера Yii::app(). Конечно, не из коробки, надо было что-то самому из паттернов реализовывать, но хотя-бы это было похоже на код на языках общего назначения тех лет (на джаву, c#) и это можно было поддерживать. Реакция коммьюнити Yii была резко негативной: «ета жиж rapid fremwork нада бистра-бистра, а это всё овирхед, вали в свою джаву задр». И когда я годик хлебал это всё в 2013, нормальных ребят в Yii1 уже не было и постов на форумах типа «давайте сделаем слоистую архитектуру без статических вызовов» уже не было.
А статические вызовы — это не ООП. Это процедурщина с классами.

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

Это аннотации называется. Тебе надо долго и вдумчиво читать про метапрограммирование: ru.wikipedia.org/...​wiki/Метапрограммирование

Это есть везде давным давно, даже в ВУЗе мне это преподавали, когда мы изучали C#, EF, LINQ. Когда к этому привыкаешь, то уже не укладывается в голову, что надо например для валидации инпута писать внутри толстой модели метод самому! А ведь в Yii и не такое писали в толстой модели...

Мне трудно выделить какой-то из них в совсем уже булшит.

Так это от версий зависит. Если сравнить то, что было с этими фреймворками в начале десятых, то были очень серьезные отличия. Вплоть до того, что кодигнайтер был вообще местами процедурный, Yii1 — процедурщина с классами, ларавел уже давал возможность писать объектно, но не заставлял, а симфа, даже 1 симфа, которую я почти не видел, уже легонько толкала тебя в сторону хорошего. Вторая и далее симфы начали навязчиво заставлять, делая свои требования все строже и строже. Уже в 4 симфе нельзя из контейнера сервис достать по-умолчанию, только если ты public:true пропишешь для сервиса, чтоб тебе не пришло в голову контейнер инжектить. Защита от дурака, так сказать. Где эта защита от дурака в перечисленных трех?..

Саме жахливе що нема згоди по стандартам між фреймворками і мовами. В результаті всюди пишуть як художники, і фіг переконаєш, бо про існування кращих практик поза межами їх рапід стьоку не знають і не хочуть знати.

Саме жахливе що нема згоди по стандартам між фреймворками

www.php-fig.org
У цієї штуки досить непогано виходило, принаймі на рівні PHP, але все поламалось :(

Саме жахливе що нема згоди по стандартам між фреймворками і мовами.

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

Новые языки и фреймворки появляются потому, что их авторов не устраивают существующие (ваш кэп)

Та ні, тому що хочуть урвати ринок і заробити. А от деви чи хто вже обирають нові бо не влаштовують існуючі. Або так просто модно на даний період. З рештою погоджуюсь.

Интересный лонгрид на тему архитектуры, но самый прикол в том, что yii2 не навязывает вам архитектуру ( если не брать во внимание Ar как основу всего) — ее навязывает выбранный вами шаблон , по типу адвансед.

И никто вас не заставляет писать огромные модели — выделяйте все в сервисы, репозитории и декораторы, для валидаций используйте отдельные модели (не ar), запросы и скоупы видимости вместе со всеми бд-шными штуками юзайте через aq и будет щастя.

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

Yii2 лишь даёт вам инструмент, и действительно я считаю его королем в области «сделать по Шурику» но поверьте, и в больших сложных ddd проектах его вполне можно юзать ( да впринципе при ddd и фреймворк и даже язык ± сменить легко).

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

Что там по yii3?))

Интересный лонгрид на тему архитектуры, но самый прикол в том, что yii2 не навязывает вам архитектуру ( если не брать во внимание Ar как основу всего) — ее навязывает выбранный вами шаблон , по типу адвансед.

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

И никто вас не заставляет писать огромные модели — выделяйте все в сервисы, репозитории и декораторы, для валидаций используйте отдельные модели (не ar), запросы и скоупы видимости вместе со всеми бд-шными штуками юзайте через aq и будет щастя.

Почитайте, я про Yii1 говорил же. Первую версию. Вот от неё я плевался по-настоящему. Это именно там в первую очередь приучали разрабов к толстым моделям и статическим вызовам, магии на каждом шагу, публичным свойствам... А когда в Yii2 уже дали нормальные инструменты для работы, стало можно из коробки писать объектно и слоисто, коммьюнити то не поменялось. Они как в первой версии писали, так продолжили писать и во второй, обзывая все эти репозитории и декораторы оверхедом. Yii2 в своей нише rapid development выглядит сейчас неплохо на нем должно быть удобно накидывать быстро прототипы и он дает возможность потом всё зарефакторить и сделать поддерживаемым, если всё будет писаться людьми с головой на плечах, которые разделят всё на слои и неполенятся прокидывать зависимости между ними правильно. Для этого, наверное, придется брать DI из ларавела или симфы, потому как своего нет, а правильность использования сервис-локатора сейчас оспаривается.

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

Посмотри как простые вещи делаются на компилируемых языках с обязательными строгими типами данных. То, что было в php5 — это разброд и шатание. Такого больше не будет. Сейчас мы постепенно идем именно к тому, чтобы стать компилируемым языком общего назначения. В PHP8 обещали свой JIT. Заживём!
А симфа просто заставляет тебя писать также, как ты писал бы в каком-нибудь спринге. Как пишут все остальные серьезные дяди на серьезных стеках. Всё же оттуда идет. Вся ООП мысль же из спринга к нам приходит. И туда всегда бежали симфонисты с еще пятой пыхи.

в больших сложных ddd проектах его вполне можно юзать

Верю. Зависит от людей и принятых внутренних требований к коду в команде/компании. Потому что сам Yii2 не заставляет, значит надо заставлять себя самим писать хорошо. Но писать хорошо — на нём можно.

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

Да может и не запланированно заранее, но когда проект живёт долго и приносит уже хорошо бабла, то на первый план выходят уже совсем другие ценности, а не «сделать по Шурику».

Что там по yii3?))

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

Для этого, наверное, придется брать DI из ларавела или симфы

Или я чего то не понял, или Yii::createObject() вас чем то не устроил? Есть и синглтоны и определения, инициализация как всегда, при правильном разнесении на модули(у которых бесконечная вложенность) есть возможность переопределять значения. Что не так с DI?

То, что было в php5 — это разброд и шатание. Такого больше не будет.

Я вот недавно смотрел www.youtube.com/watch?v=rKXFgWP-2xQ — стало понятно откуда столько косяков в 5ке было. Все сейчас стремятся к строгости, все подросли, и php дает нам 2 таблетки, как Морфиус.

Вся ООП мысль же из спринга

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

Yii2 не заставляет, значит надо заставлять себя самим писать хорошо.

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

Да может и не запланированно заранее, но когда проект живёт долго и приносит уже хорошо бабла, то на первый план выходят уже совсем другие ценности, а не «сделать по Шурику».

Тут часто и от пыхи откаызваются, и это норм =)

P.S. — я не критикую, очень толерантен к другим фреймворкам и языкам, так что не парься =)
Мы просто говорим =)

А ответ на тему топика — я бы учил пхп, но сразу бы отделял общие знания о программировании и знания инструмента, то есть яп и все технологий связанных с ним. Если делать упор в 1е — буде щастя вне зависимости от ЯП и среды.

Или я чего то не понял, или Yii::createObject() вас чем то не устроил?

Честно говоря, про Yii::$container был не в курсе, а этот метод — просто синтаксический сахар для самого контейнера. Почитал про него, он безусловно лучше, чем известный мне Yii::$app, который и является сервис локатором и именно его использование оспаривается.

Но и в Yii::$container вижу минусы:
— во-первых, он доступен через статический вызов, т.е. вызвать его можно где угодно. Это позволяет плохому разработчику наплодить неявных зависимостей по всему проекту. И как потом мокать эти статические вызовы, если уже понаписали такого?;
— во-вторых, у него только 1 способ конфигурирования — это php array (нет yaml, xml);
— в-третьих, не уверен, что с его помощью можно объявить как сервисы всякие вещи типа контроллера, консольной команды, репозитория (или модели, где запросы в БД лежат), чтобы управлять _всеми_ зависимостями проекта из одного места.

В итоге мне видится так, что среднестатистическому йиишнику проще будет навытаскивать себе всего подряд из контейнера прямо в методах сервиса (модели) и не запариваться с его конфигурированием. Еще половина проектов для этого Yii::app() используют, уверен. Или половина объектов там, другая сям. Если не прав, поправьте.

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

Это rapid девелоперы, им бы побыстрей прототип накидать, а как оно дальше им не так важно.

А ответ на тему топика — я бы учил пхп, но сразу бы отделял общие знания о программировании и знания инструмента, то есть яп и все технологий связанных с ним. Если делать упор в 1е — буде щастя вне зависимости от ЯП и среды.

Согласен.

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

но зачем, если можно просто взять джаву/спринг?

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

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

До выхода php7 всё асинхронщину реализовывали на чём-то компилируемом и долгоживущем, но сейчас эта необходимость отпала. Можно держать на пыхе все части своих веб-приложений, иметь единый слой бизнес-логики (один и тот же код) как для отдачи респонса синхронно, так и для асинхронных задач, а не переписывать одно и тоже на разных языках.

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

Потому я трансформации пыхи так горячо и приветствую.

Що думаєте на рахунок Spring Boot ну і альтернативи в виді Asp.net core?

К asp.net mvc отношусь крайне тепло. Особенно уважаю язык запросов к объектной модели LINQ. Это просто бомбическая вещь, с её помощью можно одинаково кверить ЛЮБОЙ источник данных, будь то субд, файл ряда форматов, даже объекты в памяти. :)

Единственный известный мне аналог этого в PHP-мире — DQL в Doctrine ORM, но он не такой чарующе быстрый и заточен только под СУБД. Но это всё понятное дело имхо, дотнетчикам, наверное всё будет не так.

Веб-приложения на asp.net mvc в 2013 году, когда я искал работу по нему, получались на голову лучше того, что было на пыхе, но работы не было для джуна. Всё, что стартовали на местном рынке — всегда пыха, реже — руби (тогда был хайп). В лучшем случае — поддерживать говно мамонта на asp.net web forms. Да и вообще платформа дотнета уже тогда явно уступала джаве в энтерпрайзе и пыхе в вебе (и до сих пор уступает).

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

Цікавий досвід з asp.net mvc, але asp.net core абсолютно новий фреймворк побудований здається на ідеях node.js, але з бвгвтою мовою C# і сам фреймворк жирніший, я чув в ноді треба мульйон пакетів ставити аби щось зробити, а тут все досить компактно. Правда в процесі переписування з laravel постійно стикаюся з неочевидностями а то і відвертими багами, як і в ef core. Хлопці спішать дуже і боюся помилок наробили дуже багато.

Особенно уважаю язык запросов к объектной модели LINQ

Так, крута штука. Хоча я все на лямбдах пишу, зручніше. Хоча функціональщину ніколи не вчив, інтуїтивно розумію)) Нажаль не всі конструкції вміє ще в дб квері переводити і подекуди вибирає всю таблицю відфільтровану аби закінчити вибірку.

Брать сразу джаву для большинства веб-приложений сейчас — это удорожание разработки.

Почему? джава+спринг сильно сложнее пхп+симфони?

Сам язык джава сложнее пыхи. Он строже, у него больше языковых конструкций, он больше даёт возможности работы с памятью, он компилируемый, наконец. И дороже разрабы, особенно, джуны-миддлы.

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

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

И дороже разрабы, особенно, джуны-миддлы.

для самих пхп разрабов это недостаток, а не преимущество)

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

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

для самих пхп разрабов это недостаток, а не преимущество)

Это их проблемы. Вход обваливают CMS. Не было CMS, зарплаты бы для джунов/миддлов сравнялись бы. А так для кого-то есть лёгкий вход за $300.

Якщо не зобовязує використовувати значить ніколи і не використають в проекті бо і так працює. Сенсу в опціональних типах практично нема, бо мало де потрібна динамічна типізація. А от опціональний динамічний тип як в C# dynamic закриває цю необхідність. Нажаль якісна мова програмування і популярна — рідко зходиться.

лёгкий вход за $300

Плодить поганих девів які потім продовжують кодити в звичному нетипізованому стилі пхп 5.

Якщо не зобовязує використовувати значить ніколи і не використають в проекті бо і так працює.

Ну и ладно. :] Главное, чтоб тем, кому это нужно было, могли использовать. А не приходилось зоопарк из языков к проекту прикручивать, как еще недавно было.

Плодить поганих девів які потім продовжують кодити в звичному нетипізованому стилі пхп 5.

Плохие девы, не задающиеся никакими вопросами, так и останутся на CMS и мы с ними никогда не встретимся. :)
А остальные, изучая хороший код фреймворков, того же ларавела/симфони/зенда задумаются и начнут делать хорошо.

От джава з початку вчить вайтішника правильної бази, а пхп прощає багато. Це без наслідків не залишається для пхп. Крім того ви привели аргумент про дешевизну пхпстів, хоча загальновідомо що хороший дев коштує багато незалежно від мови програмування. Тому це «на пхп дешевше» — не більше ніж трюк для замовника нищеброда.

Основная проблема в Yii2 там нет нормального контейнера зависимостей как в Laravel/Symfony с инициализацией через аргументы метода , Yii::$app -костыль какойто

Yii::app() - это сервис-локатор, а не DI. Это гораздо лучше, чем везде писать на статике или делать new объектам (как делали в нулевых-начале десятых), но сейчас уже многие считают его анти-паттерном, потому что вместо явной инъекции только нужной зависимости, нужно обращаться к локатору — либо делать статический вызов Yii::app() либо прокидывать в классы прямую зависимость на локатор, чтобы избежать статических вызовов. В обоих случаях произойдет смешение слоя бизнес-логики с инфраструктурным слоем фреймворка, что нарушит инкапсуляцию — для работы с классом придется знать детали его реализации, что там нужен не просто какой-то объект (сам сервис локатор), а в том объекте еще какие-то объекты должны быть, а какие — хз (пустой локатор не подойдет).

Здравствуйте. Меня зовут Вячеслав, мне 22 года и я пхп программист. Я сижу на пхп с 18 лет. Первый раз я попробовал пхп с другом. Мы сидели, обсуждали веб-технологии и тут он сказал, что недавно пробовал пхп. Он предложил попробовать мне. Поначалу я не согласился, ведь это пхп, я слышал много плохих слухов про него, слышал, что он вызывает зависимость. Но друг настаивал, говорил, что в жизни нужно попробовать все и я сдался. Он предложил бесплатный скрипт, выводящий «Hello world!». Он казался совсем безобидным, но как потом оказалось, я уже не мог остановиться.

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

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

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

Самая трагическая история за всю мою жизнь

А нахиба вебдев? Почему не мобайл? Тот же андроид на джаве, например, пили себе аппку под ключ, хочешь иди нанимайся на галеру, хочешь фрилансь, хочешь стартапь. Масса направлений :)

PWA уже во всю шагает, а это значит что используя JavaScript (ECMAScript) и тот же PHP на бэкенде можно смело вливаться в тему мобильных аппликух, которые будут плюс/минус одинаково работать и на яблофонах и на андроидах используя всего 1 команду разработчиков.

Мой бы выбор был по убыванию(от лучшего к худшему): python, ruby и ... golang и JAVA.

Я позащищаю пыху, поскольку она с каждым релизом начиная с ноября 2015 года становится всё лучше и быстрее и заслуживает того, чтобы отмыться от дерьма, налипшего на неё в нулевых и ранних десятых (небезосновательно). Сейчас последняя пыха значительно быстрее последнего пайтона, например: (и не только пайтона, а и руби и nodeJs тоже!)
benchmarksgame-team.pages.debian.net/...​marksgame/faster/php.html

И с каждой версией пыхи её производительность растёт на 10-15%.
www.phoronix.com/...​.3-Performance-Benchmarks

В ней появились статические типы данных (необязательные, но появились), наконец-то полностью устранили все утечки памяти и можно писать демоны, не перезапуская их раз в час (у меня в продакшне демоны на php 7.2 живут в среднем 14 дней (от релиза спринта до релиза следующего без перезапуска), а отдельные — по месяцу и более). И нет утечек. Вообще.

Веб-фреймворк симфони на голову превосходит джанго по абстрактности (гибкости) объектных моделей, в нем нет повсеместных статических вызовов как laravel, в нем принудительно везде dependency injection, он заставляет писать объектно и тестируемо.

Работы именно по вебу на PHP/Symfony столько же или больше, чем на Django, на PHP/Laravel — больше в разы. Если брать в весь PHP-мир, включая CMS — в десяток раз.

Тебе я бы порекомендовал вкатываться в PHP-мир через Laravel, там очень низкий порог входа и можно начать зарабатывать сразу, но при этом не такой низкий, как у CMS, чтобы не конкурировать с индусами. Когда в голове уложится OOP, DI и научишься писать без статики — велкам в симфу. Ап по зарплате приложится.

Что до пайтона — ему нет равных в разной околонауке, куча либ для неё, если захочешь вкатываться с целью потом в machine learning задержаться или в распознавании образов, то лучше с пайтона начинать. Но есть риск неосилить порог.

Что до пайтона — ему нет равных в разной околонауке

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

У PHP есть одна большая проблема: уровень софта, по большей части работать прийдется с старым кодом(особенно беря во внимание что только старт у человека) — там жуть и боль
Если новый PHP вполне неплох, то мозги и привычки у людей остались старые, и подход к написанию софта такой же

в нем принудительно везде dependency injection, он заставляет писать объектно и тестируемо

Вот прямо сейчас на проекте который написан на Symfony, стартовал в 2015 ... не тестируемо, totally overengineered, ООП использован потому что Symfony заставляет, но совершенно без понимания зачем
И это отнюдь не частный пример — такого на PHP большая часть, и будет еще долго, хоть и да это не проблема языка а людей которые на нем пишут, он сейчас вполне приятен

по большей части работать прийдется с старым кодом

Это верно для абсолютно любого ЯП. У нас те же java /.net еще то легаси Г...
В общем все зависит от вас, есть желание — перебираете проектами, а не +200$ к зп. Если на 1м месте бабло — тогда пишите что дают и не парьтесь.

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

Ну поддерживать старый проект на втором петоне и древней версии фреймвока удовольствие тоже так себе.

У PHP есть одна большая проблема: уровень софта, по большей части работать прийдется с старым кодом(особенно беря во внимание что только старт у человека) — там жуть и боль

Я почему и посоветовал начинать с laravel. Сам фреймворк довольно новый (относительно, конечно, ведь начался в 2011), в нем все-таки не будет каких-то мамонтов из 2004 с процедурщиной, уже везде ООП. Старый синтаксис php5 кода (без типов, всякие array вместо [] и т.п) еще доведется встретить не раз, но это уже будет в медвежьих углах проекта, куда редко доходят руки. Более менее новое и то, что рефакторится, уже будет писаться по-человечески. Конечно, надо всегда выбирать работу по ощущениям от собеседования, спрашивать очень подробно о проекте, команде, не идти на гнилой стек, это же само собой разумеется, нет? Да, на хорошем проекте или проекте с нуля (хотя пойти джуном на с нуля — это большая удача для джуна) будет чуть меньше по зп, но на входе же важнее впитать что-то хорошее, а не урвать лишних $200?

Вот прямо сейчас на проекте который написан на Symfony, стартовал в 2015 ... не тестируемо, totally overengineered, ООП использован потому что Symfony заставляет, но совершенно без понимания зачем

У меня тоже проект, на котором я сижу, начинался в начале 2015 на симфе еще 2.3 (типа LTS же, всё серьезно, энтепрайз делаем). И что? Да, пацаны в начале юзали new, было десяток мест со статическими вызовами, репозитории как сервисы не объявляли, туда, куда объявляли кидали что не попадя, встречал даже контейнер в одном месте. :) Ну и что? Завёл техдолгов на это, зарефакторил за несколько месяцев это, потом техдолги на покрытие юнит-тестами (чуваки пытались, но как-то не срослось у них), ушло месяцев 9. И нормальный проект получился. Да, до сих пор есть куски кода из 2015 с php5 стайл кодом, но переезду это не мешает, если сейчас что-то пишем там, то рефакторим уже на нормальный вид.

Оверинженининг — это вообще чистой воды субъективизм. Есть люди, которым DDD и CQRS — оверинжиниринг. А есть, кому — ValueObjectы. Уверен, что в нулевых были и те, кому ООП код писать на пыхе было впадлу и они говорили, что типа это ноулайферы придумали, оверинжинирят. И где сейчас те процедурщики из нулевых? Время не стоит на месте, скоро у всех будут распределенные архитектуры, общающиеся между собой по graphQL, лежащие в облаках и для общения между ними будут использоваться CommandBuses. Уже вон всё реализовано, до нас только не дошло — гугли symfony/messenger и enqueue/enqueue-bundle. Второй сейчас как раз внедряем и сколько же там оверинжиниринга!!! Который через полгода станет обыденностью...

Оверинженининг — это вообще чистой воды субъективизм

Трудно не согласится — как пример мы о разном говорим, я имел ввиду сложность реализации, а не пути поиска проблем

И где сейчас те процедурщики из нулевых?

Та собственно все у них хорошо, мне кажется, программирование (к счастью) не ограниченно только ООР

Время не стоит на месте,

Оно то да, но следующая цитата заставляет задуматься

Уже вон всё реализовано, до нас только не дошло

Что не дошло? MQ? или Actor pattern? или Pub/Sub pattern?
Или оно до Symfony не дошло?
Люди веруюющие в ООП часто забываю, что основной задачей программиста, помимо решения проблемы есть уменьшение сложности этого решения, и вот когда забывают и получается то что я назвал оверинжинирингом(можно еще бы назвать overcomplexity) — идея может и ок, реализация говно, и за сложной и запутанной реализацией не видно той самой идеи

DDD и CQRS, ValueObjects, MQ, Actors ...

это не оверинжиниринг — это способ борьбы со сложностью с помощью добавления абстракций, иногда работает иногда нет

и enqueue/enqueue-bundle. Второй сейчас как раз внедряем и сколько же там оверинжиниринга!!!

Я даже понимаю почему вам так кажется — потому что Symfony + enqueue/enqueue-bundle — они ж изо всех сил стараются быть универсальными, что накладывает кучу доп сложности
Я тот же RebbitMQ через PHP AMQP extension использовал году так в 13м-14м и ничего сложно там нет
Второй минус универсальности — enqueue/enqueue-bundle, скорее всего, не будет поддерживать много специфических(и очень полезных часто) фич конкретных брокеров

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

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

Какая разница, какой код МОЖНО написать на PHP если важно какой код НАПИСАН.
Поддерживать то прийдется не теоретический код на php7, а обычный на php5

Прошу прощения, а какой сейчас год по-вашему? Вроде как PHP5 с 1 января 2019 больше вообще ни в каком виде не поддерживается: php.net/supported-versions.php У всех любителей пятой пыхи было 3 (!) года, чтобы обновить свои продукты до 7ки (точнее уже даже минимум до 7.1, 7.0 же уже тоже не поддерживается). О необходимости обновления с 5 на 7 предупреждали везде и всюду, даже всякое дно типа Битрикса к 19 году все-таки смогло!

Сегодня стабильной мажорной версии PHP7 на сегодняшний момент уже 4 полных года, успело выйти даже 3 минорных апдейта за этот срок, а до ноября 2015 еще где-то с весны мусолилились релиз кандидаты... Не знаю кем нужно быть, чтобы в 2019 идти поддерживать php5 код. Вы задумайтесь, если в конторе за 3 года пожлобились выделить время разрабам, чтобы перетащить проект хоть по кускам, то на что еще они пожлобятся?

Я на двух работах застал два масштабных переезда с PHP5/Symfony2 на PHP7/Symfony3, никогда не было никаких проблем с тем, чтобы обосновать необходимость переезда. Оба раза заводил техдолги в джире, прилинковывал бенчмарки, релиз календари пыхи и симфы и говорил продукт овнеру, что надо сделать то и это иначе проект сгниет. В течение 2-3 месяцев всегда находилось время, чтобы посервисно (у нас везде SOA было) всё переносить.

В июне 2017 окончательно перевёз проект на текущей работе и написал свой последний php5 код, с тех пор — семёрочка онли. И я работал не в каких-то мегаконторах, но и не в аутсорсе. Просто ходил и разговаривал с овнерами, с тогдашним лидом, другими разрабами, убеждал. Да, не сразу, были нервы, но в итоге закончилось хорошо.

Вы еще скажите, что никогда за юнит-тесты не ругались с PM/PO на пыхоынтепрайзе. :)

Какая разница какой сейчас год? Я вот еще ни разу ни видел НИ ОДНОГО проекта на php 7. Может, они гдето есть, как единороги. Но шанс на них попасть — 0.

Я вот еще ни разу ни видел НИ ОДНОГО проекта на php 7.

Что для вас проект на php7? Если допустим, проекту года 3 он написан на микросервисах и 30% микросервисов (новых) писались php7 стилем со строгими типами, а остальные 70% с солянкой старого кода php5-стиля и нового php7-стиля, но вся эта вакханалия работает в проде на PHP7.2/7.3, то это для вас проект на php7 или нет?

Может, они гдето есть, как единороги. Но шанс на них попасть — 0.

Можно пойти в стартапы. Там шанс на них попасть — 100%, ибо не существует сейчас людей, которые новые проекты на PHP5 стартуют.

Мне кажется, мы меня троллируете. Ну или это пропасть «двух миров айти».

Ну допустим вот в моей области — freepbx, php-agi, a2billing — никто ничего не обновлял. Centos 7 — нету php 7й версии. Я уж не говорю про мои проекты на php. Никто не просил их обновлять. Новые проекты на php в последние 5 лет никто не просил начинать. Слава сильно уж недобрая. Теперь лет 10 до изменения.

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

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

Да это пропасть между ожиданиями и реальным миром.

Пропасть между телекомом и разработкой прикладного софта, вы хотели сказать?

Ну я не натыкаюсь на каждом шагу на проекты на php7. Затo натыкаюсь на проекты на php 4/5 и на факты перехода с php на другой язык.
Почему вы считаете свой опыт более репрезентативным чем мой? Помоему это вы педалите.
Ну вот какой аргумент по поводу того, что в актаульных linux системах по умолчанию php5? Это у их мантейнеров тоже узкая область?

As a default, Ubuntu 16.04 LTS servers assign the PHP 7.0 version.

Убунту уже через два года иногда не обновляется(хотя заявлено, что да). И они всегда как бы славилися тем, что новые пакеты ставят.

И они всегда как бы славилися тем, что новые пакеты ставят.

И переключение на новую версию PHP после апдейта может быть tricky :)>
(об этом в конце статьи по ссылке)
letyourmoneygrow.com/...​ubuntu-18-04-1-lts-linux

В убунту много чего «tricky» особенно если сервер достался от неизвестного админа и не обновлялся год или больше.

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

Та во всех областях так же.

ну нет же, у вас там выше уже один оппонент есть, я второй
я уже лет так с ..дцать с PHP работаю и все меньше вижу остатки 5го, вернее почти не вижу
все более менее вменяемые проекты уже ушли на 7й и не просто для галочки
то что

freepbx, php-agi, a2billing

нет — это значит только то что те части которые там на PHP воспринимаются как побочный продукт и внимания должного от mainteiner/community не имеют/не заслуживают
Opensource в худшем его виде, хочешь халяву, имеешь халяву
Кстати почему такая ситуация именно с вебмордами для VoIP так и не понял до конца
И да — a2billing начал таки шевелится в сторону PHP7, а php-agi помер давно

Шевелится то начинают, но на это нет ресурсов.

так все и обновили, только 7-й же обратно совместим, там минимум фиксов что бы легаси код продолжал работать.

Это да, php5 кода еще много и он работает нормально, но новый код же пишется уже по-новому же? И наверняка же постепенно техдолги фиксятся, есть какое-никакое покрытие тестами, постепенно доходят руки до рефакторинга старья... Или нет?

Рефакторинг? Это только в книгах. Ну или если вы пишите либу опенсорсную то там и тесты и рефакторинг ну и все это за ваше личное время ))). По факту рефакторинг в реальных проектах может происходить только в случае если этого требует какая то баг/фича, и без него нет возможности двигаться дальше. Ведь ваш рефакторинг кто-то должен оплатить, потом протестировать, потом еще баги на продакшене ловить и фиксить, и не дай бог компенсировать потенциальные убытки. Код конечно можно писать по новому. Тесты опять же, если за них кто-то готов платить то тоже можно писать.

А вам не приходило в голову, что надо заказчику рефакторинг и тесты ПРОДАТЬ? В точности как всяческие маркетологи продают заказчику идеи, которые надо реализовать в продукте, так и вам надо всё, что нужно вам, продать.

Неужели так сложно продать, например, тесты? Приходишь к заказчику и говоришь: «хотел предупредить, что сейчас с продуктом все хорошо, но это не продлится долго. Чем дольше мы живем дальше так, как живем, тем хуже будет в средне-долгосрочной перспективе для продукта — задачи будут со временем делаться все дольше и дольше, людей будет нанять все сложнее и сложнее, вы хотите своему детищу такого будущего? У меня есть решение, которое решит все проблемы, нужно всего-лишь выделять совсем немного времени в спринте на рост покрытия!».

Или, чтобы обновить инфраструктуру: «вы знаете, что инструменты, которыми мы пользуемся, МОРАЛЬНО устарели и больше не поддерживаются их разработчиками? Злобные хакеры не дремлют, следующая дыра в безопасности, которую они найдут, будет использована против нас! И её некому будет исправлять! Если мы не задумаемся о переезде проекта на новые версии инструментов, то рано или поздно наш продукт окажется в опасносте! Но у меня есть решение! Нужно зарефакторить это и это, обновить на сервере такие-то пакеты, задачи уже поставлены, нужен только ваш аппрув!».

После таких тирад нормальный заказчик, который беспокоится за судьбу своего проекта, который его кормит фактически, как бы ему не хотелось, выделит какие-нибудь 5-10% спринта на конкретные вещи, будь он трижды жлобом. А нормального без труда можно убедить и на 15-20% квоты техдолгов в спринте, если подробно объяснять и давать отчеты что и зачем мы делаем.

А если не объяснять, не продавать, то как он поймет, что его не обманывают? Все эти тесты, версии пых, более лучшие архитектуры он самостоятельно потрогать не может. Ему нужны какие-то отчёты, в точности как ему дают маркетологи или сеошники, где зеленый значит — «хорошо», а красный — «плохо». Состояние инфраструктуры можно представить точно также. :)

Круто конечно, но реальная жизнь она другая) Хотел много написать, но чет лень.

Дай бог нам всем таких заказчиков. И такие проекты.

Що тут думати, скільки вакансій он по пхп на доу. Які пітони, ноди.

Ну, если цель состоит просто поработать, то да. PHP — как вариант я бы рассматривал лишь как низконишый dev аля (magento, wordpress) и полная концентрация на том, чтобы становиться узконишевым матерым специалистом. Всё остальное, — расходование жизненных сил и дорога в никуда. Мое ИМХО.

Я пытаюсь человеку сказать, что не суть важен язык и крутость фрейворка. Я вижу более правильным развиваться нишево в продуктах где большой спрос на квалифицированных специалистов. Со знаниями symfony и laravel, вы будете как специалист, решать задачи которые решаются альтернативно куда более серьезными Django и RoR. Люди которые заточены на продукт (допустим magento) и имеют правильную точку приложения (фриланс или удаленка), имеют рейт раза в 2 выше чем средний рейт который здесь на сайте, я это хотел донести.

Symfony/Laravel/Django/RoR — все бойцы одной весовой категории. Более того, рельсы одновременно ругают и хвалят за их направленность на «быстро наклепать».

Узкая заточка может приносить хороший рейт, тут не поспорю.

NodeJS, якщо вам WEB хочеться
хоч у Python ніби і намічається щось на зразок resurrection у WEB, але не факт
У будь якому випадку не раджу PHP( і так, я останні років 10 як з ним працюю, і зараз теж, але якби мені зара тре було обирати куди йти — точно б не обрав PHP)

Моё ИМХО — если хочется побыстрее начать зарабатывать, то PHP. А если хочется получать удовольствие от процесса — однозначно Python :)

Я так розумію, ноутбук для вебдева Ви вже обрали...;)))

Хіба можна обрати ноутбук, не знаючи для PHP він буде, чи для Python?

Якщо ноут біленький — то байдуже;)))

Знаєте щось про ТС, чого не знаєють інші? ;))

Не, просто слюни пускаю)))

Подписаться на комментарии