Страница 1 из 6

С какой целью разрабатывается фреймворк

Добавлено: 2019.04.01, 18:20
TM123
Здравствуйте.

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

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

С Yii познакомился с версией 1.1.9 в марте 2011, в октябре начал писать ERP. Это первый фреймворк который мне понравился и отвечал моим требованиям и идеологически соответствовал моим ощущениям прекрасного в программировании.
В составе ERP 16MB чистого исходного кода, с каментами за 30 завалит, 250MB исходных кодов используемого стороннего ПО, все это управляет примерно 40 сервера Postgres, MySQL, MariaDB с общим объемом данных в них около 400GB. В проекте есть основные модули - CRM, Workflow, Документохранилище, База знаний, Почтовый архив компании, Система тестирования сотрудников, модуль Отчетов. Система прав представляет из себя лес из около 2000 ролей, в системе работает каждый день около 400 человек географически распределенного торгово-производственного холдинга, в котором работает всего почти 1000 человек. Из проекта управляются почтовый mail proxy, Asterisk, десяток СКУД'ов, сервера видеонаблюдения, СМС гейт, сервер календарей, интернет файл-браузер взамен samba, авторизация через LDAP и управление LDAP. Пользователь заводится в системе, автоматически в соот. с должностью получает права в системе, которые разливаются вплоть до того, что у него будет доступно на рабочей станции.
Сейчас идет процесс усиления интеграции со складской программой так же собственной разработки, которая написана на других средствах + интеграция с 1С всякого рода ЗУП, Бухгалтериями и т.д.

в 2014 году вышел Yii 2, мы не ломанулись переводить проект на него (зачем самостоятельно искать косяки, тем более что косяки в Yii 1.1 пришлось исправлять самостоятельно, потому что ждать не было времени) и подождали до лета 2016 года, после чего начали перевод. В статьях писали о несовместимости фреймворков, но суть их сводилась что не смотря на несовместимость типа просто одни программные конструкции надо поменять на другие, кое что просто копипастом заменить, в общем процесс не представлялся особо сложным, но все закончилось тем, что пришлось перекрыть значительную часть классов, выпилить некоторое количество функционала, чтобы обеспечить прозрачную работу для пользователя, когда он не знает что сейчас он работает на Yii 1.1 а следующая страница уже работает на Yii 2. Помимо этого пришлось наваять собственную визуальную библиотеку и специализированную версию ActiveRecord для Postgres, которая вытаскивает из PG все что только можно и обеспечивает определенные принятые в проекте правила, в результате чего объявление в 3 строки приводит к созданию полностью функциональной модели, в которой остается написать только бизнес валидации, все проверки типов, внешние связи и т.д., все настраивается автоматически исходя из описания данных хранящихся в системных таблицах PG.

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

В какой-то момент мы столкнулись с тем, что мы не могли найти персонал, потому что никто не хотел работать на Yii 1.1, все хотели Yii 2, нормальное желание и вот мы потратили 1.5 года на то чтобы скрестить в проекте 2 версии фреймворка и только год занимаемся переводом проекта и что тут происходит, выходит новая версия Yii 3, которая по заявлениям разработчиков не совместима с Yii 2, хоть и не так радикально как Yii 1.1, но тем не менее это большая проблема для большого проекта.

Меня интересует на кого рассчитывают и на какого-рода проекты рассчитывают разработчики фреймворка? Для сайтоваятелей фреймворк слишком сложный и имеет мало бантико-плюшек, требует хороших знаний PHP не на уровне просмотра пары примеров на сайте - PHP для чайников. По моим ощущениям это фреймворк для проектов средней сложности и выше, но если мы говорим о таких проектах - это проекты живущие годами, но архитектурная политика фреймворка на мой взгляд смахивает на погоню за модными тенденциями в попытках остаться популярным, из-за этого от версии к версии фреймворк полностью переделывается и совсем не в ту сторону, которую стоило бы. Так же у таких потребителей как мы возникают проблемы описанные выше, из-за чего отбивается желание использовать этот фреймворк, текущий проект никуда от фреймворка не уйдет, но следующий проект очень вероятно я не буду стартовать на Yii, потому что он совершенно не соответствует традициям PHP - сильная обратная совместимость и соответствует традиции .NET, в которой с выходом новой версии мы выбрасываем все наработки и начинаем делать все с нуля.

