Зачем мне нужен популярный фреймворк?

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

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

Одна вещь, которую вы упустите, - это всю валидацию, которая входит в популярный фреймворк.

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

У фреймворков есть несколько преимуществ:

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

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

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

Обновлено:

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

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

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

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

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

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

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

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

И любое сэкономленное время - это хорошо. Лень в программировании окупается.

Я согласен, что вам следует использовать свой собственный фреймворк. Это не только упрощает понимание, но и обеспечивает максимальную безопасность работы!

Я могу сразу вспомнить три причины:

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

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

Как вы, наверное, знаете: «время - деньги». Таким образом, используя популярный фреймворк с множеством помощников, множеством примеров кода в сети и большим сообществом, вы делаете больше за меньшее время.

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

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

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

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

Причина, по которой я использую фреймворк, например Django для python или Rails для Ruby или Webforms и MVC для ASP.net, заключается в том, что они упрощают и ускоряют написание приложений для них. В случае с Ruby и Python, если я не использую для меня фреймворк, я сойду с ума.

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

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

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

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

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

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

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

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

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

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

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

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

ТЕМ НЕ МЕНИЕ

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

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

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

Вот еще одна причина, по которой нет создает свой собственный фреймворк. Закон Линуса - «Если внимательно присмотреться, все ошибки мелкие». Другими словами, чем больше людей использует данный фреймворк, тем более надежным и свободным от ошибок он может быть.

Вы видели, сколько существует веб-фреймворков для Java? Раньше для любого полуприличного разработчика / архитектора было модно писать свой собственный веб-фреймворк. В конце концов, 95% из них выглядели как пользовательская реализация Struts (самого популярного веб-фреймворка Java в то время). По сути, они создали клон Struts, который: 1) был проприетарным; и 2) недостаточно хорошо документированы и протестированы.

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

Я забыл, кто это сказал, но однажды я услышал отличную цитату: «Первое правило создания собственного фреймворка: не надо». Кто-то другой, вероятно, приложил усилия для этого и, вероятно, проделал ту же работу, что и вы. Сэкономьте время, силы и испытания.

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

Сможете ли вы решить проблемы, которые возникают в вашем коде, быстрее и надежнее, чем общедоступные фреймворки?

Если да, то продолжайте использовать свой собственный.

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

Все сводится к тому, какая кодовая база выполняет работу лучше (в зависимости от значения, которое дает клиент;))

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

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

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

Недостатки.

Большинство рамных работ не ориентированы на объект. (воспламенитель кода показывает некоторые обещания)

Большая часть кода выполняется с помощью include. пытаться отследить проблему - все равно что натягивать нитку на свитере и распутывать всю одежду, чтобы полностью понять творение.

Большинство фреймворков имеют плохо написанную документацию.

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

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

Многие работы php Frame были написаны для php 4 и написаны в другой среде. Они значительно расширились, но показывают свое происхождение. Особенно распространено использование глобальных ограничений. Я надеюсь, что php 6 убьет большинство из них. Воспламенитель кода избегает большей части этого, но он новый и имеет объектно-ориентированные части.

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

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

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

дайте мне хорошо написанный объект в любое время. По крайней мере, их вы знаете сразу с места в карьер.