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

Question

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

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

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

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

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

Answer 1

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

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

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

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

РЕДАКТИРОВАТЬ:

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

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

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

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

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

Answer 2

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

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

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

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

Answer 3

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

ОДНАКО

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

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

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

Answer 4

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

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

Answer 5

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

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

Answer 6

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

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

Answer 7

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

Answer 8

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

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

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

Answer 9

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

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

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

Answer 10

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