Хотелось бы услышать мнение разработчиков фреймворка и серьезных разработчиков. Мне стоило достаточно больших усилий убедить хозяина начать переход на Yii 2 и удалось только тогда, когда люди стали отказываться работать на Yii 1.1 и вот опять я в перспективе 1-2 лет окажусь у того же самого разбитого корыта и потрачу еще полтора года на скрещивание уже 3-ех фреймворков.

Re: С какой целью разрабатывается фреймворк

Добавлено: 2019.04.01, 20:22
samdark
Если сравнивать с остальными популярными (да и не очень популярными) фреймворками, у Yii ну очень долгая поддержка старых версий: https://www.yiiframework.com/release-cycle. Ещё дольше мы их поддерживать не можем: нужно двигаться вперёд, перенимать лучшие практики, править глобальные архитектурные косяки, пробовать новые идеи. Если в версии 3.0 мы сделаем основу более грамотно, чем это было у 1.1 и 2.0, версия 4.0 будет в большей степени обратно совместима с 3.0.

Re: С какой целью разрабатывается фреймворк

Добавлено: 2019.04.01, 20:32
samdark
В принципе, вы можете вместо переписывания всего проекта ввести дополнительный слой абстракции (довольно тонкий). Это позволит прыгать на новые версии фреймворка безболезненно.

Re: С какой целью разрабатывается фреймворк

Добавлено: 2019.04.01, 21:27
TM123
Речь идет не о поддержке, а о несовместимости. 10 лет назад у меня возник вопрос, куда двигаться дальше, перейти окончательно на PHP на котором к тому времени я уже писал 7 лет, или пересесть на .NET, который своими корнями идет от IIS для которого на VBScript и JScript я на тот момент писал 10 лет. Выбор в пользу PHP был сделан в основном потому, что даже если код написал на PHP 3, он все равно на 99% работает на PHP 5, чем не мог похвастаться .NET. Поддержки PHP 3 конечно же не было, но код работал на новой версии PHP, да в этом коде не использовались разные новые плюшки языка, какие-то функции были задублированы самописками, потому что в PHP3 их не было, но код был абсолютно рабочим.

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

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

На мой взгляд основная задача фреймворка - это представление среды исполнения и эту концепцию я попытался объяснить выше.

Если не обращать внимание на крупных разработчиков, то сразу возникает проблема популярности фреймворка. Фреймворк уже существует больше 10 лет, но людей упоминающих его в своих резюмах практически нет, а большинство упоминающих в основном программисты ниже среднего, потому что столкнулись с фреймворка не посредством осознанного выбора, а просто хотели попробывать фреймворк какой нибудь и волею судеб им попала статья про фреймворки, по результатам прочтения которой они что-то на нем пописали. Нет на рынке серьезных разработчиков, потому что судя по всему их просто мало в принципе и они не светятся на рынке, ну либо мы где-то не там ищем. Только серьезные разработчики могут реально популиризировать фреймоврк, потому что они делают свой выбор осознанно, долго работают на нем и вокруг них вращается за это время достаточно большое количество программистов вникающих в фреймворк. Если не опираться в популяризации фреймворка именно на этот пласт людей, то получится пузырь из программистов, который как может быстро надуться случайными людьми, так точно так же сдуться.
samdark писал(а): 2019.04.01, 20:22 нужно двигаться вперёд, перенимать лучшие практики, править глобальные архитектурные косяки, пробовать новые идеи.
Я собственно и подозревал что вы дадите именно этот ответ, но рекомендую обратить внимание на то что я написал выше. 12 лет назад я пытался написать свой собственный фреймворк, потому что все что было доступно меня не устраивало архитектурно, а реализация была вообще ниже плинтуса. Фреймворк который я сам пытался написать идеологически был очень похож на Yii, только Yii реализован на много более правильно и не удивительно, я занимался на тот момент прикладным программированием и многого не знал из того, что надо было знать для реализации, я возвращался к попыткам в течение нескольких лет, на этом псевдофреймворке работало несколько достаточно больших проектов, но вот мне попался Yii и я него сел и больше не слезал. Не совсем в реализации я согласен, но это уже из области так видит художник.
Я уже давно наблюдаю тенденцию того, что вы пытаетесь втянуть в фреймворк разные программные концепции и делаете упор именно на это, но на мой взгляд надо больше делать упор на предоставление функционала позволяющего не внешнюю мишуру реализовывать, хотя она конечно нужна, но основной упор надо делать на решение именно задач, создания среды в которой от программиста не требуется выполнять рутинных действий, первый этап вы уже сделали, но давно, например, есть валидаторы и их можно легко настроить, но их все равно надо настраивать, а из структуры БД можно подчерпнуть информацию и не заставлять настраивать такие валидации как то что это должно быть число, что оно обязательное и т.д., что это число вообще синтетический ключ ссылка на другую таблицу и не надо настраивать связи в модели, все это автоматически должно быть настроено, а программист должен заняться настройками только того, что невозможно выяснить из структуры БД, например, валидатор проверки какого-то сложного взаимодействия полей модели, который например, невозможно было вставить в constraint. Разработав некие правила построения базы данных, можно добиться очень высокой степени автоматизации труда программиста, где сложные вещи могут описываться парой строк, а бантики и модные программные концепции - это нужно но явно не должно быть в приоритете.

