Когда НЕ использовать рамки [закрыто]

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

Тем не менее, я думаю, что у ЛЮБОЙ основы есть и обратная сторона в том, что программисты, как сообщество, могут настолько полагаться на выбранные ими структуры, что они больше не понимают основополагающие принципы работы, или, в случае более новых программистов, никогда не изучают основополагающие принципы работы, чтобы начинать с. Легко стать специализированным до такой степени, что вы уже не «программист PHP» (например), а «программист Drupal», исключая все остальное.

Кого волнует, верно? У нас есть рамки! Нам не нужно знать, как «сделать это вручную»! Правильно?

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

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

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

«Должна быть хорошая метрика, чтобы определить, когда целесообразно использовать каркас».

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

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

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

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

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

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

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

Я склонен работать в основном с веб-приложениями, и хотя я стараюсь быть общим, мой ответ может не относиться к вашей области программирования.

Я также собираюсь использовать «каркас», синонимичный с «библиотекой».

Перед реализацией фреймворка необходимо рассмотреть несколько вещей, вот несколько общих примеров.

# 1. Сэкономит ли каркас время и усилия?

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

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

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

Это может замедлить процесс разработки, что может быть дорогостоящим.

# 2 Масштаб вашего приложения

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

Когда вы разрабатываете приложение (будь то веб-приложение, приложение для ПК, мобильное приложение или приложение любого другого мыслимого типа) - если вы чувствуете, что размер вашей среды «карликов» для вашей (возможно, будущей) реализации, то это может быть большим предупреждающий знак того, что ваш фреймворк может просто раздуть ваше приложение Хороший анекдот был бы, если бы вы включили jQuery, просто добавив «загруженный» класс к вашему тегу body, когда документ будет готов. Делать это с использованием только собственного JavaScript-кода может быть немного сложнее , но это не приведет к расширению вашего приложения.

С другой стороны, если фреймворк выполняет много грязной работы внутри (т. Е. Фреймворки баз данных), он может быть жизнеспособным для реализации, даже если вы только «частично» используете фреймворк. Хорошим анекдотом было бы не пытаться создать свой собственный ADO.NET или MongoDB-драйвер только потому, что вам не нужно использовать всю библиотеку.

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

В конечном итоге это связано с вопросами № 1 и № 3.

# 3 Воздействие.

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

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

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

Некоторые структуры также могут быть очень ресурсоемкими.

Это, конечно, связано с пунктами № 1 и № 2.

Это всего лишь большой «круг вопросов», и нет никакого реального научного метода для решения, следует ли вам внедрять фреймворк или нет.

Корбин Марч суммировал это очень хорошо:

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

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

Все фреймворки имеют прецеденты, это просто вопрос их реализации для правильных целей.

Знают ли другие разработчики фреймворк?

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

Что касается вашего заявления о том, что новые программисты не знают основ, вы гораздо более сострадательны, чем я! Да, это позор, но я собираюсь тратить свое время на беспокойство о чьей-то неумелости? Nup. (Исходя из предположения, что эти новые члены сообщества не сразу работают с вами.)

Я бы использовал рамки, если (и ТОЛЬКО если) выполняются следующие условия:

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

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

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