Пользователь
0,0
карма
3,2
рейтинг
1 января в 13:46

Разработка приложений на Yii2 без опыта — прямой путь в АД

Yii*, PHP*


В этой статье речь пойдет о разработке приложений на Yii2. А именно, как в самом начале своего пути без определенного опыта легко поддаться на искушения и свернуть на дорогу, которая ведет прямо в АД. Далее под словом АД предполагается ситуация в которой вы понимаете, что сопровождать ваш код становится все сложнее.

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



Небольшая предыстория
Года три назад я познакомился с отличным инструментом под названием Yii2 и стал тесно с ним работать. Вначале для обучения новым фитчам php5.3 и php.5.4 ну и в дальнейшем для реализации всех своих проектов. Тогда еще у меня были очень большие проблемы с архитектурой, хотя должен признать, что сейчас они тоже есть, но не в таких масштабах. Поэтому, когда я натыкался на множество ошибок, я не придавал им значений, а когда проект вырос, было уже поздно.

Итак приступим.



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

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

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

Процесс разработки приложения на Yii2
Установка Yii2 достаточна простая. С появлением composer установка почти любого инструмента простая. Единственное, что все портит это composer-asset-plugin, с ним у многих возникают проблемы. Кто-то забыл поставить, кто-то обновлялся и не сбросил кэш, в общем проблем и вопросов по этой теме много. Хотя я не буду записывать это в минус, просто скажу, что установка Yii2 достаточно простая.

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

  • basic
    Не знаю как у Вас, но у меня возникал дискомфорт когда проект постоянно разрастался. Нужно было думать как красиво вынести админку, если ее организовать модулем, то появляется большая вложенность, чувство неудобства и еще если вдруг по какой-то причине нужно было бы добавить еще 1 приложение (по перспективе роста как в advanced) дискомфорт увеличивался.
  • advanced
    Как-бы решает дискомфорт с приложениями в basic, но появляется новый дискомфорт. У нас в проекте появляется тонна конфигов для каждого приложения + общие и все модели начинают делиться между приложениями и наследовать друг друга. Еще в некоторых случаях приходилось перекрывать реляции, чтобы дергать классы моделей текущего приложения, а не общего.

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

Примерно с этого момента мы уже взглянули (не ступили, а только посмотрели) на дорогу, которая ведет в АД.

Yii2 — современный mvc framework
Даже если предположить, что все, кто разрабатывает на Yii2 (хоть это далеко не так) следуют парадигме mvc, пишут тонкие контроллеры, жирные модели и не пишут логику в представлениях, работая с Yii2 вы все-равно уже в АДУ.

Дело в том, что разработчики самого Yii2, слишком дословно трактовали MVC при разработке инструмента. В результате модель получается таким божественным классом, который делает все. Модель обычно в лучших традициях унаследована от ActiveRecord, работает с формами, валидацией, содержит логику, реляции, еще одну логику, еще сценарии, и еще 10 логик на каждый сценарий и еще одну логику для логики логик.

Когда проект разрастается и у вас есть модель, которая скажем состоит из 5 сценариев, содержит очень много логики и еще в лучших традициях от нее зависит 80% всего вашего приложения. И тут появляется задача что-то изменить или добавить, а вы понимаете, что у вас не одна такая модель, а целых 10 и все они зависят между собой и чтобы что-то добавить нужно отрефакторить все это дело. Смотрите по сторонам, и видите дорогу с табличкой «Добро пожаловать в АД».

Пожалуй самая основная проблема Yii2 заключается именно в том, что почти все наследуют модели от ActiveRecord и реализуют в ней всю логику. Еще живут варианты, когда логика разнесена по контроллерам и представлениям.

Несколько примеров из жизни (или добро пожаловать в АД):
  • В одном проекте я был свидетелем того, что разработчики придерживались идеи MVC, делали тонкие контроллеры и жирные модели. В результате чего можно было наблюдать несколько моделей из 10 000 — 15 000 строк кода, которые были связанны чуть ли не с большей половиной всего проекта. Естественно настал момент, когда все крестились и просто боялись их трогать, зная что если что-то сломают может полететь весь проект. Это не критично на небольшом проекте, но если проект набирает популярность и разрастается, ждите беды.
  • Если все модели наследуем от ActiveRecord, то на выходе по перспективе получаем так-же букет из проблем. Возможно будет такая ситуация, когда мы унаследуете frontend и backend модели от common моделей, которую в свою очередь от ActiveRecord. Но что будет если вдруг по мимо общей логики, нам потребуется разная логика в frontend и backend приложениях? Скорее всего начнутся перекрывания сценариев, событий таких как afterSave, beforeSave и много других интересных штук. С которыми я сталкивался почти везде.
  • ActiveForm, тут просто facepalm. Это не очень гибкая штука как и 90% виджетов Yii2, они рассчитаны на быструю разработку ну скажем прототипов или максимум админку. Но использовать эти виджеты в большом и сложном проекте не очень хорошая идея. Практически не реально воплощать в жизнь извращенные задачи клиентов. Еще как претензия, это то что разработчики Yii2 прилично смешали php код с js, это можно наблюдать в валидаторах. И на послед, это то что все поголовно зависит от jQuery. Не скажу, что это плохо, но есть еще такой замечательный framework как vanilla (если вы понимаете о чем я ;)).
  • Расширения. Что касается расширений Yii2 (конечно-же от сторонних разработчиков), то 99% этих расширений решают только примитивные стандартные задачи. Если возникает суровая серьезная задача, то в 99% случаях Вам придется писать все самому.
  • И таких примеров очень много.


Разумеется все эти моменты приходятся непосредственно именно на разработчиков. Однако, когда я начинал, я даже и представить не мог, что через год у меня будет более 80 моделей с перекрученной логикой и кучей, просто огромной кучей условий, чтобы хоть как-то "'это" работало. Рефактроинг превращается в АД, потому, что рекурсия зависимостей делает свое дело. Если как-то отрефактроить одну модель, за этим следует рефакторинг почти половины проекта.

Пожалуй самые главные минусы Yii2, которые в свое время мне подпортили жизнь
  • Слишком добрый и много плохого позволяет разработчику. В некоторых моментах даже провоцирует на пакость.
  • Большая связанность компонентов.
  • Изначально Yii2 не вводит такого понятия как слоистая архитектура. В результате чего появляются божественные модели в лучшем случае, ну а в худшем все разбросанно абы как.
  • DI. По сравнению с symfony2 (или 3) в Yii2 DI это игрушка для младенца.
  • ActiveForm. А именно JS api. Хотя на валидаторы чуть-чуть нагрешить тоже можно.
  • Сторонние расширения. В 99% решают только примитивные стандартные задачи.


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

Несколько советов для тех, кто работает с Yii2
  • Пишите хотя-бы юнит тесты. Это здорово выручит, особенно когда это большой проект на Yii2, где все связанно.
  • Предотвращайте появление божественных жирных моделей
  • Не наследуйте все подряд от ActiveRecord
  • Не пишите всю логику в моделях, разделяйте модели на сервисы (на отдельные классы).
  • Старайтесь как можно сильнее избегать связанности.
  • Не пишите логику в видах и контроллерах.
  • По вечерам уделите время Symfony 2(или 3), чтобы расширить кругозор.


Еще в качестве дополнения я хочу ответить на некоторые популярные вопросы:

Какой framework выбрать новичку?
Профессиональный разработчик может выбрать абсолютно любой инструмент для разработки проекта. Что касается новичка, я бы рекомендовал брать Symfony 3. Просто поверьте на слово. Да будет тяжело, да будет желание уйти, да будут жалобы. Нужно перетерпеть и просто сидеть на Symfony 3. И так до тех пор пока вы не разберетесь с архитектурой и не получите хорошие знания «как это работает». После этого вы сможете избежать многих ошибок в Yii2.

Подходит ли Yii2 для больших проектов ?
Да. Yii2, как и любой другой современный инструмент подходит для любого проекта, но обязательным условием должно быть то, что вы или представители вашей команды хорошие инженеры. Иначе, когда проект разрастется вы проснетесь в АДУ.

Symfony2 vs Yii2, что круче ?
Раньше я всегда двумя руками защищал Yii2 и грешил, что Symfony2 медленная, жирная, в ней много чего не нужного и тп. Обращаюсь ко всем симфонистам: Ребята простите, я никогда так не ошибался.

Что касается ответа на этот вопрос, как говорил Александр Макаров на одной из конференций: «Yii2, это другая ниша».
Сравнивая Symfony2 (или 3) с Yii2, это наверно как сравнивать велосипед с автомобилем.
В теории на велосипеде тоже можно проехать 500 км., однако будьте готовы запастись клеем и заплатками.
И при этом тем не менее многие бы сейчас с удовольствием расслабились и покатались на велосипеде.

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

Далее, если тема кому-то интересна, то в следующей статье я попробую рассказать о том, как можно встать на путь истинный и более-менее красиво работать с моделями в стиле Yii2.
@nepster09
карма 0,0
рейтинг 3,2
Реклама

Похожие публикации

Комментарии (88)

Voenniy
+7
Года три назад я познакомился с отличным инструментом под названием Yii2 и стал тесно с ним работать.


Yii2 релизнулся чуть более года назад.
Ну и слишком абстрактная да и спорная статья. Ни одного примера.

Кстати, новичку я как раз советую Yii2. Просто поверьте на слово (с)
nepster09
0
Это в стабильном релизе. Альфу и Бету никто не отменял.
Я был тем самым новичком и сейчас не очень доволен.
Voenniy
+2
Вы плотно начали работать на альфе версии фреймворка который каждый день изменялся без обратной совместимости?
nepster09
0
Так, я ж указал, что начинал для обучения. Учиться на альфе как раз было интересно. Я не писал боевых проектов, а писал свой тестовый проект, и каждый раз когда что-то ломалось, я понимал все больше как устроен инструмент. Вы походу вообще статью не поняли. Смысл даже не сколько в коде, а в архитектуре приложения, которую предлагает Yii2.

Когда проект разрастается, многие моменты выходят боком. Вы либо очень хороший программист, либо не писали на Yii2 ничего сложнее блога.
SamDark
+3
Yii не предлагает архитектуры. Вообще. Никакой. Слои вы там захотите или гексагональную архитектуру или микросервисы — это ваше дело. Фреймворк и не должен навязывать архитектуру. CMS — да, но не фреймворк.
nepster09
0
Вот тут большой вопрос. Что значит «Yii не предлагает архитектуры.»? Есть 2 часто используемых шаблона, по которым 99% сообщества работают. Может быть вы хотели сказать: что в Yii можно реализовать любую архитектуру?
zelenin
+2
эти два шаблона предлагают пример организации кода. в них например не оговорено о наследовании моделей из common в остальных частях. Т.е. там вообще не про архитектуру.
nepster09
0
Там в каждом демка. Да и обычно все просто: один сделал, а остальные скопировали.
SamDark
0
Сомневаюсь, какой-либо фреймворк показывает с порога в шаблоне приложения выстроенный доменный слой. Просто потому, что доменный слой разный для каждого приложения.
SamDark
+1
Шаблоны приложений не дают никакой архитектуры. Они не говорят вам, как именно реализовывать логику, как будут общаться разные части приложения, на сколько серверов оно будет разбито, будут ли очереди и всё такое. Положить модели в папку models — это ещё не архитектура. Это базовая организация кода.
Fesor
+4
архитектура никакого отношения к фреймворку не имеет. И это ваша ошибка как новичка. Полагать что фреймворк все сделает клево за вас. Возьми вы symfony + doctrine вышла бы та же ситуация.
nepster09
–1
Не совсем так на самом деле. В случае с symfony сообщество более квалифицированное, примеры кода и подходы более правильные, + symfony открывает глаза сразу на слоистую архитектуру вводя понятие сущностей, сервисов, репозиториев и тп.

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

Fesor
+1
примеры кода и подходы более правильные


Вот честно, я в опенсурс проектах видал всякого и только парочка проектов могла похвастаться чем-то хотя бы отдаленно похожим на красивую архитектуру. Есть решения на базе компонентов Symfony которые неплохи но не более.

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

Посетите форум Yii2 сообщества и посмотрите на примеры публикации кода


Мне хватает примеров того что выкладывают PHP-ники в Symfony или Laravel комьюнити. Это проблема любого хоть сколько нибудь популярного решения.
zelenin
+1
это не совсем так. с декабря 2013 года (альфа) обратная совместимость нарушилась только один раз. В остальном кодовая база была достаточно стабильна (для написания проектов «для себя»).
HaruAtari
+3
Так ваша проблема была не в Yii, а в отсутствии опыта как такового. Дай новичку симфонию — он нагородит такого же говна, так еще и разбираться будет в несколько раз дольше.
Человек, который понимает, что такое ООП, MVC и паттерны (именно понимает, а не тупо следует их реализации в конкретном фреймворке) будет везде писать хороший код. А тот, кто этого не понимает по определению не может написать что-либо нормальное.
nepster09
0
Все верно. Там в статье в заголовке пометка даже про опыт стоит. Да с вами полностью согласен, и при этом симфони более строгий инструмент и открывает глаза на интересные вещи. И строит более правильное понимание об архитектуре.
shoomyst
–1
Раньше я всегда двумя руками защищал Yii2 и грешил, что Symfony2 медленная, жирная, в ней много чего не нужного и тп.

Так со всеми «академическими» решениями. Так было с ZF1, так было/есть с Doctrine. В середине 00-ых сам был в этом лагере :) Оглядываясь назад, могу предположить, что в основе навешивания монструозных ярлыков лежит боязнь не осилить «слишком умный и академически правильный» фреймворк.

Я всегда называю Sf/ZF следующим этапом в развитии php-разработчика, на что многие yii/laravel-разработчики обижаются. Но это пишется не для того, чтобы вас потроллить или потешить свое ЧСВ. Это пишут люди, сделавшие этот шаг, и делящиеся опытом. Но очень важно, чтобы у этих людей был большой опыт на этом новом этапе, поэтому не слушайте людей, которые неделю покодили на Symfony и называют себя гуру разработки.

Я бы еще посоветовал не зацикливаться на php, не закрываться в этом php-мирке и веровать, что он решит все ваши проблемы. PHP сегодня не сможет соревноваться в фронтенде с js/node, с тем же go в быстродействии и т.д. Но это не значит, что надо бросать php и переписывать все свои проекты на Scala или Haskell. Важно просто смотреть в сторону совмещения/сосуществования различных инструментов. Возможно стоит почитать про микросервисы. Можно конечно считать всё это хипстотой, но если вы будете полагаться лишь на php, скорее всего вы проиграете.
nepster09
+1
Полностью согласен, щас рулит стэк из технологий. Ни один большой проект не обойдется одном php.
Что касается «Я всегда называю Sf/ZF следующим этапом в развитии php-разработчика», походу хабро-сообщество не сильно оценило мой шаг вперед =).