У меня модель описывающая одну и ту же таблицу в Yii 1.1. занимает около 30kB, на Yii 2 всего 2 kB, почему, потому что в первом случае имеется долгое и нудное описание настроек модели, а во втором случае все это делает специализированный потомок ActiveRecord и немного дописано нюансов которые не удалось считать из БД и они не следуют из правил проекта. На мой взгляд надо уже определиться для разработки проектов какого рода пишется фреймворк. Для сайтостроя фреймворк слишком тяжелый и сложный, но большая часть нового функционала именно с ним и связана, с другой стороны фреймворк имеет смысл использовать для корпоративной разработки, но его в данном случае крайне трудно использовать для этого именно по причинам которые я озвучил. Мне кажется что выбор все равно придется сделать, иначе фреймвор потеряет своих пользователей. Я читаю много резюмов и как писал выше резюмов с послужным списком по Yii мало, но так чтобы Yii был упомянут более одного проекта - я видел всего несколько штук за много лет.

Re: С какой целью разрабатывается фреймворк

Добавлено: 2019.04.01, 21:37
TM123
samdark писал(а): 2019.04.01, 20:32 В принципе, вы можете вместо переписывания всего проекта ввести дополнительный слой абстракции (довольно тонкий). Это позволит прыгать на новые версии фреймворка безболезненно.
Мы очень сильно допилили Yii 2 чтобы он мог сам взять данные из Yii 1.1 и отдать их обратно, программного кода как такового не очень много, но потребовалось очень много времени на то чтобы досканально разобраться в соот. нюансах того и другого фреймворка, чтобы все заработало корректно, особенно трудно было принимать решения что вот этот новый функционал мы грохаем, потому что он просто тупо не совместим, с одной стороны, а с другой стороны не понятно какие точно будут у этого решения последствия. Собственно это и есть слой о котором вы говорите, но невозможно вызвать из Yii 2 модель написанную на Yii 1.1 и наоборот, т.е. если мы хотим дернуть из нового старый, то нам приходится делать дубликат модели, но если мы хотим дернуть из старого новый, то это ведет к необходимости переписать полностью весь кусок данного функционала и часто это оказывается полный комплект - контроллер, все модели и все вьюхи и это очень напряжно по ресурсам, потому что альтернатива - реализовывать дубликат уже сделанного функционала на новой версии в старой, а это просто глупо.

Re: С какой целью разрабатывается фреймворк

Добавлено: 2019.04.02, 09:07
BalykhinAS
Все меняется) если стоять на месте то мы бы до сих пор качали зип архивы с форумов.

Пилите относительно-фреймворконезависимую платформу. Проблема не в фреймворка а в том что вы сильно завязываетесь на его реализации.

Re: С какой целью разрабатывается фреймворк

Добавлено: 2019.04.02, 09:41
TM123
Wizard писал(а): 2019.04.02, 09:07 Все меняется) если стоять на месте то мы бы до сих пор качали зип архивы с форумов.

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

Re: С какой целью разрабатывается фреймворк

Добавлено: 2019.04.02, 09:54
maleks
Wizard писал(а): 2019.04.02, 09:07 Пилите относительно-фреймворконезависимую платформу. Проблема не в фреймворка а в том что вы сильно завязываетесь на его реализации.
Ему 2 года назад об этом сказали, но он предпочел не услышать и нагромоздил жесточайшую завязку уже на внутряки yii2.

Re: С какой целью разрабатывается фреймворк

