Как стать автором
Обновить

Фреймворки — больше минусов чем плюсов

Время на прочтение4 мин
Количество просмотров8.6K
Поводом для этой статьи стала другая публикация на Хабре. Называется она «Не учите фреймворки, учите архитектуру» и почитать ее можно здесь.

Сразу оговорюсь, что с автором я полностью согласен и всего лишь хотел бы добавить свои «три копейки». Сначала думал сделать это прямо в комментах под статьей, но быстро понял, что «копейки» получаются довольно объемные. Так и родился этот текст.

Сначала немного о себе


Веб разработкой я занимаюсь года так эдак с 98-го. Работал и на компании и фрилансером. Сам набирал команды. Как в реале так и в сети. Первым языком программирования был ныне благополучно почивший perl и о его безвременной кончине жалею до сих пор. Потом пришел php. Еще чуть позже ruby и началась эра фейерверков.

Большие обещания маленькие достижения


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

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

И это раз… и это два…

Эраст Фандорин
Моя первая претензия и к RoR, и Yii, и Symfony, и почти всем иным, с которыми пришлось познакомиться — их монстрообразность и тонны совершенно лишнего кода, который неизменно оказывается в проекте. Привыкнув за много лет работы, что код должен быть максимально чистым и лаконичным, что приложение должно быть как можно более быстрым, я в не мог согласится с тем мусором (уж извините по-другому сказать не могу), что оказывался в проектах.

Вторая претензия — попытка всех без исключения авторов фейерверков изобрести, что-то вроде своего языка программирования. Поясню о чем это я. Возьмем к примеру самую распространенную js библиотеку jQuery. При этом сразу оговорюсь, что именно ее я считаю чуть ли не единственно полезной, грамотной и еще много-много лестных эпитетов, среди подобных. Привожу jq в качестве примера только потому, что наверняка всем будет понятно о чем я. И так получить доступ к элементу по ID на нативном js можно так document.getElementById(«id»), а на jQuery так $(«#id»). То что при этом было написано на десяток символов меньше, меня не сильно впечатляет. При этом jq имеет кучу других плюсов ради которых я готов освоить новый синтаксис. Кроме того она надежна и практически никогда не конфликтует с другими библиотеками. Чего не скажешь и куче ей подобных, которые прочат на замену.

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

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

И это три…

Он же

Все выше сказанное касается не только front, но и back. Как следствие возникает вопрос — в самом начале я признал, что в ходе любой разработки приходится выполнять множество ненужных телодвижений, которые хотелось бы оптимизировать, но можно ли это делать такой ценой? А кроме того есть еще один момент, который в большей части касается разработки на Ruby.

Для реализации самых элементарных функций web приложения вам необходимо подключать отдельные gem-ы. Чтобы подкормиться к базе — mysql2, чтобы отправить mail — mail или созданный на его основе poni. И так далее и тому подобное. На первый взгляд ничего страшного в этом нет — все gem-ы в Ruby, как правило, хорошо оттестированы и проблем с ними не возникает. Но из этого правила тоже есть исключения. Например один раз целую неделю пришлось просидеть с odf-report, который никак не хотел корректно работать, а потом плюнуть и написать свой класс. Кроме того несколько напрягает, что с подключением каждого gem-a неизбежно возрастает время формирования страницы. На некоторых gem-aх совсем незначительно. А не некоторых…. Попробуйте поэкспериментировать на эту тему с уже упомянутым pony — сами убедитесь.

Извечный вопрос


И что же делать? C одной стороны разработка на «чистом» языке — однозначно не вариант, а с другой и существующие инструменты не устраивают по целому ряду причин? Выход видится в создании инструмента, который бы оптимизировал наиболее часто используемые функции и одновременно не стеснял программиста, и не навязывал ему стиль программирования который автор этого инструмента считает единственно правильным. На практике, это означает, что инструмент должен:

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

Может я не прав, но пока, что в обратном меня переубедить ни кто не смог. Готов выслушать любые мнения.
Теги:
Хабы:
Всего голосов 47: ↑14 и ↓33-16
Комментарии52

Публикации

Истории

Ближайшие события

15 – 16 ноября
IT-конференция Merge Skolkovo
Москва
22 – 24 ноября
Хакатон «AgroCode Hack Genetics'24»
Онлайн
28 ноября
Конференция «TechRec: ITHR CAMPUS»
МоскваОнлайн
25 – 26 апреля
IT-конференция Merge Tatarstan 2025
Казань