и критерии мертвости уии в студию. методология ddd на нем не заводится?

Ну так и работай пока менеджером и потихоньку мелкие задачки бери у разрабов ваших

а вдруг там одни джуны?)

да пусть

ну или развернуть какую CMS на Yii и ковырять ее

Вот EasyYii норм для начала

и критерии мертвости уии в студию. методология ddd на нем не заводится?

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

Простенький и понятный

ну для "хуяк хуяк и продакшн" еще норм

а можно на кокрентных задачах примеры кривости yii?

но ни одна серьезная студия сейчас не начинает делать проекты на юии так как хрен продаш

ну не продавайте хрен

:)

или у меня одного yii ассоциируется - о, это можно сделать за вечер/два )

))

или у меня одного yii ассоциируется - о, это можно сделать за вечер/два )

есть такое понятие как "технологический долг"

вот мы умудрились написать CRM на юии

сейчас это все начало рости и начинается жопа

а еще есть понятие - программирование ради программирования

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

можно конкретные примеры?

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

но ни одна серьезная студия сейчас не начинает делать проекты на юии так как хрен продаш

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

вопрос не в не возможности, а в том что там под капотом

написать можно и на чистой пыхе

но при изменении/добавлении функционала это превращается в ад

по моему опыту - проблема обычно не в инструменте, а в отсутсвии мозга,если уж прямо

этот опыт появился как на крупных так и на мелких проектах )

поэтому хотелось бы конкретики - что yii не позволяет

может вы и правы

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

А вот что Yii позволяет - так это наговнакодить так, что на других фреймворках такого говна написать нельзя, это да.

так приведите примеры

одно нытье

мне пример один понравился - сделали чуваки сервис на уии без всяких ddd и прочее. И почти сразу он стал приносить миллионы. На волне успеха они решили еще один замутить, но по взрослому (но на уии, но не суть) - результат одни убытки. Глакное бизнес идея, а не что там под капотом

ясно

А вот что Yii позволяет - так это наговнакодить так, что на других фреймворках такого говна написать нельзя, это да.

Брехня

Есть перед глазами примеры на ZF3

Брехня

\Yii->$app->request->post везде где хочешь

Ок. У нас ЦРМ для крупной компании написаная на юии. Ввиду своей архитектуры оно все монолитное и разделению практически не подлежит. Делать из юии что-то невразумительное и модульное - головная боль.

оу, а понимать что надо не везде - это сложно? )

Это позволяет и голый PHP с $_POST, но тем не менее

оу, а понимать что надо не везде - это сложно? )

Он это позволяет, говнокодеры юзают. А потом у людей, которые понимают, бомбит

так проблема в говнокодере

а еще можно архитектуру заранее продумать

и тогда вообще все как по маслу

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

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

Это вы так эту црм написали, с архитектора вашего спрашивайте

Ок. У нас ЦРМ для крупной компании написаная на юии. Ввиду своей архитектуры оно все монолитное и разделению практически не подлежит. Делать из юии что-то невразумительное и модульное - головная боль.

У меня один вопрос. Монолит - говно, микросервисы - круто? Это принимать как факт не принимая во внимание ничего?

Монолит херново в данном случае так как клиент анчал испытывать сильный рост и заказывает невероятное количество новых компонентов системы

некоторые их них не пишутся на пыхе

ЦРМ для крупной (!) конторы на PHP - это круто

или вообще работают в режиме реального времени

Как в YII2 обновить таблицу GRID

так все проблема в тупопост архитектора

$.fn.yiiGridView.update('sorders-grid');

не предусмотрел точки с нагрузкой

так все проблема в тупопост архитектора

архитектора юии?

не подумал как масштабировать приложении

архитектора crm

или ты собрался юии мучать и делать из юии лару или симфу?

или что там

Архитектора который выбирал инструменты под задачу

Архитектор сделал ЦРМ под ТЗ

Масштабирование и юии это 2 разные вещи

и, главное начали переписывать крупную црм не на java или c#, а снова на рнр

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

ERROR: S client not available

Причем вообще тут язык?

Чем пыха плоха то?

кароч найдите нормального архитектора который прочитает ТЗ и поймет бизнес задачу и сделает нормальную архитектруру

тут дело не в yii

Это и было сделать

после окончания разработки по ТЗ клиент написал новые задачи

Масштабирование и юии это 2 разные вещи

Какое масштабирование? Разнесение на несколько разных серверов под балансировку нагрузки? Легко

разделение на более мелкие компоненты

Еще раз - речь о CRM (типа SAP. OEBS) для КРУПНОЙ RJYNJHS&

разделение на более мелкие компоненты

Зачем?

КОНТОРЫ*

с целью балансировки не всей системы,а отдельных компонентов

не все компоненты требуют много мозности

а некоторые какраз имебт высокую нагрузку

это все легко предугадывается на этапе планирования )

Еще раз - речь о CRM (типа SAP. OEBS) для КРУПНОЙ RJYNJHS&

Система позволяет учитывать лидов, заказы, склад и очетность с финансами.

это все легко предугадывается на этапе планирования )

ок. Как ты угадаешь что клиент захочет написать POS модуль для компаний-партнеров который должен работать реал тайм когда тебе говорят в начале что система должна просто вести учет лидов и заказов?

Если тут реально система которая должна работать на 2+ серверах, то изначально писать её надо с расчётом на это. Фреймворк тут не причём. Или ты думаешь что если накидать связанного кода в Симфони/Ларавел, то он одним движением мышки разнесётся на кластер?

Система позволяет учитывать лидов, заказы, склад и очетность с финансами.

и вы решили снова на уии ее периписать? на основе этого негативного опыта отговариваете теперь новичов от неё?

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

в 99% у юии придется тупо убирать сам юии

и вы решили снова на уии ее периписать? на основе этого негативного опыта отговариваете теперь новичов от неё?

сжатые сроки и наличие свободных программистов-спецов по юии

причина конечно так-себе, но так получилось уже

сжатые сроки и наличие свободных программистов-спецов по юии

и давай теперь yii вовсю хаять и отговаривать от её изучения

составьте хотябы mind-map по модулям и распишите что они делаеют и примерная нагрузка

это предовтратить 90% факапов в архитетуре

не формальное ТЗ, а для себя - чтобы понять

составьте хотябы mind-map по модулям и распишите что они делаеют и примерная нагрузка

это и было) нам никто ен сказал что будут пиздоватые модули после)

мы когда услышали что они начали думать в сторону реал тайма мы офигели

ну у кого то зн опыта не хватило предусмотреть

ты будешь все делать мего расширяемое?

тогда точно в симфони превратится с кечей абстракции