Добавлено: 2019.04.02, 10:06
maleks
TM123 писал(а): 2019.04.01, 18:20 когда люди стали отказываться работать на Yii 1.1 и вот опять я в перспективе 1-2 лет окажусь у того же самого разбитого корыта и потрачу еще полтора года на скрещивание уже 3-ех фреймворков.
уже оказались. Песенка yii2 уже спета то.
TM123 писал(а): 2019.04.01, 21:27 Для сайтостроя фреймворк слишком тяжелый и сложный,
Фрейм этот быстрый в работе и легкий для изучения и поэтому отлично подходит для сайтостроения.
Именно что сайтостроения.
А про большие проекты и на чем они создаются (чтобы поддерживались долгое время), можете Дмитрия послушать.

Re: С какой целью разрабатывается фреймворк

Добавлено: 2019.04.02, 10:18
TM123
maleks писал(а): 2019.04.02, 09:54 Ему 2 года назад об этом сказали, но он предпочел не услышать и нагромоздил жесточайшую завязку уже на внутряки yii2.
2 года назад было больше 8MB собственного кода, куда должен был деться этот код? или вы считаете что штат программистов должен был быть увеличен на 2/3 чтобы писать подобного рода решения и самый главный вопрос, если самостоятельно писать системное программное обеспечение, зачем тогда использовать фреймворк? если его все равно надо писать.

Re: С какой целью разрабатывается фреймворк

Добавлено: 2019.04.02, 12:05
samdark
maleks

Дмитрию всё-таки надо продвигать курсы по ООП и другим фреймворкам, так что воспринимать его сверх-буквально не стоит. Хотя приличная часть аргументов верна, Yii 2 нормально используется в умелых руках для очень серьёзных проектов.

И да, это не значит что мы упёрто думаем что там нет косяков. Иначе Yii 3 не было бы даже в планах.

Re: С какой целью разрабатывается фреймворк

Добавлено: 2019.04.02, 12:08
samdark
TM123

Один раз написанный на Yii 1.1 проект мог работать много лет с 2010 до сегодняшнего 2019-го и далее при этом поддерживаясь. Сегодня мы как раз тегнули очередной релиз 1.1: https://www.yiiframework.com/news/206/y ... s-released

То, что разработчикам хочется развиваться мы изменить не можем и не пытаемся. Это неизбежно. Не будет развиваться Yii, разработчики просто перейдут на Symfony или Laravel или что-то ещё, что будет интересней. То есть итог от не выпуска новых версий будет ровно тот же: сложнее найти разработчиков на проект. И это нормально.

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

При этом перед фактом что надо прямо сейчас что-то переписывать мы никого не ставили. Фиксы безопасности выпускаются регулярно даже для 1.1, а уж для 2.0 тем более. Есть множество проектов на Yii 1.1, которые отлично работают. Есть nginx, при помощи которого можно вынести отдельные сервисы на новую версию фреймворка. В конце-концов, есть способы вроде https://www.yiiframework.com/doc/guide/ ... -yii2-yii1. Ровно то же применимо будет и к Yii 3.0. Часть приложения можно будет оставить на 2.0, часть написать на 3.0 если есть такая необходимость.
Нет на рынке серьезных разработчиков, потому что судя по всему их просто мало в принципе и они не светятся на рынке, ну либо мы где-то не там ищем.
Серьёзных действительно не много. Зарплатную планку попробуйте поднять раза в два (или больше) - найдутся. В конце-концов, если проект существует уже 10 лет, наверняка бизнес выстрелил и позволить себе немного, по отношению к обороту, трат на IT вполне можно.

Re: С какой целью разрабатывается фреймворк

Добавлено: 2019.04.02, 12:13
samdark
Причём про серьёзных сильных хороших разработчиков - это не специфично для Yii. Их в принципе мало вне зависимости от фреймворка или технологий. И они редко дёшево обходятся.

Re: С какой целью разрабатывается фреймворк

Добавлено: 2019.04.02, 12:19
TM123
maleks писал(а): 2019.04.02, 09:54 Ему 2 года назад об этом сказали, но он предпочел не услышать и нагромоздил жесточайшую завязку уже на внутряки yii2.
Ради интереса перечитал свои мысли, я уже забыл что задавал эти вопросы и наблюдаю что прошло 2.5 года, а по поднятым тогда вопросам ничего путного в фреймворке не произошло, что расстраивает.

