Если вы находитесь в начале своего Великого Путешествия по JavaScript, прыжок между «-Как использовать эту штуку?!» и «-Хорошо, давайте использовать Angular!» может быть совсем не таким осознанным. Без необходимого опыта очень легко отвлечься на известных инфлюенсеров, связанных с горячими технологиями — крутые ребята говорят, что вы должны использовать XYZ, поэтому вам обязательно нужно использовать XYZ!
Не волнуйтесь, это довольно легко понять — мы все были там. Я думаю, что большинство из нас часто придерживаются некоторых известных фреймворков только потому, что кто-то говорит, что «это работает». Вот почему сегодня я хотел бы сосредоточиться на решающем этапе нашего обучения — моменте, когда мы решаем, что внедрение фреймворка в жизнь нашего разработчика было бы хорошей идеей.
Перво-наперво
Мы не можем говорить о такой вещи, как «фреймворк», не определив, что это вообще означает. Тетя Википедия должна нам помочь в этом деле:
В компьютерном программировании программная среда представляет собой абстракцию, в которой программное обеспечение, обеспечивающее общую функциональность, может быть выборочно изменено дополнительным кодом, написанным пользователем, таким образом предоставляя программное обеспечение для конкретного приложения. Программная среда — это универсальная повторно используемая программная среда, которая обеспечивает определенные функции как часть более крупной программной платформы для облегчения разработки программных приложений, продуктов и решений.
Если вы опытный разработчик программного обеспечения, это определение должно закрыть дело. Фреймворк — это своего рода абстракция (?), которая обеспечивает общую функциональность (??), и часто может быть связана с программными платформами (???).
Надеюсь, я не единственный, у кого сейчас больше вопросов, связанных с фреймворками, чем ответов. Так что, если Википедия не очень полезна для нас, давайте взглянем на несколько практических примеров.
Жизнь без рамок
Чтобы понять преимущества фреймворков, нам нужно попробовать немного другой подход. Действительно ли жизнь без них так тяжела, как говорят люди? Может быть, нам стоит попробовать создать какое-то демонстрационное приложение без использования какой-либо единой среды, скажем, на… JavaScript?
Угадайте, что — я заметил, что в моем профиле GitHub вы можете найти что-то вроде этого — приложение ToDo, написанное на чистом JS! И что еще интереснее, я также создал запись в блоге об этом маленьком монстре [PL].
Короче говоря, мы хотели бы создать приложение, которое должно соответствовать заданным критериям приемлемости:
- пользователь может добавить новый элемент todo
- пользователь может удалить элемент
- … больше бизнес-требований здесь
Неопытный может подумать, что мы будем только предоставлять все больше и больше бизнес-ценностей. Остальное никого не волнует, верно? Именно в этот момент мы можем подумать о каком-то уравнении:
[ Чем заняться ] = [ Предоставление ценности для бизнеса ]
Выглядит многообещающе, но эй! Не будем забывать, что у нас нет доступных фреймворков! Как вы можете догадаться, с этим подходом связаны некоторые подводные камни:
- у нас нет стартовых наборов для сборки таких вещей
- мы не можем предоставить какие-либо шаблоны и рекомендации для нашей команды.
- мы не можем построить бизнес-функциональность поверх… ничего
Архитектура? Мы должны изобрести его с нуля. Список рендеринга? Нам нужно создать визуализатор. управление домом? Мы должны создать менеджера. Государственное управление? Неа. Слушатели событий? Простите за это.
теперь понимаешь? Как выяснилось после нескольких рабочих дней, более подходящее уравнение должно выглядеть так:
[ Чем заняться ] = [ Предоставление бизнес-ценностей ] + [ Структура файла ] + [ Управление DOM ] + [ Обработка событий ] + [ Управление состоянием ] + [ Любые новые вещи, которые мы хотели бы реализовать ]
Черт…
Нам нужен больший масштаб
Теперь вы можете сказать, что такие приложения живут только в моем воображении, потому что вы знаете… это реальная жизнь, и мы настоящие разработчики! Мы больше не создаем приложения todo! У нас нет таких проблем!
Do we?
Вы правы — этот пример был только первым шагом к пониманию жизни без фреймворков. Теперь давайте подумаем о проблемах в более широком масштабе.
Прежде всего — как насчет поддержки проекта без предопределенных инструкций? Держу пари, это был бы кошмар! Просто попробуйте представить ситуацию, в которой каждый мог бы добавлять новые вещи любым способом только потому, что у него или у нее нет шаблонов для подражания. Через несколько дней или, по оптимистичному сценарию, месяцев мы получим нечто ужасное.
Также было бы невозможно использовать знания команд из другой компании, штата или страны — мы были бы привязаны к своему единственному оригинальному решению со всеми его недостатками. Отсутствие фреймворка = отсутствие общего языка = отсутствие решений уже решенных проблем. Потеряно время на изобретение велосипеда.
Также потребуется много промежуточной кодовой базы — предоставление бизнес-ценностей станет возможным после десятков часов, потраченных на реализацию средств визуализации, менеджеров, сервисов и других основных концепций. И если говорить об основных понятиях… безопасность и производительность также должны быть включены, потому что вы знаете — это безопасность и производительность.
Хотели бы вы работать в проекте со всеми этими проблемами? Я бы не стал. Определенно это не то, на что я смотрю и думаю: «Черт, мне нужно отправить туда свое резюме!».
Конечно, сейчас вы можете спросить: «Как нам решать такие проблемы?». Давайте посмотрим на решение.
Мы ждали тебя, чувак!
Момент настал.
Теперь мы можем поговорить о слове «ф». Я имею в виду… о структуре, конечно.
Для меня фреймворки связаны с двумя очень важными вещами:
- решения постоянно возникающих проблем
- шаблоны для создания новых функций и расширения существующих
Вот и все.
Почти каждое определение этого слова, которое вы можете найти, может быть сведено к этим двум пунктам, которые я упомянул выше. Решения и закономерности.
Но это еще не все!
Фреймворки позволяют разработчикам использовать общий язык для общения друг с другом, они сокращают время, необходимое для изобретения велосипеда, и часто помогают найти лучшие способы создания и структурирования приложений.
Они не должны быть связаны с конкретными проектами. Вместо этого они должны быть связаны с конкретными типами проектов, такими как внутренние службы, внешние приложения и т. д. В различных областях разработки программного обеспечения есть свои проблемы, которые фреймворки пытаются исправить или хотя бы скрыть, и поэтому мы не можем говорить о том, что «один фреймворк правит ими всеми». Это просто не имеет смысла.
Фреймворки часто связаны с другим загадочным словом, которое называется «шаблон» — некоторый объем кода, который нам нужно написать, чтобы правильно использовать наш фреймворк. В зависимости от выбранного, этот так называемый шаблон может быть меньше или больше (придерживайтесь меньшего размера), но в результате его написания мы получаем множество шаблонов и ярлыков, готовых для использования в наших проектах.
Подводя итог — каждому проекту нужна какая-то основа, поэтому мы используем фреймворки.
Со всеми этими знаниями мы можем теперь изменить наше предыдущее уравнение следующим образом:
[ Чем заняться ] = [ Предоставление ценности для бизнеса ] + [ Использование платформы ]
Что это означает?
Это означает, что большую часть времени мы должны думать только о вещах, связанных непосредственно с нашей сферой деятельности, а общие вопросы должны быть делегированы какой-то структуре (абстракция, о которой говорилось в определении Википедии).
Что еще более важно здесь, так это то, что эта идея применима к каждому языку или технологии, которые мы используем. У C# есть свои фреймворки, у JavaScript есть свои фреймворки, у Java есть свои фреймворки. Весьма вероятно, что общие проблемы и проблемы, связанные с каждым из этих языков и приложений, написанных на них, уже были упакованы в какой-то фреймворк (.NET, Spring, Angular, Django и т. д.), который вы можете использовать, не задумываясь об этом. .
Дайте мне несколько примеров!
Боюсь, я не могу этого сделать.
Вы можете легко погуглить самые популярные фреймворки и их сильные стороны и сами посмотреть, как они работают. Для меня просто нет смысла говорить об Angular, Django или любом другом фреймворке, не предоставив более широкого взгляда на эту тему.
Вместо того, чтобы сосредотачиваться на их именах или номерах версий, помните следующее:
- использование фреймворков является отраслевым стандартом — с ними ваш проект будет проще понять всем, кто разбирается в игре
- фреймворки позволяют сократить время, необходимое для написания промежуточного кода — большую часть времени вы должны быть сосредоточены на бизнес-области
- все ошибки, которые вы можете сделать, изобретая велосипед, уже исправлены авторами фреймворков
- с фреймворками вы можете бесплатно получить программу обновления в критических разделах вашего проекта
- фреймворки часто создаются первоклассными разработчиками, которые в этом случае каким-то образом работают на вас
Очень легко следить за всей шумихой вокруг новейших инструментов на рынке, не задумываясь «зачем они нам вообще нужны?», поэтому я решил написать этот пост.
Важно понять, почему такие вещи, как Angular или React, не следует рассматривать только как изобретение так называемых «крутых детей», но вместо этого они часто стоят за успехом столь многих приложений и продуктов, которые вы используете, и даже некоторых глобальных компании.
Конечно, можно еще многое сказать о фреймворках в целом, об их влиянии на отрасль, об их великой ценности с точки зрения бизнеса, но сейчас вы должны хотя бы знать основы — я надеюсь, что ваши знания связаны с использованием фреймворков. вырос.
Исходную версию этого поста можно найти в блоге PoznajProgramowanie.pl.
