Эффект второго фреймворка
3 января 2016
Время от времени я натыкаюсь на обсуждения фреймворков и рассказы, какой плохой фреймворк X. Проблема почти всегда сводится к тому, что проект получился немного более крупным, чем планировали, и со временем превратится в один слипшийся, пованивающий и нестабильный кусок.
Проект, естественно, рано или поздно заваливается. На чём программист базирует свой следующий проект? Правильно. На чём угодно, лишь бы не на X.
Человеку свойственно винить что и кого угодно, лишь бы не себя. Это фреймворк виноват, а не я. Это фреймворк не решил вопросы архитектуры моего приложения. Это фреймворк сделал меня ленивым. Это из за фреймворка я не писал тесты. Это фреймворк не подготовил моё приложение к работе на десяти серверах. Это всё он.
Обвинив во всём фреймворк X, программист выбирает Y. В этот раз всё идёт лучше. Но не потому, что фреймворк настолько хорош и решил за разработчика вопросы архитектуры, а потому что разработчик достаточно умён, чтобы не наступать второй раз на те же грабли.
Комментарии RSS по email OK
Это по поводу поста на хабре? А что можно сказать по поводу коммента Zelenin , что Yii2 многое позволяет делать неправильно. И что хороших расширений нет, потому что при получении определенного опыта разработчики покидают сообщество - уходя разрабатывать на другом FW
Zelenin сам написал много расширений - и активно помогает на форуме - его мнение, по-моему, объективно.
Да, тот пост не о чём. Но, всё же в комментарии Zelenin есть здравый смысл.
Посмотрите посты на хабре по php - количество материалов по symfony, laravel и yii 2, последний всегда проигрывает.
Yii хороший взрослый фреймворк для пряморукого программиста, тут стоит признать, что в команду надо добавлять маркетологов и пиарщиков, которые бы продвигали это дело.
Большинство "псевдопрограммистов" делают свои оценки в стиле "у ларавела туториалы лучше, значит сам фреймворк хороший".
Люди по своей природе необьективны. Статья ни о чем, или все вдруг забыли сколько крутых проектов уже написано и какие компании используют его для написания новых?
Пост на хабре читал. Полностью согласен с мнением Александра. Все что там написано - это не проблемы фреймворка, а разработчика.
У автора статьи после 3+ лет разработки на Yii ВНЕЗАПНО стало все лучше получаться на Symfony. Начал бы 3 года назад на Symfony эти проекты делать, результат не сильно бы отличался.
Статью можно было назвать просто "Разработка приложений без опыта — прямой путь в АД". Зачем туда было вмешивать Yii - не понимаю.
porcelanosa, сподвиг меня да, пост на хабре. Но вообще я заметил это ещё когда Yii 1.1 только выпустили. Народ переходил с CodeIgniter. В случае CodeIgniter можно было бы найти кучу объективных причин перехода, но причины были всё те же, что и в посте.
Yii да, даёт свободу, так что игнорировать паттерны и принципы возможно. Опытным разработчиком это иногда позволяет безболезненно срезать углы. Для не совсем опытных может быть нехорошо.
Про расширения, опять же, не согласен, да и Zelenin поправился в том же посте. Качество большинства неофициальных расширений для какого угодно популярного фреймворка оставляет желать лучшего. Просто потому что их много.
Что опытные разработчики покидают сообщество не согласен. Миграция есть как в одну сторону, так и в другую. Опыт тоже варьируется. Массового оттока я пока не заметил.
archil, похоже, надо напоминать :)
У меня такое ощущение, что пост все прочитали как-то выборочно и выдрали смысл из контекста.
Я даже специально жирным помечал:
"Данная статья не в коем случае не утверждает, что Yii2 плохой инструмент. Скорее статья предупреждает, что разрабатывая на Yii2 нужно быть предельно аккуратным и продумывать каждый шаг ..."
**"— Действительно ли это утверждение, которое пишут разработчики на русскоязычном сайте Yii2 правдиво? — Действительно ли на Yii2 можно написать проект любой сложности?
На эти вопросы ответ однозначно Да ..."**
Я не знаю, где кто работает и какой код пишет, но всегда куда попадал я, где был Yii, там был такой стремный код, что можно было хоронить ни один проект.
Статьей, я только хотел привлечь внимание людей, которые лепят не пойми что в модели и контроллеры и мотивировать стараться писать качественный код.
Но по какой-то причине эффект пошел совершенно не в ту сторону. При сравнении Yii2 с Symfony, я даже напомнил, что «Yii2, это другая ниша».
Очень жаль, что даже Александр Макаров (особенно жаль), совсем не понял, что я имел ввиду.
Если сравнивая меня например, почти со всеми, кого я видел, я всегда старался узнать свои косяки и совершенствоваться, однако большинство разработчиков живут по принципу: "Это работает, зачем делать по другому?"
Что касается симфони, когда ты начинаешь писать на нем, тебя сразу же ставят в жесткие рамки и открывают глаза на: - сервисы - сущности - репозитории - DI - шаблонизаторы и тп.
Я полностью согласен, что можно наговнокодить на всем что угодно, но речь была совсем не об этом. А именно о архитектуре.
Nepster, без обид, но после прочтения комментариев по-видимому вас никто не понял (по крайней мере вы так написали, что здесь что на хабре), за исключением пары людей, может тут дело в самой статье, может стоит переписать ее, чтоб народ наконец-то понял.
Archil, может быть. Но сделайте пожалуйста скидку, на то что можно сказать первая статья на хабре.
Nepster, просто в статье проблемы:
_"Заголовок совсем жёлтый и не соответствует действительности." Объясните подробнее пожалуйста. _
"Несмотря на примечание, статья пытается показать превосходство одного фреймворка над другим намекая на то, что на Yii 2 проект точно завалится... "
Из какого контекста вы это вырвали ?
Статья описывает субъективный опыт. Объективно вывод я там в одном из комментариев переписал и ложным он от этого не стал. Это может оказаться как правдой так и не правдой. В каждом сообществе есть свои разработчики самого разного опыта, которые будут защищать свой инструмент. Это холиварное утверждение.
Я вел к тому, что по сравнению с уии2 симфони сразу открывает больше всяких разных понятий. Уии2 достаточно сильно упростили, причем не с точки зрения функционала.
И "Эффект второго фреймворка" слишком абстрактно. Программируя на любом инструменте, можно перейти на другой так-же любой и при этом не повторять ошибок предыдущего. Но так-же можно перейти в другой проект на том-же инструменте и не повторять ошибок предыдущего проекта.
Вы не много все перекрутили =(.
Я имел ввиду почему нужно начинать с симфони, потому-что сразу разработчик понимает, что такое DI, сущности, сервисы и тп. А потом принимает решение, нужно ему это или нет и переходит например на Yii2. Где есть все тоже самое, но без чего спокойно можно обойтись.
Заголовок из серии «наши открывашки не радиоактивны». Вроде всё так, но факт, что подавляющее большинство открывашек не радиоактивны, намеренно оставлен за кулисами.
Так и про фреймворки. Да, без опыта на Yii можно завалить проект. Подвох в том, что без опыта можно завалить проект на чём угодно.
Скорее всего, так вышло не специально. Я больше про то, как это воспринимается.
В основном, из выводов, совета «не начинать свое обучение на Yii2» и сравнения с велосипедом и автомобилем.
К сожалению, это не так. Я пришёл в PHP из J2EE, где был Spring, паттерны во всей красе, DI и всё-всё-всё. Понятий вводилась сходу целая туча, работали с этим, худо-бедно, все, но понимали максимум пара человек на проект с командой из 15-и разработчиков. Остальные, будучи оставленными без IDE, работать не могли вообще.
Sam ОК - я пишу на php изредка хоть и давно. Пробовала проекты на Yii1 - очень-очень простые.
Как мне начиная проект на Yii2 не ошибиться? Про паттерны программирования читала всем известную книжку от банды четырех. Но опыта ноль, по большому счёту. Nepster уверяет, что на Symfony меня "заставят" писать правильно. А на Yii 2 даже официальные boilerplates - basic and advanced уже содержат просчеты в архитектуре.
Честно скажу, что попробовав advanced шаблон схватилась за голову - мне ну вот вовсе не нужно такое. Basic более человечен и вынос админки в модуль, вроде бы решил задачи. Но теперь я сомневаюсь... Не столкнусь ли в будущем с проблемами. Может стоит расширить номенклатуру готовых шаблонов от разработчиков?
porcelanosa, если добавить ещё пару шаблонов, новички будут выбирать, а не писать что-то полезное.
Шаблоны не могут содержать просчёты в архитектуре потому что они вообще не дают никакой архитектуры. Ни один фреймворк вам не даст готовой архитектуры. Это ваша задача как программиста.
Если advanced сложен, с Symfony будет совсем нехорошо. Там порог входа повыше.
Sam, Александр, попробуйте ради интереса взять заказ, что-то вроде "допилить проект на Yii2". И вы поймете, на сколько Yii2 сложный =).
Nepster, допил брал много раз. Code review тоже. С допилом да, проекты попадаются чаще плохо написанные, чем нормально. С code review всё гораздо лучше. Всё дело в том, что нормальный код, как правило, не пишется один раз сдать и всё. За ним следят.
Добавлю свои 5 копеек, yii ничем не лучше и не хуже zend, symfony , laravel и т.д. Писать хороший код можно на чем угодно, хоть на чистом php. Проработав архитектором последние несколько лет, я столько "заваленных" проектов повидал и улучшил, что могу сказать что это скорее зависит от опыта программиста и любой проект можно исправить. На любом фреймворке. И да, обучение я советую начать именно с yii2, так как у него порог вхождение ниже. А попутно прочесть хотя бы книгу по рефакторингу от Мартина Фаулера. Тогда вы сможете писать более менее хороший код. Если хочется больше, то тогда придется учить шаблоны проектирования, хотя это и может сделать ваш код хуже, при неумелом использовании.
Превратить в помойку, говнокод и завалить можно что угодно на чём угодно.
Мы ж как заваливаем? Нам дают задачу, мы в голове придумываем модель реализации. В лучшем случае модель 100% ложится на задачу. В худшем - выбирается часть, которая хорошо ложится, чтобы сделать MVP. Затем добавляется слой реализации для другой части задачи. Если программист опытный, если он уже занимался задачами аналогичной сложности, то первая реализация будет содержать точки роста, позволяющие добавить ещё чуть-чуть логики. Иначе она начинает приклеиваться на сопли и подпираться костылями.
Далее проект может начать развиваться в направлении, не укладывающемся в исходную модель стадии MVP. Тут нужен рефакторинг, переписывание и миграции, но времени не дают. Остаются неспользуемые куски кода, чудовищные абстрации "обо всём", жуткие модели данных.
На некоторой стадии исходная MVP покрывается слоем костылей. Бывает ещё, архитектор сбегает, зараза, делать новый проект в новой компании, оставляя старый гнить. Ещё бывают проекты без архитектора. Печальная участь таких проектов - они могут не пережить MVP.
Следующий проект с нуля будет писаться с учётом роста. Выбор инструмента не важен. Важно то, что творится в голове архитектора. Насколько хорошо он умеет строить модели и перестраивать их под нужды новых задач. Чтобы такое уметь делать хорошо, надо несколько раз сделать нехорошо.
В этом отлично помогают Pet Projects - домашние проекты, на которых программисты учатся делать ошибки. Они по факту, эти проекты не нужны работодателю, но факт завершённого домашнего проекта говорит, что у программиста уже есть несколько зашивших шишек от грабель.
Кстати, на моей практике действительно была компания, в которой в одной комнате к стене был прислонен пружинный матрас от двуспальной кровати. Можно было подолбиться головой. Иногда помогало утрясти мысли или выпустить пар :)
Просто по-умолчанию для новичков YII поощряет повсеместное использование паттерна, который у Фаулера называется Transaction Script. Я тоже на это напоролся в своё время, НО зато благодаря простоте YII я вполне мог делать работающие сайты, а когда накопились вопросы КАК сделать лучше я прочитал пару книг по ООП в том числе по шаблонам и продолжил свой путь вместе с YII, но уже с новыми навыками. Я даже не мог подумать, что проблема в YII, я прекрасно понимал, что просто надо закрыть кое-какие пробелы в знаниях.
"Огромное преимущество данного шаблона - это скорость, с которой вы получаете результат." И пусть кто-нибудь ещё попробует доказать, что это анти-паттерн. А плохому танцору известно что мешает, но точно не прекрасный фреймворк YII.
А ещё в экстремальном программировании один из принципов "сделайте самый простой работающий вариант". А дальше уже "пилите Шура... пилите... " рефакторинг... композиция, делегирование, композиция, делегирование... хоть до бесконечности.
Проблема "толстых моделей". Yii действительно немного провоцирует их появление. Как и многие другие фреймворки. Как и сам паттерн ActiveRecord. Ответственность за это, конечно же на разработчике конкретного приложения, а не на фреймворке.
Есть ли какие-то статьи с примерами как правильно спроектировать слои приложения Yii не отказываясь от ActiveRecord? То есть не делая как здесь yiiframework.ru/doc/cookbook/ru/model.dao
У меня в крупных проектах, каждая модель дополняется компонентом с таким-же именем, в котором основная логика, а в модели содержится только код необходимый для целостного сохранения данных в БД. По валидации, в модели находятся только несколько простых правил для админки, только чтобы сохранение ошибки SQL не выдавало, если что-то заполнено не так. Формы пользовательской части вынесены отдельно, в них уже детальная проверка формата данных + доп. проверка из модели тоже есть, т.е. двойная валидация двумя классами.
Ещё удобно делать как в Doctrine, держать код модели в двух файлах (напр. Post и PostBase), которые наследуются один от другого. В одном конфигурация - связи, атрибуты, поведения, etc.., а в другом все остальное. Так у меня на одну сущность 3 файла получается.
denis909 Спасибо за подробный ответ. Пойду смотреть Doctrine. Тем не менее проблема существует, если не проблема фреймворка как готового кода, то фреймворка как продукта в целом. Неплохо было бы если Sam осветил этот вопрос в будущем.
Александр, в черновиках есть. Надо довести до ума и опубликовать.
В этом плане в Doctrine нет ничего особенного, применительно к ситуации c Yii, в PostBase мы держим конфигурацию AR - attributeLabels, relations, behaviors, rules, в Post события beforeValidate, beforeSave, scopes, т.е. все остальное что из модели не вынести, уже не конфигурация а реализация... а в PostComponent всякая логика, типа вспомогательных функций, то что можно вынести из модели без потерь.
Делал проект на Yii2. Спасибо разработчикам движка! Несмотря на то что я нихрена не понимал в архитектуре и тд я смог сделать рабочий проект. По ходу мне помогал программист который говорил что я делаю не правильно это или то... и тд но мне было сложно понять его доводы. Потом я подписался на курсы от ElisDN и в итоге понял кучу своих ошибок. Переписал проект заново на Yii2 по ElisDN. И мой товарищ программист который помогал мне помог еще более улучшить код. получилась конфетка... Теперь допиливать проект и расширять его одно удовольствие! Те кто гонят на Yii это просто либо конкуренты, либо идиоты.
PS: Использую шаблон basic убежден что он лучше чем advanced для 95 процентов приложений. По поводу того что Yii позволяет разрабатывать проект без сервисного слоя это да... Для новичка это конечно неправильный ход. Поэтому просто нужно бы добавить туториалов по сервисному слою и это решило бы проблему новичков.