П.С. Zend что-то не серьезные. Обещали релизнуть zf3 еще в прошлом году и так и не релизнули походу =(.
Fedcomp
0
Собственно а что вам не нравится в laravel?
Alexufo
0
Есть ощущение какого-то огорода из за его модульности. Четкой позиции партии нет — для начала работы нужно обвешаться плагинами как следует, которые поддерживают стороние разработчики. Как это поведет все себя в будущем, никто не знает. yii2 как то в этом плане более серьезен.
Mendel
+2
Дело даже не в том, что поддерживается сторонним разработчиком.
Для всех этих базовых вещей приходится делать выбор.
В одной компании имеется десяток проектов на ларавел.
Для скорости их заказали на аутсорсе у разных команд.
А в штат взяли одного ларавельщика для дальнейшей поддержки этого всего.
Как вы понимаете бедный, бедный мальчик.
Там не было ни одного проекта с одинаковым набором базовых компонент.
Разные шаблонизаторы, разные RBAC…
ШЕСТЬ РАЗНЫХ RBAC! Шесть Карл!
Fesor
0
Собственно а что вам не нравится в laravel?


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

— А что такое dependency injection?

Ну вот как-то так. Сам фреймворк ок, но на нем легко сделать не ок, а до 5-ой версии воспринимать его серьезно я вообще не могу.
SamDark
+1
Разве не легко сделать не OK используя Symfony? Интересно, многие ли симфонисты на вопрос про DI понесутся рассказывать сходу про аннотации, контейнер и «что-то там внутри само»… я припоминаю, что когда работал на J2EE проектах со Spring, туча народа просто не понимала, что вообще происходит с этим DI и что это на самом деле такое, хотя работали со всем этим практически каждый день.
Alexufo
+1
PHP сегодня не сможет соревноваться в фронтенде сс js/node, с тем же go в быстродействии и т.д.

Это нужно раскрыть. Вот смотрите
www.hostingadvice.com/blog/comparing-node-js-vs-php-performance
Alexufo
+1
По ссылке выше есть таблица
image
Посмотрите где там hhvm, а ведь php7 (на графике php 5.5 ) совсем рядом по производительности.
shoomyst
0
У меня есть некоторые сомнения по этим графикам, но так или иначе, говоря про соревнование, я все же имел в виду не производительность, а предлагаемые инструменты для разработки клиентской части приложения.
Alexufo
+1
эм… ну если клиентская часть то этож не го и не пых.
zelenin
+1
как раз, смотря на график hhvm, можно его понимать и как php7. Поэтому с производительностью неплохо. Тем не менее эти графики в совокупности у меня тоже вызывают сомнения — непонятно что с чем там меряли и корректно ли это.
AlexGx
+1
У меня большие вопросы как к этому бенчмарку (как можно сравнивать водпресс приложение с кодом на ноде который просто отвечает хелло ворлд), так и компетентности автора статьи по ссылке (в коментах он вообще чушь несет, про хендшейки и установление сессий на стороне ноды). Если бы я сравнивал php с нодой, то сравнивал бы с reactphp.
zelenin
+7
статья некорректна в том, что приписываются минусы фреймворку в том, что на самом деле является минусом разработчика, т.к. он следует неким практикам, принятым в yii-сообществе, но не требуемым устройством фреймворка. То есть дело в том, что разработчик пишет «как все», а не как правильно.

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


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

Дело в том, что разработчики самого Yii2, слишком дословно трактовали MVC при разработке инструмента. В результате модель получается таким божественным классом, который делает все. Модель обычно в лучших традициях унаследована от ActiveRecord, работает с формами, валидацией, содержит логику, реляции, еще одну логику, еще сценарии, и еще 10 логик на каждый сценарий и еще одну логику для логики логик.


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

В одном проекте я был свидетелем того, что разработчики придерживались идеи MVC, делали тонкие контроллеры и жирные модели.

ты превратно понимаешь mvc — он не о тонких контроллерах и жирным моделях.

ActiveForm, тут просто facepalm. Это не очень гибкая штука как и 90% виджетов Yii2, они рассчитаны на быструю разработку ну скажем прототипов или максимум админку. Но использовать эти виджеты в большом и сложном проекте не очень хорошая идея. Практически не реально воплощать в жизнь извращенные задачи клиентов. Еще как претензия, это то что разработчики Yii2 прилично смешали php код с js, это можно наблюдать в валидаторах. И на послед, это то что все поголовно зависит от jQuery. Не скажу, что это плохо, но есть еще такой замечательный framework как vanilla (если вы понимаете о чем я ;)).


вот тут полная правда: виджеты yii2 — полный ад. Перефразируя Тему, «так программируют только чудаки».

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

С настроением статьи согласен, с аргументами частично.
zelenin
0
добавлю, что можно и на yii2 напрограммировать красиво, было бы желание, но yii будет всячески «мешать» этому своей сильной связанностью.

поэтому, как и автор поста, «втоплю» за симфони :-)
nepster09
–3
Да все верно. Я даже уточнил в статье, что Yii2 это не плохой инструмент. И все приходится именно на опыт разработчиков. Но тем не менее, сколько человек из многочисленного сообщества пишут хороший и грамотный код на Yii2?

Даже Qiang Xue аккуратненько свернул на GO, подальше от Yii2 =).
zelenin
0
в паблике я не видел хорошего кода на yii2.

nepster09
0
Вот ты сейчас обидел конкретно определенных людей, https://github.com/yiisoft-contrib/yiiframework.com
zelenin
0
юмор?
там я сразу увидел is_file в модели. Модель не должна касаться файловой системы. В общем эта тема не для обсуждения стороннего кода) если хочешь в личке накидаю косяков)
nepster09
0
конечно юмор. Там сами разработчики на форумах писали «так не делать», а много приколов встречается в их-же коде.
А все почему?
SamDark
+1
Не стоит передёргивать насчёт «срулил» и, тем более, насчёт «подальше».
Alexufo
+1
Про отсутствие функциональных расширений распишите подробнее?
zelenin
+1
автор высказал тезис про отсуствие инетерсных расширений, дескать, есть только базового уровня. Я согласен. Практически 100% расширений — это джуниорские поделки (у самого на гитхабе за 2014 год есть таких несколько).
Alexufo
0
такс) интересные, базовые, функциональные это мягкое, колкое и зеленое))) Интересные расширения это интересно)))
А вот, к примеру, как к этому расширению относитесь? Довольно нехилый набор параметров для постройки таблиц из бд.
demos.krajee.com/grid
zelenin
0
к Картику у меня следующее отношение — мне кажется он предвестник армагеддона, настолько у него индусский код. Это раз.
А два: виджеты это новичкам от новичков. Очень важная причина популярности yii среди новичков — наличие виджетов для базовых вещей.
Три: все-таки под функциональными расширениями имелось что-то более крупное, чем клиентские улучшения для админки.
Alexufo
0
Переделывать виджеты пд себя самоубийство. Проще свой сделать. За код и их развитие отвечает только он. Волновать может только их безглючная работа и скорость. (то что виджеты тормозят это да, ну извиняйте, плата за универсальность) Но то что они прекрасно работают и сверхуниверсальные — отрицать ну никак нельзя.
Смотрите как интересно получается — вы связываете популярность у новичков с готовыми решениями из коробки. Вот у визуал студии есть дизайнер форм из коробки, базовая вещь, это тоже причина популярности среди новичков? Конечно! Это абсолютно нормальтная закономерность — чем больше позволяет инсрумент тем больше людей найдут в нем решение своих задач.
Мы смотрели и крутили Го, интересно весело и круто, ну и куда он впился без готовых для работы виджетов? Переходить на ext-js? Спасибо — не надо. Почему стало плохо наличие виджетов для базовых вещей?
Одно замечание — я не хочу наш опыт объявлять святым. Мы всегда отстаиваем свой опыт в кругу своих задач. Отсюда какие то бесконечные разногласия.
Ну по последнему пункту возразить мне нечем, поскольку тут получается что коли что хотели более крупное, но вот что, да и имеет ли тогда это отношение к виджетам.
zelenin
0
наличие виджетов для базовых вещей — это супер. Но это не важная фича в целом. А реализация виджетов вообще ужасна. Поэтому чуть только админка усложняется и сразу виджеты легче выбросить, чем сконфигурировать.
SamDark
+1
Не согласен. Просто надо знать, на что смотреть:

github.com/yii2tech
github.com/codemix
github.com/creocoder

Тут всё очень даже. И это, естественно, не полный список.
zelenin
0
да конечно все я это видел. Это то, что называется «исключение, подтверждающее правило». Есть расширения с хорошим уровнем абстракции, хорошим конфигурированием, продуманностью удобства для конечного разработчика, а не сделанное под конкретный проект. Но их мало. Таких разработчиков 5-10 на все сообщество.
VolCh
–1
есть практики, где принято всю бизнес-логику запихивать в модели, хотя очевидно ее надо выносить в сервисный слой.

Модель и предназначена для бизнес-логики, её основная функция — моделирование и реализации бизнес-логики. Сервисы — это уровень контроллера в MVC по умолчанию. Если очевидно и бизнес-логику поместить в сервисы, то что останется в модели? Просто DTO?
Fesor
+3
Эх, опять эти три волшебных буквы MVC.

Модель в MVC это что угодно, что хранит состояние данных и занимается обработкой. Что там внутри, сервисы и дата мэппер, актив стэйт/актив рекорд, просто PHP возвращающий наружу имутабельные DTO — это все деталь реализации и скрыто инкапсуляцией. Контроллер вообще об этом ничего знать не знает и не хочет.

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

Итого, сервисный слой тикакого отношения к MVC не имеет, это деталь реализации модели. Вместо того что бы обсуждать что там есть в MVC и какое место занимает, лучше обсуждать о том как эти штуки взаимодействуют друг с дружкой, почему именно так и чем так плох smartui что пришлось выдумывать эту чушь.
VolCh
0
Сервисный слой — деталь реализации контроллера, если, например, хочется инкапсулировать от объекта контроллера детали реализации хранения данных моделей или просто делегировать хранение чтобы не захламлять код. Но это деталь реализации именно контроллера, контроллер должен знать какой сервис дернуть, чтобы получить нужную ему модель

А вот как раз модель ничего не знает и не хочет знать о том, как она хранится и хранится ли вообще ) Она знает и хочет знать только о предметной области, в которой, как правило, нет понятия даже «сохранить документ», не говоря об «обновить записи в базе данных».
Fesor
0
Сервисный слой — деталь реализации контроллера


Контроллер — адаптер между приложением и HTTP. Не более. Его задача — выдрать данные из HTTP запроса и попросить модель отреагировать на действия. Как — вызвав метод конкретного сервиса, пробросив команду в шину команд или еще как — это уже деталь реализации именно модели. Приложение не зависит от UI, UI зависит от приложения. Вы же не будете говорить что «приложение является деталью реализации контроллеров или UI».

А вот как раз модель ничего не знает и не хочет знать о том, как она хранится и хранится ли вообще

Вы путаете понятие «модель» и «сущность». Ну или просто смешиваете эти понятия. Как говаривал Эрик Эванс — выражайте модель через сервисы и сущности.

И да, скажите, вам правда так «удобнее» воспринимать все это? Со всеми этими дополнительными вещами, деталями, усложнениями и т.д.? То есть простая до ужаса идея отделения UI от приложения превращается в дико сложную хрень которую каждый трактует как хочет и по итогу получает толстые контроллеры и отсутствие этого самого разделения.
VolCh
0
Контроллер — адаптер между приложением и HTTP.

Адаптер между HTTP и приложением в нашем случае — php-fpm или mod_php, плюс фронт-контроллер, передающие в конкретный контроллер уже данные приложения, пускай не объекты модели, но хотя бы объектную обертку над HTTP-запросом, понятную приложению.
Приложение не зависит от UI, UI зависит от приложения.

Приложение состоит из UI, модели и «клея», обеспечивающего их взаимодействие. Клей принято называть контроллером в Model2 :)
Вы путаете понятие «модель» и «сущность».

Не путаю. Но смешиваю, да. как и Эванс :)
Как говаривал Эрик Эванс — выражайте модель через сервисы и сущности.

Ветка началась с утверждения, что бизнес-логику нужно помещать не в модели, а в сервисах, что естественно навело на мысли о сервисах в смысле Фаулера, а не в смысле Эванса.
И да, скажите, вам правда так «удобнее» воспринимать все это?

Да, удобнее. Чётко разделив обязанности каждого слоя, не возникает (ну, редко) вопросов куда поместить ту или иную функциональность.

То есть простая до ужаса идея отделения UI от приложения

Отделения в приложении UI от логики домена и их обоих от остальной инфраструктуры. Да, может получиться толстый контроллер, если инфраструктуры много, или толстая модель, если бизнес-логика сложная, но стратегически разделение произведено и дальше повышать уровни абстракции можно чуть ли не автоматически по алгоритмам типа «в методе не должно быть больше 7 строк».
Fesor
0
Адаптер между HTTP и приложением в нашем случае — php-fpm или mod_php, плюс фронт-контроллер, передающие в конкретный контроллер уже данные приложения


public function anyControllerAction(Http\Request $request) {
    $resultDTO = $this->get('some.app.service')->doSomeStuff($request->get('foo', $request->get('bar'));
    
    return new Http\JsonResponse($resultDTO, 201);
}


нэймспейсы как-бы намекают что контроллеры являются именно адаптерами между интерфейсом (в нашем случае HTTP) и приложением. В этом суть GRASP-контроллеров и в этом суть Model-View-Adapter (MVC на бэкэнде никогда небыло. Если не верите, сравните диаграмки канонического MVC и MVA).

Приложение состоит из UI, модели и «клея», обеспечивающего их взаимодействие. Клей принято называть контроллером в Model2 :)


Или адаптером в MVA, Model2 это развитие MVA с уточнением о том что есть еще логика сохранения этого добра.

Не путаю. Но смешиваю, да. как и Эванс :)


Нууу… у Эванса сущности это часть модели но не вся модель.

Ветка началась с утверждения, что бизнес-логику нужно помещать не в модели, а в сервисах

Я это понимаю. А я лишь написал что говорить в контексте MVC про сервисный слой не имеет смысла так как сервисный слой — элемент модели в контексте MVC.

Да, может получиться толстый контроллер, если инфраструктуры много

Инфраструктура так же выносится в сервисы уровня инфраструктуры. Раз уж мы про слои заговорили. Это все же логика приложения. Что мы будем делать с толстыми контроллерами и сложной инфраструктурой через год, когда понадобится делать микросервисы или для целей тестирования добавлять CLI интерфейс к приложению, или Pub/Sub для websockets и т.д.

нынче WEB это далеко не только тупо формочки. И это надо учитывать.
VolCh
0
Похоже у нас разные понимания термина «приложение». Давайте договоримся об одном?
Fesor
0
Если вас смутила вот эта фраза:

Инфраструктура так же выносится в сервисы уровня инфраструктуры. Раз уж мы про слои заговорили. Это все же логика приложения.


То это похоже я упоролся к вечеру. Я хотел сказать что без инфраструктуры никак конечно, но это НЕ основная часть приложения. Она лишь поддерживает его работу. Контроллеры — это часть инфраструктуры и не более.

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

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

Интересный факт. Разработчики как правило не заморачиваются по поводу этих вещей пока не зафэйлят парочку проектов, или, что чаще, пока не сталкнуться с поддержкой уже зафэйленного проекта (свой код не так сильно пахнет). Но возможно у меня выборка не репрезентативна. Просто так же люди не будут пытаться делать свою работу лучше.
zelenin
0
модель включает бизнес-логику, связанную только с самой моделью. сервисный слой включает в себя бизнес нескольких несвязанных моделей + инфраструктурные операции.
Я же говорил скорее о чем-то, что отдаленно связанно с моделью, например различные файндеры, которые принято в yii пихать в модели.
VolCh
0
Ну, это скорее прямое следствие использования ActiveRecord, у которого by design две ответственности: реализация бизнес-логики и логики хранения в базе данных.
zelenin
0
это верно
stalkerg
0
Дело в том, что разработчики самого Yii2, слишком дословно трактовали MVC при разработке инструмента. В результате модель получается таким божественным классом, который делает все.

Я вообще считаю, что для веба куда практичнее делать жирные контроллы и тонкие модели (в меру конечно). Многие товарищи вообще говорят, что MVC для веба (не бизнес приложений) плохая идея (разработчики Pyramid).
Arik
0
Тоже так раньше считал, но когда один файл содержит кучу различных логик, кучу разных инструментов и тем более имеют доступы публичные — тоже еще тот АД. Вам ВСЕГДА надо работать с тонной кода, если только каждый экшн не выносить в отдельные файлы, что тоже гемор. Мне кажется, самое больное место тут – как правильно передать, а тем более добавить в существующий код, нужные параметры для моделей, чтоб она правильно завелась или чтоб ее запуск не был завтра адом, но со времени получается все лучше.
Когда модель становится той еще толстушкой, мне нравится ее делать в своем роде модель-контроллер, которая подключает другие классы модели сгруппированных по каким-то свойствам, либо разбивать на трейты опять же по общим свойствам. Так всегда работаешь с минимальным количеством кода, пусть и файлов плодиться куча. Чем меньше кода трогаем, тем лучше. Приятно ведь когда написана либа раз и все, и ты ее годами не трогаешь, она как танк работает и все тут.
А так кучу раз копи-пастить код и разбирать его из проекта в проект О_О
stalkerg
0
если только каждый экшн не выносить в отдельные файлы, что тоже гемор

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

А не те самые это яйца только в профиль?

Мне в целом нравится как это сделано в Pylons когда контроллер это некий класс который содержит экшены т.е. их можно группировать функционально и создавать внутреннюю логику для избежания копипаста (такие контролеры можно наследовать друг от друга). Ну и конечно если постоянно много однотипных работ с данными то тут надо модель мучить.
VolCh
0
В чём для этих товарищей отличие веба от бизнес-приложений с веб-интерфейсом?
Fesor
0
что для веба куда практичнее делать жирные контроллы и тонкие модели (в меру конечно)


Это называется SmartUI так как бизнес логика из модели в этом случае вытекает в контроллеры, цель которых — выступить в качестве медиатора между UI (HTTP) и приложением (модель в контексте MVC на бэкэнде это граница приложения). То есть у нас уже нет разделения логики представления данных от логики обработки данных (мы же завязываем логику приложения на HTTP).

У SmartUI есть свои преимущества, в частности — простота. Любой дурак сможет разобраться в этом, согласитесь. Для какого-нибудь CRUD-а с независимой логикой для каждого ресурса — это более чем нормальных подход которые позволяет поднять скорость разработки до неимоверных высот. А если еще и с кодогенерацией… ух. И справедливости ради — таких приложений большинство.

Но давайте пройдемся по недостаткам.

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

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

Так же у нас начинаются проблемы с UI. В случае обычного WEB в этом нет ничего страшного ибо все находится в нашем контроле, но если мы делаем API для мобильных приложений — начинается веселье. Есть такая штука как обратная совместимость, и ее надо учитывать минимум 3 месяца после релиза новой версии (по исследованиям фэйсбука именно столько надо что бы подавляющее большинство обновило апу). В итоге в контроллере появляются отвратительные вещи и контролировать все это становится тяжело.

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

Ну и не стоит забывать о таких вещах как микросервисы, без которых реально большие проекты больше ничто не пишет. С толстыми контроллерами это все весьма проблематично (хоть и возможно).

И я не могу сказать что все это сильно плохо там и т.д. и уж тем более не призываю всех делать все исключительно с использованием слоеных архитектур, полной изоляцией инфраструктуры и т.д. Не зря существует понятие "Технический Долг". Есть все-таки здравый смысл. Но это сложно ибо приходится мало того что думать что и почему делаешь, так еще и прогнозировать в каких действиях и решениях сколько профита. Нам же надо задачи бизнеса эффективнее решать. Где-то это эффективнее с толстыми контроллерами, где-то с CQRS + EventSourcing, архитектурами портов и адаптеров и т.д.

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

что MVC для веба (не бизнес приложений) плохая идея


MVC — чисто GUI архитектура, которую изначально придумали как решение проблем десктопных приложений. В контексте WEB все интереснее так как тут мы ограничены request/response моделью. Например по схеме smaltalk-MVC (79-ого года) между моделью и представлением были прямые обзервабл отношения. То есть представление подписывалось на события обновления модели и обновляли свое состояние под текущее. На бэкэнде же используется MVA (Model-View-Adapter), а контроллер (читать про контроллер в контексте GRASP) становится лишь адаптером между представлением и моделью полностью изолируя одно от другого.

Так что да, MVC на бэкэнде не имеет смысла, но никто не использует на бэкэнде MVC — все используют MVA и дальнейшие развития этой идеи (Model2 в частности).

stalkerg
0
1) дублирование кода.

Почему все забывают старые добрые Сишные функции?

MVC — чисто GUI архитектура, которую изначально придумали как решение проблем десктопных приложений.

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

делаем API для мобильных приложений — начинается веселье

Веселье в любом случае начинается, так как вам приходится старое и новое API разводить либо в модели либо в контроллере (как правило это затрагивает все слои).

