Собственный фреймворк vs существующих решений. Осторожно возможен HW

[AmdY]

Смысл писать с нуля, если можно просто форкнуть на гитхабе готовый проект и вырезать своё, делать пулреквесты в родителя, получать патчи для нетронутого функционала.
Времена, когда фреймворки жёстко навязывали использования только своих классов уже давно прошли и сейчас все популярные вещи модульные. Не хочешь использовать AR - пожалуйста, работай через PDO в ZF и Symfony(Doctrine) это делается без особых проблем и без особого оверхеда. Много запросов - не используйте роутинг. Это 2 вещи которые действительно СЕРЬЁЗНО влияют на производительность, больше припомнить не могу или есть ещё?

ну давай на вскидку, типичная аналитическая задача прогноза по собранным данным, минимальное количество записей 10.000, надо сделать выборку из бд, расчет и вывод вывод кастомный, страницы на выходе > 1м.б.

Каким образом здесь мешает фреймворк, кроме как НЕобязательное использование AR-ORM. Да и то, даже с ORM оно работает с достаточной скоростью на объёмах крупнейших компаний, а главное при этом любой менеджер может составить какой угодно отчёт сам через визарды.

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

p.s. Тему открыл, потому что она действительно в данный момент болезнена, ибо приходит понимание, что СОВРЕМЕННЫЕ фреймворки стали достаточно гибкими и функциональными, что узкоспециализированные решение уже не дают существенного выигрыша и велосипедостороение в области fw сейчас для души в нерабочее время.

 

[atv]

эффективнее разрабатывать свой фреймворк

Хочу уточнить, т.е. предлагается для каждого проекта, для каждой, вновь созданной, команды писать свой фрэймворк?

 

[varan]

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

 

[Absinthe]

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

 

[grigori]

Не хочешь использовать AR - пожалуйста, работай через PDO

в PDO нет асинхронных запросов и курсоров, на миллионных выборках работа без буферизации результата может сэкономить мегабайты памяти и много времени

 

[AmdY]

grigori
pdo для примера. фреймворк в этом плане не ограничивает никак, хоть mysql_connect, хоть handle socket, хоть mongo юзай в конкретном экшине, а можно и вовсе на java отчёт генерить, зато 80-90% остальных задач покроются ГОТОВЫМ фреймворком.

Собственно теперь и платят не за то, что ты умеешь готовым пользоваться, а за то, что умеешь встраивать своё в готовую структуру фреймворка-cms.

 

[Ирокез]

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

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

очевидные вещи, типа существующие решения лучше, потому-что их поддерживает сообщество (никому не интересны)

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

 

[Ирокез]

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

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

 

[atv]

я предполагал видеть мнения не опираясь на абстракцию, а конкретно мой фреймворк умеет (пример):

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

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

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

В любом случае, выбор между ГОТОВЫМ своим и готовым не своим фрэймворком сводится к такому же сравнению как выбор между другими существующими фрэймворками. И те же требования к существующим фрэймворкам нужно предъявлять и к своему, такие как наличие документации, возможность поддержки и развития после ухода члена команды и др. Так что однозначного ответа на вопрос что лучше, свой или существующий, нет, всё зависит от конкретной задачи и конкретной команды.

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

 

[Ирокез]

atv вас не смутило примечание, (пример)?
я поздравляю вас что у вас хватает терпения разбирать гкод чужих фремворков. а по теме есть что? (не очевидное)

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

 

[AmdY]

- нет достаточно быстрой реакции на мелкие баги, недочеты

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

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

опять же, сейчас этой проблемы практически нет, благодаря git-mercurial + githum-bitbucket

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

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

 

[c0dex]

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

Так что выдохни и расслабься

 

[Absinthe]

- нет достаточно быстрой реакции на мелкие баги, недочеты

В готовом фреймворке оно есть, но медленное. В своем личном - полностью нулевое(никакое комьюнити его править не будет точно). Так что и тут готовое лучше.

зачастую не возможность перенести часть функционала в модуль php

Что невозможно перенести? Все можно кроме архитектурных решений: и роутинги, и кэширование, и базу и т.д.

 

[AmdY]

c0dex
у меня есть несколько версий своего фреймворка с разными подходами и все они быстрее zf, но толку?
после выхода ZF 1.0 я увидел что там нет доброй части того что мне нужно от фреймворка и написал свой, но год назад опробовав новую версию ZF с удивлением обнаружил что практически всё что я писал для себя уже есть в ZF, да ещё красивее и гибче, пускай при этом чуть медленнее.

p.s. как ниже отписался atv, мне не повезло и фреймворк писался не в рабочее время, а в моё личное.

 

[atv]

atv вас не смутило примечание, (пример)?

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

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

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

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

 

[grigori]

grigori
pdo для примера. фреймворк в этом плане не ограничивает никак

это как сказать, иногда есть драйвера только для одного вида соединений, а два экстеншена для одного проекта - плоховато тем, что у тебя буде 2 соединения на страницу,

Ирокез я лишь рассказал о традиции, которую ты просто не знал, не принимай все так лично

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

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

- зачастую не возможность перенести часть функционала в модуль php
кроме тебя это делают только баду и фейсбук

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

- мы говорим о сложном приложении
критерий сложности в студию!

 

[grigori]

Ирокез
Это специфика этого места. Все дохрена умные и дальше своего носа не видят и не готовы мириться с тем, что у кого-то "велосипед" работает быстрее коханы/зф/йии

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

 

[Ирокез]

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

Так что выдохни и расслабься

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

AmdY, Absinthe при все моем глубочайшем уважении, задача не писать и не поддерживать фреймворк (да хрен с ним, 10-ть процедур, раз пошла такая пьянка), а выполнять задачи которые стоят в рамках разработки сложного проекта, делать патчи и комитить, это значит тратить время на не связанные с проектом задачи (запишите в тасклист заказчику, я 2 дня тратил на патч и коммит чужого фрймворка [grigori] извини за красивую фразу, но реально как мне обосновать это? )

гибкость, в сложном проекте, это беда. извините за оффтоп: в году 2000-м, работал над одним проектом, на выходе был исполняемый файл ~100 мег. я как молодой и считавший себя опытным пришел и говорю, давайте, сделаем классы, введем наследование, вместо функций (получится очень гибко и красиво), что надо перегрузил, написал свой код, мудрый человек мне ответил, товарищ дорогой, время компиляции проекта составляет часов 8-мь (и это для того чтобы, в дебагере проверить правильность кода), говонокодеров, которые переопределят метод и внесут сове ноухау хватает, так-что пусть остается все как есть (прав он был или нет, ну решите сами)

 

[Ирокез]

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

я не понимаю (ввиду ограниченности ума), какую конкретику надо в студию?

Ирокез я лишь рассказал о традиции, которую ты просто не знал, не принимай все так лично

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

 

[grigori]

я не понимаю (ввиду ограниченности ума), какую конкретику надо в студию?

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

(запишите в тасклист заказчику, я 2 дня тратил на патч и коммит чужого фрймворка [grigori] извини за красивую фразу, но реально как мне обосновать это?

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