Frameworks. frameworks, frameworks(+)

[Sherman]

Frameworks. frameworks, frameworks(+)

Множество копий было сломано, множество кода было написано, отрефакторнено и оттестировано

И все же, мало кто задумывался(или я пропустил), почему же навороченные фреймворки на php не пользуются популярностью.

Причин тут несолько. Но мне бы хотелось остановиться на нескольких из них.

Одной из причин непопулярности фрейворка является отсутсвие срдеств автоматизации создания приложений на оном.

Откроем любой мануал(если он вообще есть) и посмотрим что же там есть. А там в лучшем случае описано простенькое приложение типа «новости». И когда смотришь на то кол-во документации, которое придеться изучить, а это и синтаксис шаблонов, и лазанье по бесконечным директориям с исходным кодом, создание(в ручную!) необходимого «каркаса»(у некоторых такой каркас просто чудовищен по объему написания и отладки исходного кода приложения) и т.д. и т.п. всякое желание разбираться с этим пропадает. К тому же учитываем, что все это поставляется ввиде as is, и неизвестно будут ли работать ваши приложения на этом фреймворке завтра...

В чем сила .NET Framework.

Имхо, там нет ничего принципиально нереализуемого на php(я не имею ввиду разницу в самом подходе к работе приложений, т.е. я не говорю о clr ит.д., о гигантском кол-ве человекочасов на разработку), я говорю о том, что помимо самого framework-а, существует огромная инфраструктура поддежрки девелоперов, которые пользуеются данным продуктом. Огромное кол-во книг, сайтов, статей, примеров, даже видео(!). Это первый важный аспект.

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

Возможно это болезнь open source вообще.

p.s. писал в основном по php-ным системам, в том же ruby(который на рельсах) есть кое-какие средства для автоматизации разработки.

p.p.s. Тем не менее, хочу выразить признательность всем разработчикам(особенно российским) за их системы, без них было бы много хуже

 

[Фантазер]

Может быть тут дело в другом? Фреймворк, это как рубашка, которая ближе к телу. Это то в чем разработчик может что-то менять, рефакторить, использовать. Поэтому фреймоврк у каждого свой. Опять же правильно смотреть что делается у соседа -- можно взять идеи и реализации -- это как раз плюс опенсорца.

А вот как раз компоенеты, - то куда разработчик скорее всего не полезет -- очень даже можно брать готовые - форум, adodb,phpmailer, zip-gzip из phpmyadmin.

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

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

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

 

[HEm]

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

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

Ага, скрещивай ежа с ужом, пока скрестишь - у них уже три раза апдейт выйдет и нужно будет скрещивать заново

 

[Фантазер]

HEm
Ну слово должен оно хорошее -- кто кому должен?

К сожалению уровень билиотек, который является ближайшим к тому, коду, что вы пишите -- так или иначе будет самописным -- вон в интерфейсах программ -- все серьезные программы так или иначе имеют свой набор работы с win32 API, не смотря на то, что есть дельфи или си++ билдер или MFC. Про 3d движки я уже говорил.

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

Если Вы посмотрели на чужой фрем ворк и реализовали у себя ORM на основе чужого решения -- почему вас должен заботить апдейт? Теперь это ваш класс -- часть вашего фреймворка Я это имел в виду.

 

[atv]

Возможно это болезнь open source вообще.

Вот именно. Чтобы сделать всё то о чём Вы говорили нужны тысячи человекочасов, а где их взять? Ведь это опен сорс, кто за него заплатит?

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

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

Присоединяйтесь к какому нибудь проэкту и ситуация измениться. А подходить к опен сорс только как пользователь
проще простого.

 

[Фантазер]

Мифический человеко-месяц заплатил деньги -- получил результат. Очень часто это таки миф. Сколько было в разных облатсях универсальных больших (с тусячами человекочасов) разработок. И что-то не очень помнится зверской популярности. Разве что только дельфи. Но там ниша другая -- там основная часть разработчиков не пишет win32 API. А те, кто пишет -- скорее всего исключения из правила.

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

