Зачем мне нужна популярная структура?

Ответ 1

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

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

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

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

ИЗМЕНИТЬ:

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

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

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

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

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

Ответ 2

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

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

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

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

Ответ 3

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

ОДНАКО

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

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

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

Ответ 4

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

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

Ответ 5

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

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

Ответ 6

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

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

Ответ 7

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

Ответ 8

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

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

Ответ 9

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

Ответ 10

Три причины, о которых я могу сразу подумать:

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

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

Ответ 11

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

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

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

Ответ 12

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

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

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

Ответ 13

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

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

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

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

Ответ 14

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

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

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

Ответ 15

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

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

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

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

Ответ 16

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

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

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

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

Ответ 17

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

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

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

Ответ 18

Недостатки.

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

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

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

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

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

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

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

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

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

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