Я уже много лет являюсь разработчиком PHP, с множеством инструментов под моим поясом; инструменты, которые я либо разработал самостоятельно, либо бесплатные решения, которым я научился доверять.
Недавно я просмотрел CodeIgniter и обнаружил, что у них есть много классов и вспомогательных подпрограмм, которые помогают в разработке, но ничего не видели в примерах, которые я не мог сделать так же легко с помощью моих собственных инструментов. Простые вещи, такие как абстракции БД, помощники электронной почты и т. Д. Был некоторый интересный код, относящийся к маршрутам – отображение URL-адресов в правильные контроллеры; но даже это не особенно сложно закодировать, если вы когда-либо писали веб-приложение в стиле MVC с симпатичными URL-адресами.
Даже просматривая некоторые из других популярных фреймворков, я до сих пор не вижу ничего такого, что было бы большей частью экономии времени. Даже глядя на форумы, я вижу, что люди изо всех сил пытаются заставить инструменты работать на них. Я понимаю, как они будут более полезны для младших разработчиков, так как полные навыки проектирования системы требуют времени, чтобы понять и оценить полностью.
Тем не менее, мне часто говорят, что я должен использовать готовые рамки для создания своих решений, но я по-прежнему не убежден. Какая реальная польза для такого человека, как я? Я просто элит, или это общее мнение?
Редактирование. Рассматривая некоторые из ответов здесь, должен ли я подумать о том, чтобы упаковать свой набор инструментов в качестве своей собственной структуры, написав документацию и разместив учебники? Если я не решаюсь взять на себя другие рамки, открою ли я его и посмотрю дальше, это поможет улучшить мои собственные навыки / инструменты?
У рамок есть несколько преимуществ:
Вам не нужно писать все. В вашем случае это меньше помогает, потому что у вас есть собственные рамки, которые вы накопили за эти годы.
Рамки обеспечивают стандартизованные и проверенные способы выполнения действий. Чем больше пользователей имеет определенную структуру, тем больше случаев, которые встречаются и закодированы. Ваш собственный код может, а может и не быть, сражаться так же.
Другие могут быть набраны в проект со стандартной структурой и иметь доступ к документации, примерам и опыту в этой структуре. Ваши собственные фрагменты могут быть или не быть полностью задокументированы или иметь примеры использования … но не так много шансов, что другие с ними удобны.
РЕДАКТИРОВАТЬ:
Что касается вашей идеи упаковки ваших собственных фреймворков, то польза для ее очистки для общественного потребления может быть больше, чем использование других.
Причина проста: вам придется переоценить свои предположения о каждом компоненте, о том, как они подходят друг другу и насколько ясно, что каждая часть должна понимать. Как только вы опубликуете свою фреймворк, ваш успех будет сильно зависеть от того, насколько легко будет вставать и работать.
Большие победы с небольшими усилиями необходимы для принятия (эти победы побудят людей углубиться в рамки). Ruby on Rails в примере структуры, которая дает такие большие выигрыши с небольшим усилием, а затем имеет скрытые слои функций, которые могли бы перегружать кого-то, только начав работу. (Вопрос о качестве RoR-приложений не тот факт, речь идет о скорости принятия).
После того, как люди принимают рамки, речь идет о легкости дальнейшего использования. Небольшие детали, такие как последовательные шаблоны использования параметров, имеют здесь разницу. Если у одного класса есть много параметров для каждого метода, в то время как у другого есть сеттеры, которые, как ожидается, будут вызваны перед вызовом методов, вы потеряете пользователей, потому что они не могут «почувствовать» то, что ожидается в данном случае, не прибегая к документы.
Если и простота принятия, и простота в проживании – с проблемами решаются должным образом, вам нужно только получить удачу для людей, чтобы принять вашу структуру. Если эти проблемы не будут исправлены должным образом, даже первоначальный интерес к этой структуре быстро исчезнет. Причина в том, что существует множество фреймворков: вам нужно выделиться, чтобы воспользоваться преимуществами того, чтобы другие использовали ваш комплект (поскольку они по праву так же настороже относятся к вашей структуре, как и к другим).
Вот еще одна причина не создавать свои собственные рамки. Закон Линуса – «Учитывая достаточно глазных яблок, все ошибки мелкие». Другими словами, чем больше людей используют данную структуру, тем более надежной и безнадежной она, вероятно, будет.
Вы видели, сколько веб-фреймворков существует для Java? В тот же день для любого полуподобного разработчика / архитектора было модно писать собственную веб-инфраструктуру. И в конце концов, 95% из них выглядели как обычная реализация Struts (самой популярной веб-структуры Java в то время). Таким образом, они в основном создали клон Struts, который был: 1) проприетарным; и 2) не так хорошо документированы и проверены.
Давайте посмотрим правде в глаза – писать собственные рамки для клиентов – это весело, но что будет дальше? Это становится нагрузкой на обслуживание, чтобы идти в ногу с каркасом самостоятельно (или бедная душа, которая заменяет вас). И обслуживание программного обеспечения намного, гораздо более дорогостоящее, особенно когда речь идет о пользовательских инфраструктурах. Является ли компания в бизнесе разрешать проблемы с доменом или в бизнесе поддержки фреймворков?
Я забыл, кто это сказал, но однажды я услышал отличную цитату: «Первое правило создания собственной структуры:« не ». Кто-то еще, возможно, предпринял все усилия и, возможно, выполнил ту же работу, которую вы сделали бы. Сэкономьте время, усилие и тестирование.
Здесь много комментариев о преимуществах использования структуры, и, конечно, я думаю, что в очень многих случаях они совершенно правильны.
ОДНАКО
Все рамки имеют недостаток, что у них есть область проблем, которые могут быть установлены в них. Если ваша проблема находится в пределах области действия домена, то использование фреймворка не является проблемой, и в большинстве случаев это легко понять, если ваша проблема находится за пределами домена, поэтому вы не задумываетесь. Проблемы возникают, когда вы пытаетесь заставить проблему в рамках, которая просто не совсем вписывается или имеет какую-то необычную нестандартную функцию – в этом случае вы выполняете 90% кода очень быстро, а затем тратите все время, которое у вас есть сохраненный, чтобы выяснить, как сгибать или расширять рамки, чтобы он мог выполнить некоторые неясные требования. Поскольку в этом случае ваше решение / расширение должно подключаться к фреймворку, его часто бывает сложнее закодировать, чем если бы вы приходили к нему независимо.
В неправильных обстоятельствах это может быть катастрофическим. Например, если клиент запрашивает проект, который, по вашему мнению, будет вписываться в решение framework, и вы указываете его соответствующим образом, то после завершения 90% вы найдете gotcha, тогда вы можете быть действительно за рулем, особенно если это какая-то особенность, (и это всегда так). Эти проблемы, как правило, возникают из-за того, что не всегда очевидно, что слово «gochas» может лежать, особенно если вы используете структуру, с которой вы менее знакомы (и вам приходится время от времени).
Это действительно та же проблема, что и при развертывании стороннего программного обеспечения в проекте. Сам по себе я не испытываю никаких сомнений в использовании фреймворков или подобных, но, учитывая выбор, я всегда буду искать самую легкую, тонкую оболочку, которую я могу найти, которая будет делать то, что мне нужно. Таким образом, я получаю преимущества, зная, что если возникают проблемы (и они, как правило, менее склонны к более тонкой обертке), то выяснение того, как работать вокруг них, вероятно, будет проще, чем изучение обширной базы кода до точки где я могу безопасно его модифицировать.
Код структуры, вероятно, будет хорошо протестирован и относительно свободен от ошибок. Используя его, вы сэкономите время на тестирование / поддержание собственного кода, чтобы сделать то же самое.
И в любое время сохраняется хорошо. Лень окупается в программировании.
Одна вещь, которую вы упустите, – это проверка, которая входит в популярную структуру.
У ваших подпрограмм просто нет той же экспозиции, что и в популярных библиотеках.
У вас может быть точка … однако я бы не стал недооценивать силу многих, поскольку пример phpBB до сих пор касается решения bb для использования. Зачем? Потому что в их советах поддержки много и много тысяч сообщений, и многие люди используют его, которые хорошо осведомлены и могут помочь людям решить проблемы.
Поэтому единственная причина в вашем случае использовать популярную структуру – это многие другие, которые ее используют, сообщают об ошибках, исправляют и поддерживают ее. Было бы сложно получить такой же охват в ваших собственных библиотеках.
Я бы пошел против зерна здесь и сказал, что вы должны использовать свои собственные рамки, если созданное вами программное обеспечение является основой вашего бизнеса. Джоэл сказал: « Найдите зависимости и устраните их ». Если вы просто размещаете небольшой веб-сайт для своей компании, а ваш бизнес не поддерживает веб-сайты, тогда идите и используйте фреймворк. Но когда этот сайт является вашим бизнесом, вы не должны зависеть от структуры от кого-то еще, чтобы позволить вам выполнить работу.
Я думаю, что основная причина заключается в том, что, когда вы используете общую структуру, есть много людей, которые мгновенно знакомы с вашим продуктом.
Помимо этого, я думаю, что самое главное, чтобы любые инструменты, которые вы используете, действительно выполняли свою работу. Если это знакомо другим людям, то это бонус.
Я согласен, что вы должны использовать свою собственную фреймворк. Вам не только легче понять, но и обеспечивает максимальную безопасность работы!
Три причины, о которых я могу думать сразу:
Все это говорит о том, что все еще может быть место для ваших собственных решений. У нас не было бы так много фреймворков (или языков сценариев) на выбор, если бы никто не начал что-то новое.
Любой опытный разработчик может создать структуру – сложная часть убеждает других в том, что ее стоит использовать . Вам нужно будет создать документацию и учебные пособия для тех, кто планирует использовать или поддерживать ее. Вероятно, вам нужно создать демонстрационный сайт, чтобы доказать, что он полезен и на самом деле работает, как и предполагалось.
Это само по себе может быть значительным капиталовложением, не считая ошибок, которые могут возникать между ними. Когда все было сказано, это может стоить потратить время на изучение другой структуры вместо того, чтобы сделать свой собственный.
Вы упоминали CodeIgniter – я лично чувствую, что это симпатичная фреймворк – у него не получается гораздо больше баребонов.
То, что у вас есть, есть ваши собственные рамки. Таким образом, это не время для вас, потому что вы уже потратили время на разработку структуры. Если у вас не было этого, чтобы построить, то, конечно, было бы проще и быстрее использовать существующую структуру, чем сворачивать свои собственные.
На что вам нужно взглянуть, является ли ваша структура лучше, чем другие варианты там, и зависит ли ваше знакомство с вашим собственным кодом, если другие глаза смотрят на нее, а другие люди используют ее достаточно разными способами, чтобы вероятность любого проблемы, найденные и исправленные, намного выше.
Кроме того, если ваша инфраструктура намного лучше всех elses ', вы можете рассмотреть возможность открытия вашего сообщества;)
Как вы, наверное, знаете: «время – деньги». Таким образом, используя популярную структуру с большим количеством помощников, множество примеров кода в Интернете и большое сообщество вы делаете больше за меньшее время.
Иногда это нормально, если вы используете фреймворки, потому что вы становитесь более продуктивными, но в некоторых продвинутых и сложных проектах это может случиться так, что рамки будут оставаться на вашем пути, и вы должны найти обходные пути.
Я думаю, что нет окончательного ответа. Вы должны сбалансировать плюсы и минусы и принять правильное решение для своего проекта.
Обычно я принимаю популярные фреймворки очень быстро, но не в критических частях проектов, и со временем я расширяю их использование.
Я думаю, что если вы не видите необходимости использовать фреймворк, тогда не делайте этого.
Причина, по которой я использую структуру, например Django для python или Rails для Ruby или Webforms и MVC для ASP.net, заключается в том, что они упрощают и ускоряют запись приложений для них. В случае с Ruby и Python, не использующим рамки для меня, я сошел с ума.
Если у вас есть что-то, что работает, и я не вижу необходимости использовать структуру, я бы сказал, что придерживайтесь того, что вы считаете лучшим. Но я все равно буду следить за рамками.
Я думаю, что они более полезны, если вы начинаете с нуля и не имеете времени писать свои собственные. Если у вас уже есть кодовая база, которую вы разрабатывали на протяжении многих лет, они могут быть гораздо менее полезными, но может быть полезно взглянуть и посмотреть, что они сделали.
Например, я уверен, что крупные магазины разработки игр не используют сторонние инструменты, двигатели и фреймворки, а не потому, что их недостаточно, но они уже создали свои собственные с 80-х годов или что-то еще.
Кроме того, если вы используете готовый компонент, нет возможности превысить его в своей конкретной области. Если вам нужно быть лидером на рынке в определенном измерении, вы должны создать собственное решение в этом измерении, чтобы вы могли вести. Если вам не нужна эта возможность, использование стороннего компонента, который так же хорош, как ваш, может быть хорошим решением, если это простой переход. Время тренироваться в новом инструменте и жить с его особенностями может или, возможно, не стоит того.
Другое дело, чтобы подумать, что если вы можете что-то построить, вы действительно это понимаете. В противном случае вы этого не сделаете. Теперь вам не нужно полностью понимать материал, чтобы использовать их, пока они «просто работают», но мы все знаем, как это происходит … 🙂
Можете ли вы решить проблемы, которые у вас есть, с вашим кодом быстрее и надежнее, чем государственные системы?
Если да, то продолжайте использовать свои собственные.
Если нет, то найдите фреймворк, который выполняет лучшую работу и запускается с ним для этого проекта.
Все сводится к тому, чтобы кодовая база выполняла работу лучше (для ценности, лучше предоставляемой клиентом.;))
Недостатки.
Большинство рамочных работ не ориентированы на объекты. (воспламенитель кода действительно показывает некоторый предмет)
Большая часть кода выполняется через include. пытаясь отследить проблему, это как натягивание нитки на свитере и необходимость разгадать всю одежду, чтобы полностью понять создание.
Большинство рамочных работ имеют плохо написанную документацию.
Большинство рамочных работ пытаются сделать много чего.
Я нахожу из своего опыта, развивающегося с рамными работами, что для получения верхней части базы кода требуется 3-6 месяцев. И только после этого периода времени, когда вы обнаружите погоду, вы пытаетесь поместить квадратный колышек в круглое отверстие. Учитывая, что большинство проектов php хотят быть законченными до истечения этого периода, это будет стоить работодателям больше, чтобы получить какой-либо проект с использованием большой «каркасной работы» для реализации.
Многие из работ php Frame были написаны для php 4 и были написаны в другом окружении. Они значительно расширены, но показывают свое происхождение. Особенно широко распространено использование глобальных ограничений. Я надеюсь, что php 6 ставит большинство из них на смерть. Код воспламенителя избегает большей части этого, но он является новым и имеет объекты, ориентированные на объект.
Некоторые работы фреймов написали код, который не нужен, и вызывает проблемы .. например: у CAKE есть превосходный контроллер представления модели, но его обработка сеанса является катастрофой. К сожалению, рамочные работы написаны не модульным способом. Часто его вариант «все или ничего».
Мост-программисты «взламывают» рамочную работу, чтобы заставить ее делать то, что они хотят. Это оставляет будущих программистов, вытягивающих головы. Это также делает невозможным «модернизацию» рамочной работы.
Мне еще предстоит увидеть рамочную работу, которая реализует модульное тестирование. (откуда вы знаете, что вы его не нарушили).
дайте мне хорошо написанный объект в любое время. По крайней мере, вы знаете масштаб с самого начала.
Преимущества заключаются в том, что он уже написан и протестирован несколькими людьми, поэтому он менее подвержен ошибкам.
Недостатки в том, что он не создан специально для вашего приложения и поэтому, скорее всего, будет хуже.
В целом, я не могу видеть много причин использовать один, учитывая, что у вас уже есть свой … хотя, возможно, стоит освободить этот открытый источник, чтобы другие могли проверять ошибки и рекомендовать улучшения.