А вообще есть мысль, что под словом MVC сейчас все понимают разные вещи и его применяют часто не к месту. (Pyramid вообще себя RV фреймворком называет)
Короче надо смотреть конкретные реализации и их минусы, всё крайне сложно. :(
Fesor
+1
Почему все забывают старые добрые Сишные функции?

Мы же в PHP хабе, тут функции исторически недооценивают с появлением автозагрузки классов… что печально конечно.

это всё было сделано для StateFull систем, а современный веб как правило StateLess

Именно. Удешевление памяти сделало свое дело.

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


MVC — это модно. Если у тебя не MVC — ты не модный. Потому даже если у тебя НЕ MVC — говори всем что это не так. Тот же Flux намного ближе к концепциям MVC нежели все остальное. Просто оперирует оно имутабельными штуками и добавился event sourcing, что несомненно плюс.
SamDark
+8
Тогда еще у меня были очень большие проблемы с архитектурой, хотя должен признать, что сейчас они тоже есть, но не в таких масштабах. Поэтому, когда я натыкался на множество ошибок, я не придавал им значений, а когда проект вырос, было уже поздно.


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

Поэтому старайтесь не повторять таких ошибок и не начинать свое обучение на Yii2.


С чего бы вы не начали, первые N проектов как архитектор вы так и так превратите в неперевариваемое месиво. И фреймворк тут не поможет. Ни один.

Если взять ваш абзац «Какой framework выбрать новичку?», его можно переписать и неправдой это не будет:

Профессиональный разработчик может выбрать абсолютно любой инструмент для разработки проекта. Что касается новичка, я бы рекомендовал брать Yii 2. Просто поверьте на слово. Да будет тяжело, да будет желание уйти, да будут жалобы. Нужно перетерпеть и просто сидеть на Yii 2. И так до тех пор пока вы не разберетесь с архитектурой и не получите хорошие знания «как это работает». После этого вы сможете избежать многих ошибок в Symfony 3.
LinGG
+1
Если все модели наследуем от ActiveRecord, то на выходе по перспективе получаем так-же букет из проблем. Возможно будет такая ситуация, когда мы унаследуете frontend и backend модели от common моделей, которую в свою очередь от ActiveRecord. Но что будет если вдруг по мимо общей логики, нам потребуется разная логика в frontend и backend приложениях? Скорее всего начнутся перекрывания сценариев, событий таких как afterSave, beforeSave и много других интересных штук. С которыми я сталкивался почти везде.

можно поподробнее? что за фронтенд модель, которая наследуется от activeRecord?
LinGG
0
пардон, неправильно сначала понял мысль.
LinGG
+1
можно сгенерить «тонкую» модель в common, от нее наследовать 2 модели для кажого приложения. все изменения структуры дб и общая логика остаются в common, индивидуальные методы и прочее — в каждоый отдельной модели. такое разделение логики в других фреймворках сделано как-то более элегантно?
zelenin
0
на самом деле лучше сделать недо-cqrs — отдельная модель для записи (бэк), отдельная для чтения (без валидаторов, поведений и прочего барахла для фронта). Я бы пошел дальше и для фронта вообще реализовал отдельный механизм получения данных на квери-билдере с наполнением голого объекта (см. ниже).
А в других фреймворках нету AR (кроме ларавела) — поэтому модель представляет из себя POPO (plain old php object) — поэтому там такой вопрос не стоит.
LinGG
0
тут дело в том, что модель может из обеих версий изменяться. например User. админ может менять данные и сам юзер может.
zelenin
0
несовсем понял. но очевидно одно — на крупном проекте на фронте не будет AR, потому что это очень тяжело. А на мелком проекте по сути без разницы как ты отструктурируешь свои модели.
Arik
+2
Я конечно могу ошибаться, но если новички, то я бы совсем не советовал использовать фреймворки, тем более такие как Yii, Zend, Symfony, Laravel и т.д. Может все желание перебить быть программистом понимая что все работают с этими фреймворками. Конечно может и хорошо, дойдут до конца только сильнейшие. Даже имея годы опыта программирования, не каждый фреймворк дается легко, через задачу хочется кричать, реветь, бросить все и т.д. До PHP мне вообще не нравилось программировать, я как раз через «не хочу» все делал, все что пробовал навязывали какие-то свои проблемы, свои соглашения и т.д. Столько всего просили держать в голове, столько всего просили сделать чтоб сделать элементарные вещи, мало оставалось места в голове для фантазий и финтов ушами, не давали учиться быть гибче, что-то придумывать самому, делать хоть неверные, но свои решения, а потом самому понимать что ты тот еще говнокодер. Тут я думаю свалило кучу народу, которые планировали/имели желание стать программистами, но из-за такого потока «делай так и не спрашивай почему это так делается» приходили к выводу что это тупо не их и шли работать дворниками.
PHP (без фреймворков, паттернов), если забыть об относительной сложности установки и настройки рабочей среды, сразу все просто было и легко. Да, для серьезных проектов такой подход очень плох, но это новички им бы в азарт тут войти, и думаю в целом лучше изучать не фреймворки, а паттерны что они несут, а потом уже плюшки что каждый фреймворк дает. Так простому новичку, и не только, очень сложно лезть в этот космический корабль со всем готовым — ты только делай как мы просим и все будет хорошо. Хорошо вроде звучит, но ооочень много всего и сразу. Ну и фреймворки как бы просят ждать свои мажорные версии, чтоб более менее использовать новые фишки PHP, и наверно из-за своей «полноты» обновляться так быстро не могут. Может если бы разбить весь фрейморк на части, то было бы легче? Взять тот минимум который нужен для самого простого сайта и плясать от него, а все остальное в расширения, которые можно подключить через тот же композер по мере необходимости, когда ты реально устал сам делать что-то. Очень долго выходил Zend2, такая же история с Yii2, когда 3 ждать никто наверно и не знает. Ларавел вроде как раз и начал выкидывать лишнее, теперь вроде нет генератора форм, надо что-то подключать отдельно. Но это ведь не значит, что нельзя сделать сайт без генератора форм? Или без интернационализации, консольных вещей, почт и т.д.? Эти вещи больше отвлекают в начале, чем помогают по-моему. Без этого фона «у нас много чего готового» и старт был бы для всех легче. Документацию за час всю можно прочитать. За день сайт сделать и понимать что ты попробовал основную часть. За неделю/месяц посмотреть и попробовать топовые расширения и тем более все официальные(?), которые можно будет менять по необходимости. Но основа уже будет крепкая и за короткий срок.
Mendel
0
Отчасти соглашусь с вами. Но только отчасти.
Заметил недавно, что уж очень я отстал от языка и текущих веяний.
Вроде все новшества знаю, но как-то староват.
Еще в пхп4 я оброс своими библиотеками которые превращались в ЦМС (как у всех), менялись, жили своей жизнью, и вот в 2015 у меня наконец не осталось проектов живущих на чем-то старом. Почти все живые проекты на поддержке перенес на юии или ларавел.
Но тот факт что в свое время писал несколько собственных нанофреймворков очень помогало в освоении чужих.
И вот сейчас я понял, что начинаю отставать. Что уже всё немного не так.
Начал писать чисто для себя. Для восстановления понимания — новый велосипед. И я вроде понимаю, что без экосистемы я всё равно его брошу. Что скорее всего ни одного проекта я на нем не напишу. Но пишу чтобы освежить, чтобы улучшить навыки архитектуры…
Я уверен, что начинать новичку нужно с фреймворка в котором он понимает весь код. Чтобы он прочитал документацию, код, комментарии. Почитал статьи с объяснением не «как этим пользоваться» а «почему мы сделали так а не иначе».
Я уверен что тогда не будет таких детских глупостей как у топикстартера.
У меня даже появилась шальная мысль, что может в таком вот учебном контексте может этот «проект» даже и послужит и «взлетит».

Но вот всерьез считать, что голый скелет может летать — это вам в кинотеатр на Марсианина. Нет, поучиться. Блог себе нарисовать.
Сайт-визитку. «Портал». Как замена вордпрессу, да и то с такой же жирной экосистемой вокруг — это пожалуйста. Но все те «ненужные» вещи, которые в «Марсианине» отвинтили — очень даже нужны, и должны быть. И подход как у Ларавел — всё можно поставить из композера это тупик. Очень плохо когда в одной команде, на одном фреймворке везде разные подходы, библиотеки и т.п.
Arik
0
Я немного другое имел виду. Вся IT-сфера относительно молода, еще 10-20 лет назад единицы работали с кодом, такие мозги имели чтоб понять всего с чем они работают! Сегодня только лентяй не собрал на конструкторе сайт, а некоторые даже умудрились написать «Hello world» на php или еще на чем то. Все что вложили вчера сегодня пользуется успехом, была открыта дорога для таких как я. Я не стесняюсь что мне до некоторых как до Марса, и вот такой я решил тут только свою точку зрения написать обо всем этом, возможно, да, ошибочное. Я не говорил что Yii и т.д. плохи, просто такие гиганты не для всех, чтоб сразу начать пробовать надо пройти другие этапы. Нам было легче, потому что мы более менее знакомы с большей частью паттернов, уже поняли что ООП — добро, что преждевременная оптимизация — ЗЛО и т.д. Все сами пробовали на своей шкуре, похоронили тонны кода, или кто-то ткнул носом на факты. Сейчас как я вижу молодых ребят: набросали пару скриптов, вроде сайты работают у них и хотят себе работу программистов с большой ЗП. Открывают вакансии и видят красивые ярлыки Yii, Laravel и т.д. Конечно они открывают оф. сайты начинают разбираться, делают все по документации и… все. На них такой поток данных идет, а вот мы почту шлем, а вот форму собираем, а тут собираем все через elixir, вы еще не поставили Node.js? -неудачник! А теперь вот эту зависимость, а теперь то, а теперь это. Это какой-то огромный поток реки из которой вылетают менее опытные, думая что это все не для них. Закрывают это все и забывают обо всех вакансиях в этой сфере. И вот для них я и говорю что пока рано опускать руки, надо просто изучить паттерны, а потом уже брать на вооружение то что помогает экономить время. Вот тут бы огромный плакат, баннер! Что если тяжело получается с Yii и т.д. попробуйте что легче. И такого легче очень мало и толком не ценится. Вот и пришла мысль, чтоб если один из таких гигантов выкинул все лишнее, то больше было шансов понять новичкам. Я не говорил что будут разные либы или код разный, просто будут отдельными пакетами со своей документацией, что когда надо будет прочитают все и поставят. Мы же не читали весь мануал php или mysql, а по мере необходимости. А у этих гигантов все и сразу идет. Плюс из-за этого сами неповоротливые на обновления. Вспомним Lunix! Одно ядро и кучу пакетов/приложений. Тут я тоже хотел. Оставить только то что позволит сделать простой сайт, без почты, без капчи, без форм и т.д. только каркас! Вот вышел месяц назад php7, на нем можно запускать Yii2 — хорошо! Но когда он сам будет в полной мере пользоваться новинками, а не то что добавили в php 5.4? А если бы был только каркас, то может в альфе уже был бы каркас для php 7 и остальные пакеты бы подтягивались по возможности, как между laravel 4 и 5, как между расширениями yii1 и 2.
Повторюсь, что могу ошибаться. И соглашусь что над новичками надо жестко следить, что можно разбаловать, но такой подход больше для среднего образования, после уже каждый может забросить это дело, если будет тяжело для них.
По-моему новички должны сами за добавкой приходить, а не тыкать в них все подряд.
Mendel
0
Если использовать ту же кодовую базу, то нет смысла что-то урезать. Это уровень документации. Не описал фичу, и всё.
Где нельзя просто упустить — забутстрапили в дефолтной сборке простой пример, и можно не читать.

Вариант очень низкой связности, когда всё является внешним, всё просто может быть переписано, а должно быть использовано сторонними разработчиками это порочный путь. Равно как и бегство за свежими фичами. И дело даже не в том, что окружение (тот же хостинг) могут не поспевать за требованиями софта. Это еще полбеды. Обновимся, поменяем хостера, или запинаем поддержку. Не суть. Слишком частые обновления приводят к тому, что теряется совместимость даже у минорных версий. Сообщество не приходит к единому мнению и появляются как новые расширения для новых версий так и «со старым добрым АПИ»… Даже «медленное» развитие Юии ведет к тому, что большие проекты многие без критических обновлений не обновляют. Большая гибкость и скорость использования новых фишек имеет большой плюс когда у тебя небольшой парк проектов с коротким сроком жизни и/или частым переписыванием. А в перспективе вызывает дискомфорт.
AlexGx
+3
В одном проекте я был свидетелем того, что разработчики придерживались идеи MVC, делали тонкие контроллеры и жирные модели. В результате чего можно было наблюдать несколько моделей из 10 000 — 15 000 строк кода, которые были связанны чуть ли не с большей половиной всего проекта. Естественно настал момент, когда все крестились и просто боялись их трогать, зная что если что-то сломают может полететь весь проект. Это не критично на небольшом проекте, но если проект набирает популярность и разрастается, ждите беды.

С таким подходом независимо от фрейма и яп будет такой результат. Yii2 не навязывает вам арихитектуру, это фреймворк в первую очередь.
Если все модели наследуем от ActiveRecord, то на выходе по перспективе получаем так-же букет из проблем. Возможно будет такая ситуация, когда мы унаследуете frontend и backend модели от common моделей, которую в свою очередь от ActiveRecord. Но что будет если вдруг по мимо общей логики, нам потребуется разная логика в frontend и backend приложениях? Скорее всего начнутся перекрывания сценариев, событий таких как afterSave, beforeSave и много других интересных штук. С которыми я сталкивался почти везде.

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

ActiveForm, тут просто facepalm. Это не очень гибкая штука как и 90% виджетов Yii2, они рассчитаны на быструю разработку ну скажем прототипов или максимум админку. Но использовать эти виджеты в большом и сложном проекте не очень хорошая идея. Практически не реально воплощать в жизнь извращенные задачи клиентов. Еще как претензия, это то что разработчики Yii2 прилично смешали php код с js, это можно наблюдать в валидаторах. И на послед, это то что все поголовно зависит от jQuery. Не скажу, что это плохо, но есть еще такой замечательный framework как vanilla (если вы понимаете о чем я ;)).
Тот подход который навязывают виджеты действительно тяжеловесный, в большом и сложном проекте у вас скорее всего будут самописные (или переделанные) виджеты, тк все универсальное имеет много лишнего в угоду универсальности. JS часть виджетов нужно отключить на уровне ассетов и сгруппировать и упаковать grunt`ом например. ЭктивФорм надо уметь готовить, в процессе разработки у вас должно было появится понимаение какие и как формы используются, и уже имея понимание, нужно сделать свою обертку, благодаря которой у вас описание самыех сложных форм будет укладываться в несколько строк.
Расширения. Что касается расширений Yii2 (конечно-же от сторонних разработчиков), то 99% этих расширений решают только примитивные стандартные задачи. Если возникает суровая серьезная задача, то в 99% случаях Вам придется писать все самому.
Есть довольно качественные расширения, которые реализуют достаточно сложную функциональность, которую порой сам и за неделю не реализуешь, при этом они покрыты тестами, а разработчики активно общаются на гитхабе и принимают реквесты. Но есть и куча расширений-оберток над разными js либами и виджетами. Это есть в практически любом фреймворке. Для меня выбор расширения всегда начинается с просмотра кода, потом issues, и активности автора, лояльности на гитхабе.
Fesor
+2
Yii или там Laravel хорошие фреймворки для небольших и средних проектов, для прототипов или MVP. С ними можно добиться очень высокой скорости разработки. Но как только сложность проекта (и я не про инфраструктуру а именно про бизнес логику) увеличивается начинаются проблемы. Не потому что фреймворки в чем-то ограничивают, а как раз таки наоборот.

Новичкам нужен бандаж и строгость. Строгие стандарты, строгие практики, жесткий код ревью и т.д. Никаких «делай как удобно», «будь прагматичным» и тд. TDD и подобные практики очень хорошо подходят именно новичкам. Это уже потом, с опытом можно переключаться на инструменты которые дают больше свободы. И тогда процесс обучения станет намного проще.

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

Почему-то когда люди приходят в Ruby сообщество они начинают учить RoR, сразу же людей учат писать тесты, процессам разработки и т.д. В PHP же можно встретить людей которые за 5 лет ниразу не писали тестов.
nepster09
0
Вы наверно один из не многих, кто почти все понял, что я имел ввиду. Но еще не забывайте, что под словом «новичок», можно подрозумивать совершенно разные уровни знаний.

Например можно хорошо, знать php. Каждую функцию знать на память. Но при этом не слышать про паттерны, это новичок?
Или например можно знать php, работать с паттернами, но не разу не писать тесты, это новичок?
А можно знать php, знать паттерны, писать тесты, но не знать про DDD.

От сюда вопросы:
Что значит знать php?
и
Кто такой новичок?
Fesor
+1
Но при этом не слышать про паттерны, это новичок?


Паттерны это больше способ общения, а не средства проектирования. Напомню что в конце 90-х было много холиваров на тему должны ли программисты знать паттерны или это несет больше вреда чем пользы. А все потому что паттерны… они просто есть. Только ближе к 2000-ым появились хоть какие-то обоснования (SOLID, GRASP) из которых можно вывести все паттерны.

То есть тут занятная ситуация, перепутались причина и следствие. Знаете вы паттерны или нет — если вы будете соблюдать принципы SOLID и понимать зачем это надо и какие преимущества дает разделение ответственности и т.д. то они у вас всеравно получатся.

Так что я не считаю что знание паттернов это обязательно для новичков.

Или например можно знать php, работать с паттернами, но не разу не писать тесты, это новичок?


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

А можно знать php, знать паттерны, писать тесты, но не знать про DDD.


DDD — это способ управления сложностью. Сложностью именно бизнес логики. Как и BDD, основная соль тут — уменьшение стоимости перевода требований из языка стэкхолдеров в код. Способ устранения двусмысленности и т.д.

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

Основная соль DDD не в паттернах или там в том как вы проектируете архитектуру приложения, а в том что разработчики должны концентрировать внимание именно на потребностях бизнеса. Потому оно и называется domain-driven. Большинство же проектов имеют весьма простой домен, а значит DDD там не особо поможет. Есть проекты с дико сложной инфраструктурой и простой бизнес логикой.

Что значит знать php?


Знать PHP как средство решения проблем.

Кто такой новичок?


Человек с минимальным опытом. Вообще тут стоит прояснить что это даже не джуниор. То есть выполнять коммерческие проекты на этом уровне вообще нельзя. Даже за джуниорами нужен контроль.
nepster09
0
Тут еще момент в том, что «Человек с минимальным опытом» может быть в конкретной области. Например человек может спокойно писать на Yii2 делая 10 средних проектов в год при этом даже не догадываясь про существования таких понятий архитектуры, которые мы обсуждаем.

У меня знакомый уже лет 5 наверно сидит на codeigniter 1.xx версии, делает интернет магазины и не знает проблем. Я смотрел на его код, там от ооп только контроллеры и модели самого CI, остальное процедурный код по 5к — 10к строк кода. Тем не менее это ему не мешает выполнять заказы для клиентов и поддерживать их. Кое-ка они там работают.

Я бы опыт разделил на этапы. Да и понятие «джуниор» для каждой так сказать конторы будет свое.
Fesor
0
Ну и пусть себе кодит. Для некоторых программирование это просто способ заработка. Пришел, покодил, ушел домой. И развиваются эти люди только тогда когда за это платят.

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


А может оно и не надо? Ну вот серьезно. Зачем мы вообще придумываем всю эту чушь? DDD, BDD, гексагональные архитектуры, микросервисы и т.д.?

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

Я вот не так много проектов знаю где микросервисы нужны. И еще меньше проектов где нужны загоны по DDD. Они есть, их не мало, но это небольшая доля от рынка.

Те же интернет магазины — не так много владельцев магазина осознают что можно делать для повышения продаж и т.д. Покупают и здорово. А то что если бы мы практиковали какой event sourcing мы бы могли найти потенциальных покупателей больше и потом заспамить их предложениями какими-то и оптимизировать продажи — ну так это надо много думать. Зачем…
Mendel
–1
Он кодит, а потом проект растет и кому-то его приходится поддерживать и «чуть допилить». Может не надо?
Может сразу человеку объяснить? Не рассказать а объяснить.
Недавно собеседовал человека чтобы «белить и красить, штукатурить и еще немного вышивать» — партнеру нужен был человек который сможет поддерживать его проекты на вордпрессе, юии1, юии2 и т.п., но по мелочи.
Пообщались. Вроде нормально. Даже умные вещи говорит типа тонкий контроллер и т.п. Но слышу что не понимает.
Вычитал, но не понимает. Знает что так нужно.
Привел пару примеров из жизни, пару сферических. Дошло.
Вообще я часто сталкиваюсь с тем, что люди могут рассказать тебе как всё правильно, но ничерта не понимают.
SamDark
0
Если дошло, надо брать :)
Fesor
0
Вычитал, но не понимает. Знает что так нужно.


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

Ну или там инкапсуляция — вроде простая штука, но многие разработкики ее не понимают и не могут сказать «почему этот код нарушает инкапсуляцию».
SamDark
0
денормализовать?
Fesor
0
Нет, именно произвести нормализацию базы данных, привести все к пятой нормальной форме если хотите. Денормализовать — тут как бы даже делать ничего ненадо обычно.
Mendel
0
Например можно хорошо, знать php. Каждую функцию знать на память. Но при этом не слышать про паттерны, это новичок?
====
Да. Новичек. Худшая форма. Не знаю и знать не хочу всех функций пхп. Мало того — часть из них знать опасно. Тянет знаете ли на велосипеды. Есть гугл, справка языка, хелпы ИДЕ. Зачем? С паттернами не так однозначно. Паттерны знать надо, не обязательно от зубов чтобы названия отскакивали и т.п. но это намного важнее чем мелкие нюансы языка. Каждый раз когда встречаю тернарный оператор я лезу в гугл. Не хочу я себе голову забивать этим. Но это не делает меня новичком. А вот патологическая склонность к велосипедостроению — делает.
Если у человека класс на 15тыс строк кода, то не важно на каком языке или фреймворке он написан, и модель это или контроллер. Ему нужно повышать свою грамотность в архитектуре. Точка.
Нет, шаблонов это не касается, хотя тоже навивает. Нет, бывает когда дедлайн и ты в чужом коде. Но так чтобы сам…
Fesor
0
Нет, бывает когда дедлайн и ты в чужом коде. Но так чтобы сам…


Рекомендую почитать заметки Мартина Фаулера на тему Tradable Quality. А еще у него есть неплохая пародия на Роберта (Дядю боба) Мартина: youtu.be/B_KIAmFZJz0?t=29m50s
VolCh
0
Скорее всего основная проблема не в Yii как таковом, а именно в использовании ActiveRecord. Фаулер предупреждал, что годится он лишь для несложной логики домена и(или) базы и важно не пропустить момент, когда ActiveRecord усложняет разработку. Другое дело, что имеет ли смысл Yii без своей ActiveRecord?

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

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

Интересные публикации

Вакансии

Заказы