2. Абстрактно разрабатывать фреймворк нельзя -- легко можно не угадать куда надо двигаться. Остается путь работать над фреймворком в рамках коммерческих проектов. Ну и тут сразу упс -- готов ли тот или иной фреймворк помочь мне сейчас? Этот ответ часто отрицательный, потому, что есть свои библиотеки и потому, что проект заточен под другую задачу.

Заметь-те насколько лучше дело с готовыми компонентами -- там, куда не надо лазить руками -- форумы, adodb, pear-классы -- потому, что они не влияют на архитектуру приложения в целом.

Нет больших фреймворков с хорошей документацией? Ошибаетесь. Typo3, Ez -- там все есть. Ах -- они большие --
вот-вот -- начинается каприз

 

[_RVK_]

Sherman

Одной из причин непопулярности фрейворка является отсутсвие срдеств автоматизации создания приложений на оном.

ENVOS?

 

[Фантазер]

Кстати у меня вот крутится в голове идея -- не думаю, что можно сделать фреймворк, который народ побежит использовать, в силу причин, что я написал выше. А вот взять часть фреймворка, описать api, написать тесты и предложить -- "Пишете свой фремворк? А у меня для вас есть готовый MVC набор с MIT или GPL лицензией и тестами". Также и набор Active Record-Table Gateway-ORM, А еще у меня есть декоратор для рисования формы на основе гибкого интерфейса к контейнеру объекта. Кстати можно будет замерить популярность скачиваний наборов и тогда можно будет особо популярные объединять в пакет.

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

-~{}~ 15.02.06 11:27:

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

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

 

[_RVK_]

это то, что они связывают разработчика в возможности рефакторинга своего приложения

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

 

[Фантазер]

Автор оригинала: _RVK_
В каком месте связывает? Framework он на то и faramework что бы предоставлять лишь некоторые правила и базовые классы, обеспечивая гибкость остальной части системы. Опять же, если вы видете например возможность выделения метода, выделете его, и пришлите код автору. Думаю, если код от этого действительно стал лучше, в новой версии ваш рефакторинг будет учтен.

Я вижу это в комплексе классов. Если вы даете MVC набор отдельно и независимо, то ограничения накладываемые на разработчика меньше, чем если Вы даете ему целиком комплект да и внедрить проще.

Также и с Active Record.

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

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

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

 

[whirlwind]

При разработке фреймворка (ФВ) надо учитывать возможности, а не требования. Отдельные элементы ФВ должны как можно меньше пересекаться друг с другом. Грубо говоря, имеем два набора классов в двух папочках: ORM и MVC. Есть классы и для спаивания двух этих частей, они по логике вещей как и положено реализуют M в MVC, но эта связка не является обязательной. Проблема ФВ в том, что разработчик пытается однозначно описать протокол решения задачи с применением ФВ, забывая о том, что ФВ - это инструмент, для решения задачи, а не технология. А вот CMS - это уже технология. ИМХО.

 

[Фантазер]

Автор оригинала: whirlwind
Грубо говоря, имеем два набора классов в двух папочках: ORM и MVC. Есть классы и для спаивания двух этих частей, они по логике вещей как и положено реализуют M в MVC, но эта связка не является обязательной.

Именно это я и хотел сказать. При этом каждый такой маленький набор хорошо документирован, имеет тесты и UML диаграмму.

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

 

[atv]

Сколько было в разных облатсях универсальных больших (с тусячами человекочасов) разработок. И что-то не очень помнится зверской популярности.

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

Заметь-те насколько лучше дело с готовыми компонентами -- там, куда не надо лазить руками -- форумы, adodb, pear-классы -- потому, что они не влияют на архитектуру приложения в целом.

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

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

 

[Sherman]

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

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

 

[[sid]]

Один из немногих топиков на phpclub, который просто было не противно читать. Никакого флейма и прочего.

