Почему мне нужно использовать популярный фреймворк?

Question

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

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

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

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

Редактировать: Глядя на некоторые ответы здесь, возможно, мне следует рассмотреть возможность упаковки своего набора инструментов в качестве собственной структуры, написания некоторой документации и публикации руководств? Если я не решаюсь брать на себя чужие рамки, поможет ли мне открыть их и увидеть больше, это поможет улучшить мои собственные навыки / инструменты?

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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

Answer 4

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

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

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

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

Answer 5

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

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

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

Answer 6

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

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

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

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

Answer 7

Недостатки.

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

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

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

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

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

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

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

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

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

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

Answer 8

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

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

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