Фреймворки ставят слишком много абстракций? [закрыто]

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

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

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

2. Делает код трудным для понимания из-за множества доступных фреймворков и модулей и всех их особенностей,

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

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

Нужно ли нам помещать около 50 уровней абстракции поверх чего-то такого простого, как запрос MySQL? Почему бы не использовать что-то вроде интерфейса PDO в PHP, где обрабатываются подготовленные операторы / тестирование ввода, но универсально понятный SQL-запрос все еще является частью функции?

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

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

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

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

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

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

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

Также следует различать технические абстракции и абстракции «бизнес-правил» . Программирование на языке более высокого уровня - это абстракция, которую вы, вероятно, не хотите пропустить (Python, PHP, C # против C против Assembler; Less против CSS), тогда как «абстракции бизнес-правил» могут быть трудными, если они этого не делают. Точно соответствует вашим потребностям (аутентификация в один клик или cookie-файлы с ручным кодированием).

Это потому, что технические абстракции редко «протекают», то есть вам вряд ли придется отлаживать машинный код при написании приложений на Python. Абстракции бизнес-правил работают на том же техническом уровне, и на самом деле являются просто «связками кода». Вам, вероятно , понадобится отладить установленный файл cookie или хэш пароля, созданный в какой-то момент, что означает, что вы будете копаться в большом количестве стороннего кода.

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

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

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

Вы получаете это с помощью PHP или Ruby, у вас уже есть огромное количество абстракций, не так ли? Самые очевидные из них:

1. Операционная система, язык программирования и компилятор обеспечивают огромную абстракцию над Ассемблером и оборудованием,

2. Веб-сервер обеспечивает абстракцию сокетов, аварийного переключения, протокола HTTP и т. Д.,

3. SQL обеспечивает абстракцию того, как данные хранятся в постоянной памяти и поддерживаются в памяти для более быстрого доступа, обеспечивают ACID, зеркалирование и т. Д.

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

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

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

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

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

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

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

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

Используя фреймворк, вы полагаетесь на код, который:

• Написано опытными разработчиками,

• Часто парный обзор,

• Unit-тестирование,

• Широко документировано,

• Используется годами тысячами разработчиков,

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

• Известный многими разработчиками, которые знают возможные предостережения и проблемы и могут помочь на таких сайтах, как Stack Overflow.

• Доступно для вас прямо сейчас, бесплатно.

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

Хммм. Одним из аспектов LedgerSMB, над которым мы много работали, был наш подход к фреймворку. Есть две фундаментальные проблемы, которые идут с такой абстракцией. Эти:

1. Взрыв зависимости, и

2. Неверная абстракция

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

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

Конечно, главная проблема заключается в том, что чем более автоматизирован код, особенно когда он непрозрачен, тем сложнее увидеть, что происходит не так. Это пункт о ORM, который @jhewlett делает выше (см. Https://softwareengineering.stackexchange.com/a/190807/63722 ).

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

Мы написали фреймворк LedgerSMB с нуля, потому что в то время, когда мы начинали, не было действительно хороших фреймворков, которые бы делали то, что мы хотели. На самом деле это одна вещь, которой я очень доволен, и, по словам нового разработчика проекта, это делает настройку приложения довольно простой. (На самом деле мы сводим генерацию кода SQL к минимуму и вместо этого сосредотачиваемся на написанных от руки пользовательских функциях, что означает, что части для написания SQL-файлов - очень тонкий клей). Да, в некоторых местах он обеспечивает большую абстракцию, более чем удобны для некоторых программистов (в частности, «сопоставление свойств объекта с аргументами в этой хранимой процедуре» время от времени заставляет нас отступать). Однако мы стараемся, чтобы все было простым и последовательным, чтобы было легко определить, что пошло не так. Это работает довольно хорошо.

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

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

Могут ли они быть раздутым излишним? Конечно. Это все зависит от того, что вам нужно, и что структура приносит на стол. Если у вас есть простое веб-приложение, возможно, Rails для вас излишне, и вам следует взглянуть на что-то более простое, такое как Sinatra, в качестве решения.

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

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

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

Рассмотрим объектно-реляционные сопоставители (ORM). Они хороши тем, что заботятся о многих утомительных кодах для вас. Они могут даже создавать ваши объекты для вас. Однако, абстрагируясь от SQL, гораздо сложнее рассуждать о производительности и оптимизировать свои узкие места.

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

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

Для меня решающим моментом является то, что я должен извлечь из ресурса больше, чем он требует от меня. Или, с другой стороны, я бы сказал, что, как только потребности структуры превышают доступные вознаграждения, все преимущества исчезают. Так что «Да! Пожалуйста! И благодарю вас!' всем, кто делает активы, которые будут работать прямо и по мере необходимости в моих собственных HTML / CSS / PHP и SQL.

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

Некоторые люди говорят, что это принцип Голливуда : «Не звоните нам, мы вам позвоним». Напротив, всякий раз, когда вы используете библиотеку, ваш код вызывает библиотеку , а не наоборот.

Как видите, важным моментом является то, кто контролирует, а именно контролирует поток контроля. Кто решает, какое утверждение будет выполнено после какого?

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

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

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

Я не думаю, что было бы разумно решить, что лучше быть похожим на первого или второго.

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

...

И даже более конкретно, если вам не нравятся фреймворки, такие как Django, отправляйтесь на поиск «микрорамок», таких как Flask :)