Что касается CMF... Интерестные идеи были высказаны, но я хотел бы еще кое-что добавить. Во-первых не совсем корректно сравнивать .NET Framework и frameworkи для разработки интернет-приложений. .NET это general purpose каркас, он не заточен под решение каких-либо конкретных задач. Другую ситуацию мы имеем в случае с нашими CMF. Это каркасы заточенные под разработку интернет-приложений. Это значит что в нагрузку к general purpose составляющей мы должны спроектировать и реализовать web-составляющую (мезанизмы обработки запроса, валидации etc). При такой направленности большинство framewrokов страдают допущениями в архитектуре. Ведь одна из основных задач (и наверное минусов, как было указано выше) это принятие за программиста граммотных архитектурных решений. Именно от качества этих решений и зависит реюзабельность кода и возможнсоти frameworkа к расширению функциональности. Я лично не так много видел cmf с хорошей выраженной архитектурой (LIMB, mojavi, php.MVC). Очень большое количество проектов очень плохо приспособлены к изменениям (например, тот же неповортливый гигант Symphony). Ну и конечно же документация... Документация CMF это ее жизнь. Как я уже неоднократно говорил, CMF с плохой документациеей через некоторое время перестает терять смысл даже для ее разработчика.

 

[Фантазер]

Автор оригинала: [sid]
При такой направленности большинство framewrokов страдают допущениями в архитектуре. Ведь одна из основных задач (и наверное минусов, как было указано выше) это принятие за программиста граммотных архитектурных решений. Именно от качества этих решений и зависит реюзабельность кода и возможнсоти frameworkа к расширению функциональности. Я лично не так много видел cmf с хорошей выраженной архитектурой (LIMB, mojavi, php.MVC).

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

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

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

Автор оригинала: [sid]
Очень большое количество проектов очень плохо приспособлены к изменениям (например, тот же неповортливый гигант Symphony). Ну и конечно же документация... Документация CMF это ее жизнь. Как я уже неоднократно говорил, CMF с плохой документациеей через некоторое время перестает терять смысл даже для ее разработчика.

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

 

[[sid]]

Ну уж тогда WACT еще добавьте

Когда я говорю LIMB, я подсознательно имею ввиду WACT по понятным причинам

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

Абсолютно согласен. Переоценить оба типа документации невозможно.

Но часто документация -- не самое узкое место в освоении продукта

Хм... Честно говоря, я не видел ни одно удачного frameworkа с плохой документацией.

 

[Фантазер]

Автор оригинала: atv
Я имел ввиду что отсутствие человеко-ресурсов на проэкт отрицательно сказывается на его популярности, но не наоборот, что достаточность ресурсов гарантирует популярность.

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

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

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

Плюс мои рассуждения были и в каком-то смысле маркетинговыми. Одно дело во фреймворке компоненты могут быть независимыми, другое дело когда это преподносится, как желаемое применение. Т.е. автор явно говорит -- я разрабатывал эти куски, чтобы вы могли использовать их в своем проекте по отдельности -- но есть и возможности использовать их вместе (вот смотрите сюда на примеры). Когда потребитель это читает он смотрит на это совсем по-другому, нежели на "в общем-то из этого фреймворка можно выдрать ORM классы, малость допилить и использовать".

-~{}~ 16.02.06 10:34:

Автор оригинала: [sid]
Хм... Честно говоря, я не видел ни одно удачного frameworkа с плохой документацией.

На мой взгляд у WACT документация обрывочная, хотя и крайне полезная для чтения.

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

 

[[sid]]

Хотя добавлю, что есть и с хорошей документацией, но все равно тяжелы для внедрения -- поскольку либо надо учиться (например паттернам) илбо надо все перекраивать под этот фреймворк (типо3 и ez).

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

А что касается сложности систем, тут я позволю себе процитировать одного, на мой взгляд, очень опытного человека: "Увы, но сложность, о которой мы говорим, по-видимому, присуща всем большим программных системам. Говоря "присуща", мы имеем в виду, что эта сложность здесь неизбежна: с ней можно справиться, но избавиться от нее нельзя." ("Проектирование Объектно-Ориентированных Систем" - Г. Буч).

 

[Фантазер]

sid,

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

-~{}~ 16.02.06 11:34:

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