Если говорить о фреймворк-независимости, то визуальная библиотека не зависит от фреймворка, да придется написать небольшой адаптер для нового фреймворка. Специализированная версия ActiveRecord для PG зависит в большей степени, но тоже написанием адаптера можно порешать проблемы, с контроллерами это полностью посадка на фреймворк. Если подводить итого под разработанными системными доработками, то они направлены на формирование среды исполнения специализированной для корпоративной разработки и по сути остается один шаг до того, что можно будет просто отказаться от фреймворка, даже при нынешних зависимостях это не так сложно. Проблема в другом, нет желания написать свой фреймворк или нечто подобное, моё личное мнение это задача фреймворка формировать среду исполнения и Yii больше фреймворк для корпоративной разработки, а не для сайтостроя, но все что я наблюдаю, из грузовика способного возить тонны груза пытаются сделать красивую маленькую легковуху, но все время вылезают огромные колеса со злой резиной, чадящий выхлоп мощного двигателя и т.д.

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

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

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

Я уже давно понял что не бывает серьезного функционала за бесплатно, хотя Linux пытается нам доказать и это у него с переменным успехом получается, связано все это по всей видимости со спонсорством команд разработчиков крупными IT компаниями запада, Yii не только бесплатный проект, но все как я понимаю осложняется тем что вся команда работает на чистом энтузиазме, поэтому так себя ведет. Жалко, но я наверное буду пытаться слезать с Yii, в какую сторону не знаю, но вектор развития фреймворка мне не нравится, Yii очень напоминает УАЗ Патриот, прекрасная машина, хорошо бегает по дорогам, уже в базовой комплектации реальны внедорожник, в общем масса достоинств, есть только одна проблема - разваливается на ходу, в любой момент можно встрять без движения. Ахелесова пята Yii - тотальная несовместимость версий, в любой момент может выйти новая версия и оказываешь перед необходимость значительных инвестиций в проект. Если кто-то хочет обсудить фреймворко-независимость, я все свои мысли высказал ранее, ничего не изменилось, нет смысла в прикладной компании потребители мутить фреймворко-независимость, это слишком усложняет и удорожает проект, не считая всех проблем с поиском программеров куда более высокого уровня, чем ...

Re: С какой целью разрабатывается фреймворк

Добавлено: 2019.04.02, 12:44
TM123
samdark писал(а): 2019.04.02, 12:08 То, что разработчикам хочется развиваться мы изменить не можем и не пытаемся. Это неизбежно. Не будет развиваться Yii, разработчики просто перейдут на Symfony или Laravel или что-то ещё, что будет интересней. То есть итог от не выпуска новых версий будет ровно тот же: сложнее найти разработчиков на проект. И это нормально.
Я не против развития, я говорю о том что должна быть обратная совместимость, ее отсутствие вот это проблема.
samdark писал(а): 2019.04.02, 12:08 Выпустить Yii 3.0 соблюдая обратную совместимость не получится потому как вся его идея в том, чтобы поменять не устраивающую нас базу, что позволит строить без проблем проекты в любом стиле, в том числе и вот то, о чём Дмитрий рассказывает в своих скринкастах последнее время. 4.0, скорее всего, получится сделать без сильного слома совместимости.
Не готов судить можно ли было или нельзя, ибо не знают пока ничего о 3, но 1.1 и 2 не совместимы и это понятно и по другому было нельзя, но были очень жирные надежды что после разрешения проблем из-за которых 1.1 оказалась не совместима с 2, дальше тема несовместимостей будет закрыта, именно поэтому и было принято решение переходить на 2 и сделано столько инвестиций в код.
samdark писал(а): 2019.04.02, 12:08 Серьёзных действительно не много. Зарплатную планку попробуйте поднять раза в два (или больше) - найдутся. В конце-концов, если проект существует уже 10 лет, наверняка бизнес выстрелил и позволить себе немного, по отношению к обороту, трат на IT вполне можно.
Куда же больше, 110-130 для программера на подхвате, 150-160 для серьезных программеров. Да у нас есть осложнения в виде не презентабельного офиса, отсутствие соц пакета, но зато у нас на столько большой проект и можно такое количество всего разного пощупать, что на мой взгляд ЗП вполне адекватная, мы длительное время висели с ЗП 130-150 на нескольких работных сайтах в топе списка вакансий поднимая вакансию утром каждый день и не уходя дальше 2-ой страницы. Я может постарел и отстал от жизни, но тупо нет даже откликов!!! и начинают закрадываться мысли что связано это в том числе с Yii, сейчас все носятся как забубененые с Laravel. У меня некоторое количество учеников работает в крупняках IT, финансового, банковского, сырьевого сектора, нигде не платят ЗП в 2 раза больше чем мы предлагаем, у всех примерно так же, есть несколько знакомых на уникальных продуктах которые получают больше, но и это не в 2 раза. Когда люди из числа прикладников решающих конкретные проблемы слышат подробности того как и что у нас сделано, они говорят как?, мы даже мечтать об этом не можем, а вы говорите об этом как о мелочах каких-то, а наши планы считаются вообще какой-то фантастикой, но тем не менее у нас тотальная проблема с кадрами.

