{"id":14279,"url":"\/distributions\/14279\/click?bit=1&hash=4408d97a995353c62a7353088166cda4ded361bf29df096e086ea0bbb9c1b2fc","title":"\u0427\u0442\u043e \u0432\u044b\u0431\u0435\u0440\u0435\u0442\u0435: \u0432\u044b\u0435\u0445\u0430\u0442\u044c \u043f\u043e\u0437\u0436\u0435 \u0438\u043b\u0438 \u0437\u0430\u0435\u0445\u0430\u0442\u044c \u0440\u0430\u043d\u044c\u0448\u0435?","buttonText":"","imageUuid":""}

Про фреймворки

Часть первая

Вступление

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

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

Когда начинаешь изучать программирование, чувствуешь себя всемогущим человеком, который может построить в домашних условиях полноценную систему или проект, чего не может сделать, например, инженер или строитель. Ты чувствуешь себя всемогущим и имеешь в голове грандиозные планы по написанию собственной игры, операционной системы и других глобальных проектов. Ты амбициозен, решителен и силён, и считаешь, что изучение навыков разработки программного обеспечения откроет тебе все двери для лёгкого построения собственной экосистемы. Я начал свой путь в программирование через одну книгу, в которой мне предложили создать игру с помощью Microsoft Power Point. Где можно было заменить ссылки картинками, по клику на которых нужно было переходить на следующие слайды. Это было забавно, пока я не упёрся в тот случай, когда мне стало необходимым хранить информацию об игроке (бонусы, жизни и т. д.). Случайно я наткнулся на диск с курсами по веб-программированию и дизайну. Я обнаружил, что можно создавать игры, используя веб-страницу, включая ссылки. Это вдохновило меня на разработку собственного сайта на любую тему и публикацию его в Интернете. Благодаря этим курсам я освоил основы программирования, что позволило мне создавать собственные веб-сайты. Впоследствии, поступив в университет, я продолжил обучение в этой области. В университете я также собирал свои велосипеды и к 3-му курсу изучал веб-разработку. Поначалу все было легко, пока учитель не заметил, что я могу выполнять задания быстрее других, и не дал мне дополнительную нагрузку. Помню, получил задание на создание функциональной системы аутентификации для сайта. Я написал код, который просто сохранял пароли в базе данных без шифрования и других необходимых элементов. Учитель указал на ошибки и объяснил, почему мой код неадекватен. Затем он познакомил меня, с фреймворками с готовыми шаблонами и инструментами для создания надежных приложений прямо из коробки. Далее я пошёл в армию, а после армии работал в различных местах, где применялись различные фреймворки для осуществления одних и тех же задач для бизнеса. По началу я как новичок очень быстро рос и жадно впитывал информацию, но со временем я стал делать тривиальные задачи, и стал писать не на самом языке, а на фреймворке и при переходе с одного рабочего места на другое, мне приходилось менять фреймворк и учить новый, тем самым росли мои навыки не по вертикали, а по горизонтали. И с годами я стал понимать, что если так всё продолжиться, то мы упрёмся в проблему в зависимости от фреймворков, а также потеряем мотивацию и цель разработки в целом.

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

Про фреймворки

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

Широкое распространение некоторых фреймворков обусловлено захватывающей полемикой против создания приложений с нуля с лозунгами типа «Не изобретайте велосипед!» и «Не обязательно все делать самому, об этом уже позаботились более опытные люди».

Фреймворк — это программная платформа, которая упрощает разработку программного продукта, определяет структуру проекта и помогает удобно объединять в нём разные компоненты.

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

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

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

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

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

О недостатках фреймворков

Ограничение творческого мышления

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

ООП — объектно-ориентированное программирование

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

Негибкие и загоняют в рамки

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

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

Снижают производительность

Абстракции

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

Про ORM

Очень сильно снижают производительность во фреймворках ORM.

ORM (Object-relational mapping), что в переводе означает «Объектно-реляционное отображение». Технология программирования, которая связывает базы данных с концепциями объектно-ориентированных языков программирования. По сути ORM — прослойка между базой данных и кодом, который пишет программист. Эта прослойка позволяет созданные в программе объекты складывать/получать в/из баз данных.

В начале ORM это очень полезная штука, она помогает вам быстро спроектировать проект, но по факту дальше начинается какое-то странное явление. Мы понимаем, что ORM существенно тормозит базу данных, мы начинаем некоторые запросы переделывать на plain SQL. Ещё лучше – пытаться написать на самом ORM хороший запрос. Это, вообще, страшное дело. Бывают случаи когда у вас уже много чего сделано на ORM, и вам нужно поправить часть запроса, чтобы улучшить производительность, но ORM не понимает что вы хотите от неё. Абсурд является в том, что у вас уже есть запрос который написан правильно, и вы пытаетесь написать его на ORM, чтобы тот сгенерировал запрос такого же вида для того чтобы он нормально заработал. Бессмысленность этого становится совершенно очевидной.

Продолжение следует...

0
1 комментарий
Иванов Иван

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

Ответить
Развернуть ветку
-2 комментариев
Раскрывать всегда