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

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

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

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

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

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

Сценарий, которого следует избегать
Например, давайте представим, что некая компания начала свой проект в 2014 году и на тот момент выбрала Laravel 4 для разработки проекта. Вскоре ей пришлось внести некоторые изменения во фреймворк, и она начала переделывать его, чтобы он соответствовал ее требованиям.

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

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

Другими словами, эта компания работает на совершенно другом фреймворке, но это гибридный фреймворк, это не собственный фреймворк, а построенный только на том, что вам нужно, и это не фреймворк Laravel 😅

Это большая проблема, потому что теперь у вас в руках бомба замедленного действия, и вы не знаете, когда она взорвется 💣 бомба, которую вы не проектировали, но у вас хватило смелости попытаться разобрать ее и вмешаться в нее и внесите в него изменения 😄

наконец
Надеюсь, я хорошо ответил на вопрос.

Теперь нам может быть известна одна из самых важных причин, по которой некоторые веб-сайты полагаются на языки программирования, а не на фреймворки как таковые.
ISSA MOHAMED ALI
YASSINE HOUTA