Re: С какой целью разрабатывается фреймворк

Добавлено: 2019.04.02, 12:47
TM123
samdark писал(а): 2019.04.02, 12:13 Причём про серьёзных сильных хороших разработчиков - это не специфично для Yii. Их в принципе мало вне зависимости от фреймворка или технологий. И они редко дёшево обходятся.
Это все понятно, не первый год замужем. С твоей точки зрения сколько? Я постоянно хозяину и начальнику говорю что мы не в рынке, а только сильно приближены, постоянно привожу примеры сколько мои знакомые платят подчиненным или сами получают, но ни у кого нет Yii. Сколько серьезный разработчик стоит на Yii. Я знаю свою ЗП, но она не показатель, потому что помимо самого Yii я еще много чего знаю, умею, делаю + я играющий тренер.

Re: С какой целью разрабатывается фреймворк

Добавлено: 2019.04.02, 13:44
ElisDN
TM123 писал(а): 2019.04.02, 10:18 или вы считаете что штат программистов должен был быть увеличен на 2/3 чтобы писать подобного рода решения
Если бы ваш десятилетний код (8МБ) был разделён на более-менее независимое ядро (7,5МБ) и адаптеры (0,5МБ), то для обновления/смены фреймворка вы переписывали бы только адаптеры, почти не трогая свой код. Если же изначально и до сих пор весь он написан без разделения сильно сплетённым лапшекодом, то логично, что на любое изменение фреймворковского кода приходится переписывать кучу смешанного с ним вашего. И фиксить каждый раз много, и переписать всё уже нереально. И такой ад теперь у вас навсегда.
TM123 писал(а): 2019.04.02, 10:18 самый главный вопрос...
Главный вопрос как раз в том, что перед разработкой проекта на 5+ лет задают ли авторы себе стратегические вопросы:

- Что будет, если фреймворк перепишут целиком с 1 на 2?
- Что будет, если фреймворк загнётся как CodeIgniter?
- Что будет, если Kartik не обновит свои виджеты?
- и т.п.

Если задают, то сразу думают, насколько глубоко нужно интегрироваться и насколько сильно полагаться на конкретный фреймворк. Использовать его напрямую или через аддаптеры. Смешивать свой код с фреймворковским или отделять бизнес-логику от представления и инфраструктуры.
TM123 писал(а): 2019.04.02, 10:18 если самостоятельно писать системное программное обеспечение, зачем тогда использовать фреймворк? если его все равно надо писать.
Если воспринимать фреймворк как внешний каркас для разработки в нём своего проекта, то всё нормально. Пишем именно свой проект, иногда подтягивая фреймворковские компоненты через прослойки, но чётко отделяя свой код от фреймворковского.

А если же просто ставим фреймворк и бездумно фигачим весь код по его правилам, а не по своим, то навсегда становимся его заложниками.
TM123 писал(а): 2019.04.02, 10:18 чтобы писать подобного рода решения
Все те самые нелюбимые в мире Yii наборы рекомендуемых принципов и паттернов вроде SOLID, GRASP и подобных придумали не просто так, а вывели из проблем существующих крупных проектов как раз как полезные советы, чтобы разработчики новых проектов не совершали этих же ошибок.

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

Re: С какой целью разрабатывается фреймворк

Добавлено: 2019.04.02, 13:48
ElisDN
TM123 писал(а): 2019.04.02, 12:19 моё личное мнение ... Yii больше фреймворк для корпоративной разработки, а не для сайтостроя, но все что я наблюдаю, из грузовика способного возить тонны груза пытаются сделать красивую маленькую легковуху, но все время вылезают огромные колеса со злой резиной, чадящий выхлоп мощного двигателя и т.д.
Как раз наоборот: Yii - это построенная любителями в свободное время легковуха, которая хочет тягаться с коммерческими корпоративными грузовиками.

