Pull to refresh

Фреймворки портят разработку

Reading time 2 min
Views 12K
Вступление

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

Сама мысль

Я полагаю, вы согласны с тем, что программирование имеет 2 смысла. Первый — мощный инструмент для решения сложных проблем(иногда простых), второй — творчество. Если с последним всё понятно — вы получаете удовольствие от процесса, придумывая оптимальный алгоритм или создавая что-то новое, то с первым не совсем.

Написание любого кода приводит к созданию какого либо продукта (хорошего или нет — не важно). Этот продукт и есть решение проблемы. Нужно распознать человека на фото/видео — задача, программа, которая делает это — продукт, код — инструмент. И ваша задача состоит в том, чтобы конечный продукт решал начальную проблему. Я не говорю о том, что нужно/можно писать говнокод и радоваться жизни — нет, так нельзя. Нужно помнить об оптимальности алгоритма и потребляемых ресурсах. Но погоня за идеальным кодом – не лучшая идея, на мой взгляд. Нужно всегда искать и останавливаться на той золотой середине, которая дает лучшее соотношение затраченных сил и оптимальности решения.

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

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

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

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

Стоит вспомнить о набирающей в последнее время шутке про мощнейший и популярнейший фреймворк «vanilla.js».
Tags:
Hubs:
-13
Comments 96
Comments Comments 96

Articles