Re: С какой целью разрабатывается фреймворк

Добавлено: 2019.04.02, 14:01
ElisDN
TM123 писал(а): 2019.04.02, 12:44 Я не против развития, я говорю о том что должна быть обратная совместимость, ее отсутствие вот это проблема.
Не думайте, что пять раз переписывать с Laravel 1 на 2,3,4,5 вам было бы суммарно сильно проще, чем один раз Yii с 1 на 2.

Просто у Yii нет промежуточных полусовместимых версий вроде 2.0, 2.1, 2.2, ..., 2.8, 3.0 как у Laravel и Symfony для постепенного обновления, а есть только взрывные 1, 2 и 3 раз в пять лет. В этом и дело.

Re: С какой целью разрабатывается фреймворк

Добавлено: 2019.04.02, 14:24
TM123
Прокомментирую только кусок, остальное будет с моей стороны переливание ...
ElisDN писал(а): 2019.04.02, 13:44 Главный вопрос как раз в том, что перед разработкой проекта на 5+ лет задают ли авторы себе стратегические вопросы:

- Что будет, если фреймворк перепишут целиком с 1 на 2?
- Что будет, если фреймворк загнётся как Kohana?
- Что будет, если Kartik не обновит свои виджеты?
- и т.п.

Если задают, то сразу думают, насколько глубоко нужно интегрироваться и насколько сильно полагаться на конкретный фреймворк. Использовать его напрямую или через аддаптеры. Смешивать свой код с фреймворковским или отделять бизнес-логику от представления и инфраструктуры.
Да каюсь, распрощавшись 10 лет назад с мелкомягким и его .NET в пользу PHP я предполагал что люди пишущие на PHP исповедуют стратегию PHP - обратная совместимость, да несовместимость может быть, но не тотальная и иногда, все когда-то меняется, но я совершенно не ожидал что каждая следующая версия будет не совместима с предыдущей. Мне очень "нравится" позиция команды разработчиков MS, которая победила в начале 2000-ых, нас не интересует обратная совместимость, мы пишем все на острие технологий и не собираемся тащить за собой всякий технологический хлам тратя ресурсы на обеспечение обратной совместимости. Что мы в результате имеем, последняя операционка от MS, которая не требовала практически полного обновления покупного софта была Vista, большая часть софта от XP в ней работала, потом началась вакханалия, что даже софт от Vista не работал на семерке, не говоря уже о XP. Ну допустим 200 баксов за ОС можно заплатить, но с какой радости я должен платить 2000 баксов за новую версию фотошопа, меня полностью устраивает и старая, да и ОС устраивает, но вынужден купить другую из-за того что нет дров.

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

Если сделать коррекцию на такого рода подход, то я 8 лет назад не стал бы использовать фреймворк, а продолжил пилить свою робкую попытку написать свой фреймворк. Вопрос стоит в том, что делать сейчас. Если меня оставили бы в покое на полгода и не дергали со всех сторон, то то что написано можно достаточно легко перевести в фреймворко-независимое состояние, но этого времени нет. Другой вариант, выбросить из Yii 2 80% файлов фреймворка, т.к. они не используются, из оставшихся выбросить половину методов т.к. они так же не используются, дальше по тому же принципу выбрать функционал из Yii 1.1 и скрестить ужа с ежом создав некую среду в которой будет работать и тот и другой код и дальше жить на этом дикобразе со всеми траблами того, что этого дикобраза 2-ух фреймворков смогу поддерживать только я, потому что сколько у нас не было людей, писать прикладной функционал в проекте могут многие, но делать доработки в прослойку между фреймворком и проектом не смог никто, а эта прослойка сейчас на столько простая по сравнению с самим фреймворком, что предполагать что кто-то сможет сладить с дикобразом глупо, как и так же глупо предполагать что мы сможем заполучить еще одного такого же опытного чела как я, они есть, но только они все устроены и за них держатся зубами. При этом Yii 3 вообще не использовать, да и из описания вакансии придется убрать упоминания Yii, потому что этот дикобраз будет уже не Yii, но отсутствие упоминания в вакансии каких либо фреймворков отрицательно влияет на отклик на вакансию и это тоже проблема.

Вот такой вот выбор стоит.