Содержание

Нам точно нужен фреймворк? / Хабр

К 2021 году появилось много статей о том, что фреймворки не нужны и не стоит делать из них культ. Отчасти это верно. Зависимость от фреймворка затрудняет процессы рефакторинга и тестирования, часто негативно влияет на выстраивание бизнес-логики приложения. Но во всём нужен разумный подход. И прежде чем встать на путь отрицания фреймворков, руководитель Программного комитета PHP Russia Александр Макаров советует прочитать статью Маттиаса Нобака (Matthias Noback) «Should we use a framework?»

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


Так как я много пишу о разработке распределённых приложений, неудивительно, что один из моих читателей задал вопрос: «Зачем использовать фреймворк?».

Короткий ответ: потому что он вам нужен. И вот почему:

  • Фреймворк делает за вас слишком многое. Вам потребуется уйма времени и денег, чтобы заменить всё это на самостоятельно написанный вами код.
  • Разработчики, поддерживающие фреймворк, исправили множество проблем ещё до того, как вы с ними столкнулись. Они постоянно заботятся о безопасности кода и исправляют проблемы по мере их появления. Вам остаётся только загрузить последнюю версию фреймворка.
  • Отказавшись от фреймворка, вы не будете зависеть от Symfony, Laravel, Yii и так далее. При этом вы будете зависеть от своего фреймворка, а это ещё большая проблема, так как поддерживать его вам и очень вероятно что делать это вы не будете (по моему опыту, в проектах с самописным фреймворком, поддержкой самого фреймворка почти никто не занимается).

В общем, фреймворк нужен всем. Но вам всё равно стоит писать независимый от фреймворка код там, где это возможно. Ведь если весь код проекта связан с фреймворком, то:

  • Сложно угнаться за изменениями в фреймворке. При обновлении API, пользовательских соглашений или лучших практик фреймворка обновление кода проекта занимает слишком много времени;
  • Трудно протестировать любую бизнес-логику без прохождения фронт-контроллера, анализа HTML-ответа или просмотра базы данных;
  • Тестировать что-либо будет сложно, потому что изолированное тестирование в таких случаях невозможно. Обязательно нужно будет настроить схему базы данных, заполнить ее данными или поднять какой-либо сервисный контейнер.

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

  • Сервисы приложения и командные объекты.
  • Сущности и интерфейсы репозиториев.
  • События домена и их подписчики.

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

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

Для себя я установил несколько правил для проверки изолированности бизнес-логики в проекте:

  1. Могу ли я перенести это приложение из веба в консоль, не затрагивая ни один из основных классов?
  2. Могу ли я создать экземпляры всех классов в ядре моего приложения без подготовки какого-либо специального контекста или настройки внешних сервисов?
  3. Могу ли я перенести это приложение из базы данных SQL в документную базу данных, не затрагивая ни один из основных классов?

Пункты 1 и 2 должны быть выполнены на все 100%. Что касается пункта 3, здесь могут быть варианты из-за извечной проблемы сопоставления сущностей с форматом их хранения. Например, у вас может быть некоторая логика сопоставления в вашей сущности (т.е. инструкции для вашего ORM о том, как сохранять сущности), но не должно быть никаких сервисных зависимостей, специфичных для выбранного вами хранилища. Например вы не можете внедрить EntityManagerInterface или использовать QueryBuilder где-либо в коде. Кроме того, вызовы методов никогда не должны приводить к реальным запросам к базе данных, даже если это Sqlite.

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

Этот слой содержит всю техническую информацию. Здесь вы найдете такие аббревиатуры, как SQL, ORM, AMQP, HTTP и другие. И именно здесь не стоит писать всё с нуля. Мы используем мощь фреймворков и библиотек, чтобы не отвлекаться на решение низкоуровневых проблем, а сосредоточиться на бизнес-логике и взаимодействии с пользователем.

Фреймворк должен помочь вам:

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

Я считаю, что достаточно хороший фреймворк должен обладать вот такими качествами:

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

В идеале фреймворк также:

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

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

Но пока эти практики не влияют на дизайн ядра, всё в порядке. Тем не менее, поддержка такой архитектуры требует определённой дисциплины. Когда дело доходит до изолированного ядра, не стоит срезать углы!

28 июня мы соберёмся на PHP Russia 2021. Обсудим, в том числе, фреймворки и библиотеки, расскажем об опыте реализации крупных проектов на PHP. У вас будет возможность пообщаться с core-разработчиками языка. Билеты уже в продаже. Присоединяйтесь!

Что такое Django REST Framework?

АВТОР: АЛЕКСЕЙ КУРЫЛЕВ

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

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

Чтобы ответить на вопрос, что же такое Django REST Framework, нужно разобраться со всей необходимой терминологией.

Framework

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

Также важно понимать отличия Framework от библиотеки. Это похожие вещи. В обоих случаях в Python вы должны установить нужный пакет, импортировать и пользоваться им. Разница в том, что библиотеку в проекте вы используете там, где нужно, и так, как вы хотите, а фреймворк сам определяет способ разработки приложения, то есть не только предоставляет удобные инструменты разработки в виде вспомогательных функций и классов, но и непосредственно формирует архитектуру проекта, создает структуру кода, проще говоря, определяет путь, по которому вы будете создавать свое приложение.

Django

На сегодняшний день наиболее функциональным фреймворком для создания веб-приложений на языке Python является фреймворк Django. Django можно назвать MVC-фреймворком, так он реализует взаимодействие пользователя и системы:

  • Model (хранит данные пользователя)

  • View (отображает данные пользователя)

  • Controller (принимает изменения данных от пользователя).

Внутри Django эта терминология звучит немного иначе, но суть остается той же.

Разработка Django началась в 2003 году программистами Adrian Holovaty и Simon Willison, а публичный релиз состоялся в 2005 году. Функционал фреймворка хорошо отвечал требованиям в веб-разработке того времени. Он активно развивается и до сих пор. Хотя этот фреймворк и считается довольно крупным и многофункциональным, сам по себе он не мог удовлетворить все запросы веб-разработчиков. За время его существования сторонними разработчиками было создано огромное множество библиотек и фреймворков в качестве дополнений к Django, которые упрощают реализацию тех или иных задач: аутентификация через социальные сети, кеширование данных, хранение файлов в облаке и многое другое. Некоторые из дополнений со временем сами стали частью проекта Django, как это произошло с библиотекой South, управляющей миграциями базы данных. Но большинство дополнений так и остались независимыми пакетами. Одним из них и является Django REST Framework, при помощи которого мы можем создавать Web API на основе Django.

Web API

Сегодня сеть интернет построена по принципу Клиент-Серверного взаимодействия. Клиент посылает запрос — Сервер ему отвечает. В случае, когда между собой общаются два Сервера, мы условно называем Клиентом того, который отправил запрос и ожидает ответ, а Сервером будет тот, кто принимает запрос и отвечает не него. Взаимодействие браузеров и веб-сайтов (первые выступают в роли Клиента, а вторые в роли Сервера) традиционно делалось при помощи технологии html-рендеринга, именно так изначально это делал Django. Чтобы получить данные с веб-сайта, браузер отправляет запрос GET к Серверу. Сервер формирует ответ в виде html-страницы и передает ее браузеру. Так Сервер передает данные браузеру, но как браузер может передать данные Серверу? В этой самой html-странице Сервер заложил все необходимые веб-формы, заполнив которые, пользователь мог бы передать свои данные обратно на сервер. Когда вы ввели свои данные в форму на сайте, бразуер отправляет Серверу запрос POST, в котором содержатся ваши данные, а Сервер обрабатывает их и записывает в базу данных.

Все это отлично работало, но уже в середине нулевых такой подход перестал удовлетворять возрастающим требования в веб-разработке. Появлялись мобильные приложения, различные гаджеты с доступом в интернет, и для них уже не подходил стандартный способ html-рендеринга на сервере, ведь теперь каждому клиенту нужно было отрисовать данные по-своему. Постоянно увеличивалось взаимодействие серверов друг с другом, и html-формат уже не подходил. Для всех этих задач есть другой способ обмена данными — Web API. Смысл этого способа в том, что Сервер передает Клиенту не html-страницу, а непосредственно данные, никак не влияя на то, как эти данные будут в итоге представлены. Наиболее популярными форматами для передачи данных становятся XML и JSON. Таким образом Сервер полностью избавляется от задачи отрисовки данных. Какое-то время длился переходный период, когда разработчикам веб-приложений на Сервере приходилось поддерживать оба способа одновременно: html рендерился на Сервере для браузеров, а Web API использовался для мобильных приложений и интеграции с другими серверами. Понятно, что разработчикам приложений на Сервере приходилось делать двойную работу. Но в начале десятых ситуация стала меняться в пользу Web API. Этому способствовало молниеносное развитие инструментов на языке JavaScript, а также появление различных веб-фреймворков, одним из которых и является предмет данной статьи.

Браузерные приложения быстро научились отрисовывать веб-страницы самостоятельно, получая чистые данные с Сервера. Веб-приложения на сервере научились создавать API быстро и легко. Так сформировалась четкое разделение на Backend и Frontend разработку: тех, кто поддерживает приложение на Сервере, и тех, кто делает браузерные (клиентские) приложения. А Web API стал универсальным способом общения для Сервера и всех его клиентов (браузеров, мобильных приложений, других Серверов). Конечно, это не могло не привести к развитию стандартов в общении между системами. И Клиенту, и Серверу необходимо знать каким образом общаться с друг с другом, как передавать данные, как сообщать об ошибках. Разработчики всегда могли договориться о том, как взаимодействовать их приложениям, но наличие некоего стандарта в веб-разработке позволило бы эту задачу облегчить. И вот в начале десятых таким стандартом стала концепция REST.

REST

В 2000 году Рой Филдинг написал докторскую диссертацию, где изложил концепцию REST. Там были рекомендации о том, как спроектировать Сервер, чтобы ему было удобно общаться с Клиентами. Выделю два главных принципа создания приложений в стиле REST:

  • Сервер не должен ничего знать о текущем состоянии Клиента. В запросе от Клиента должна быть вся необходимая информация для обработки этого запроса Сервером.
  • Каждый ресурс на Сервере должен иметь определенный Id, а также уникальный URL, по которому осуществляется доступ к этому ресурсу.

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

Действия для управления данными привязаны к определенным HTTP-методам. Существует несколько стандартных действий для работы с данными — это Create, Read, Update, Delete. Часто их обобщают как CRUD.

  • Для создания объекта используется http-метод POST
  • Для чтения — http-метод GET
  • Для изменения — http-метод PUT
  • Для удаления — http-метод DELETE

Давайте представим сообщения от Клиента к Серверу через Web API в стиле REST .

У нас есть объект Кошка, и мы хотим создать запись о кошке на Сервере. Для этого мы отправляем запрос на сервер:

POST — http://www.pets-server.ru/cats/

С данными в теле запроса

Name: “My Best Cat”
Color: “Red”
Age: 2

Плюс к этому запросу (и все другим) будет добавлен ключ аутентификации.

“Auth-Token”: “IPjxTy7Lodas343Fswv2”

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

Сервер ответит на этот запрос вот таким сообщением:

Id: 21
Name: “My Best Cat”
Color: “Red”
Age: 2

Сервер взял все поля, переданные клиентом, и добавил к ним поле Id. Здесь работает правило REST, согласно которому каждый ресурс должен иметь уникальный идентификатор и быть доступным по определенному URL. Сервер создал ресурс и вернул нам его Id.

Теперь мы можем получить данную запись по URL

GET — http://www.pets-server.ru/cats/21

Ответ сервера:

Id: 21
Name: “My Best Cat”
Color: “Red”
Age: 2

Что, если Клиент хочет изменить созданные им данные на сервере?

Отправляем запрос:

PUT — http://www.pets-server.ru/cats/21

С телом запроса:

Id: 21
Name: “My Best Cat”
Color: “Black”
Age: 2

Ответ сервера:

Id: 21
Name: “My Best Cat”
Color: “Black”
Age: “2”

Метод PUT используется для изменения данных. Номер 21 в URL говорит о том, какой именно объект нужно изменить. Теперь наша кошка имеет цвет “Black”.

Для удаления записи на Сервере достаточно отправить запрос:

DELETE — http://www.pets-server.ru/cats/21

С телом запроса:

Тут также мы указываем в Id объекта в URL, но передавать никаких данных в теле запроса для удаления объекта уже не требуется.

Django REST Framework

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

Тут я бы хотел процитировать слова Тома Кристи, создателя Django REST Framework.

“Неудивительно, что Django REST framework — это API фреймворк для Django. И он пытается заполнить все пробелы в том, как исторически был спроектирован веб-фреймворк Django”.

И действительно, пусть Django был спроектирован давно, он до сих отлично решает свои задачи. Однако с появлением новых требований в веб-разработке, отсутствие компонентов для создания Web API воспринимается как пробел.

Django REST framework способен этот пробел заполнить.

А мы уже заполнили все пробелы в теории и терминологии и готовы перейти к практике!

Что такое Next.js и для чего он нужен?

Итак, что же такое Next.js framework?

Next.js — это фреймворк, основанный на React, который позволяет создавать веб-приложения с улучшенной производительностью и улучшенным пользовательским опытом с помощью дополнительных функций предварительного рендеринга, таких как полноценный рендеринг на стороне сервера (SSR) и статическая генерация страниц (SSG).

Таким образом приложения Next.js используют все преимущества библиотеки React и просто добавляют дополнительные функции:

  • Server Side Rendering. SSR позволяет получать доступ ко всем необходимым данным для построения страницы на сервере. Затем страница полностью отправляется обратно в браузер и сразу же отображается. SSR позволяет веб-страницам загружаться за меньшее время и повышает удобство работы пользователей за счет повышения скорости отклика.

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

  • Тег <head>. Next.js также позволяет вам редактировать тег <head> сайта, что вы не можете сделать в React. Тег <head> является основной частью метаданных веб-страницы и способствует повышению SEO-рейтинга сайта.

Зачем использовать Next.js?

Основное преимущество Next.js — встроенная поддержка SSR для повышения производительности и SEO. Рендеринг на стороне сервера работает путем изменения потока запросов приложения React, так что все компоненты, кроме клиента, отправляют свою информацию на сервер.

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

Плюсы:

  • Приложения Next.js загружаются значительно быстрее, чем приложения React, благодаря встроенному рендерингу на стороне сервера;
  • Поддерживает функции экспорта статических сайтов;
  • Быстрый вход, для тех кто уже работал с библиотекой React.js;
  • Автоматическое разделение кода для страниц;
  • Легко создавать внутренние API-интерфейсы с помощью встроенных маршрутов API и создавать конечные точки API;
  • Встроенная поддержка маршрутизации страниц, CSS, JSX и TypeScript;
  • Быстрое добавление плагинов для настройки Next.js в соответствии с потребностями вашей страницы;
  • Поддерживает такие преимущества React, как интуитивно понятное создание на основе компонентов, интерфейсная система состояний и высокая популярность.

Минусы:

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

Однако возможности Next.js вполне подходят для большинства проектов.

Когда нужно использовать Next.js

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

Пример приложения на Next.js

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

yarn create next-app

Файл index.js, представляет отдельную страницу в этом проекте и выглядит следующим образом:

import Head from 'next/head'
import styles from '. ./styles/Home.module.css'
export default function Home() {
  return (
    <div className={styles.container}>
      <Head>
        <title>Create Next App</title>
        <link rel="icon" href="/favicon.ico" />
      </Head>
      <main className={styles.main}>
        <h2 className={styles.title}>
          Welcome to <a href="https://nextjs.org">Next.js!</a>
        </h2>
        <p className={styles.description}>
          Get started by editing{' '}
          <code className={styles.code}>pages/index.js</code>
        </p>
        <div className={styles.grid}>
          <a href="https://nextjs.org/docs" className={styles.card}>
            <h4>Documentation &rarr;</h4>
            <p>Find in-depth information about Next.js features and API.</p>
          </a>
          <a href="https://nextjs.org/learn" className={styles.card}>
            <h4>Learn &rarr;</h4>
            <p>Learn about Next. js in an interactive course with quizzes!</p>
          </a>
          <a
            href="https://github.com/vercel/next.js/tree/master/examples"
            className={styles.card}
          >
            <h4>Examples &rarr;</h4>
            <p>Discover and deploy boilerplate example Next.js projects.</p>
          </a>
          <a
            href="https://vercel.com/new?utm_source=create-next-app&utm_medium=default-template&utm_campaign=create-next-app"
            className={styles.card}
          >
            <h4>Deploy &rarr;</h4>
            <p>
              Instantly deploy your Next.js site to a public URL with Vercel.
            </p>
          </a>
        </div>
      </main>
      <footer className={styles.footer}>
        <a
          href="https://vercel.com?utm_source=create-next-app&utm_medium=default-template&utm_campaign=create-next-app"
          target="_blank"
          rel="noopener noreferrer"
        >
          Powered by{' '}
          <img src="/vercel. svg" alt="Vercel Logo" className={styles.logo} />
        </a>
      </footer>
    </div>
  )
}

По сути, индексный файл является ядром этого приложения, поскольку каждый файл в каталоге pages является отдельной страницей. Реальные веб-сайты будут содержать несколько страниц в папке pages, которая сопоставляется с соответствующим URL-адресом веб-приложения.

С чего начать в Next.js

Теперь давайте подойдем с практической точки зрения и взглянем на код Next.js. Рассмотрим 5 основных концепций, которые представили нам разработчики фреймворка и которые понадобятся вам для создания собственного проекта на Next.js.

Требования и окружающая среда

Прежде чем мы начнем, давайте настроим все, что вам нужно. Помимо самого фреймворка Next.js. вам потребуются Node.js, npm и npx.

Вы можете установить Node.js с их официального сайта. Чтобы убедиться, что он загружен правильно, введите в командной строке node -v. Обычно npm и npx одновременно устанавливаются при установке Node.js.

Чтобы убедиться, что они установлены правильно, введите в командной строке npm -v и npx -v. Каждый вернет свою версию соответственно.

Если все три инструмента установлены правильно, вы cможете установить Next.js с помощью Node. Введите npm install next react react-dom в командную строку.

После успешной установки вы получите cообщение с вашими текущими версиями Next и React.

$ npm i next react react-dom
added 266 packages, and audited 267 packages in 15s
44 packages are looking for funding
  run `npm fund` for details
found 0 vulnerabilities

Создание приложения на Next.js

Есть два способа создания приложения на Next.js, первый с помощью команды create-next-app или второй — вручную. Использовать create-next-app проще, поскольку все, что вам нужно сделать, это ввести npm create-next-app <app-name> в командную строку. Но ниже мы будем делать это вручную.

Кроме того, вы можете открыть файл package.json и ввести следующие сценарии:

"scripts": {
  "dev": "next dev",
  "start": "next start",
  "build": "next build"
}

Это позволяет запускать новое приложение в разных режимах:

  • dev запускает Next.js в режиме разработки;
  • start запускает Next.js в режиме Production;
  • build собирает ваше приложение Next.js для Production. Независимо от того, какой метод вы выберете, он сгенерирует базовый шаблон приложения Next.js, который мы видели ранее.

Если вы запустите это приложение с помощью next dev и перейдете Next.js по умолчанию на , то увидите примерно следующее:

Как создать структуру дизайна для структурирования вашего проекта

 

Крис Конли

9 августа 2016 г.

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

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

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

Что такое фреймворки и зачем они нужны

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

Зачем это нужно? Разве цель проекта не дает рамки для ее решения?

Одним словом, нет. 🙂

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

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

Мы никогда не знали, как легко нам было!

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

Но бизнес-задачи, направленные на инновации, рост или просто на обслуживание клиентов по-новому, — это коварные проблемы.

Вот почему вам нужна структура.

Проведите исследование, чтобы собрать контент для вашего фреймворка

Фреймворк предоставляет набор идей или фактов для вашего проекта. Но откуда берутся эти идеи и факты?

Они появляются в результате исследования и погружения в проблему. Вот как это сделать:

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

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

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

Итак, каково основное содержание фреймворка? В своей простейшей форме основой структуры является список важных категорий.

Вы создаете категории, анализируя данные, собранные в ходе исследования.

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

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

Проанализировав свое исследование, вы определили «шесть областей неуверенности пациентов после выписки из больницы». К ним относятся:

• Снятие боли
• Прием лекарств
• Координация помощи специалистов
• Возвращение к повседневной жизни
• Финансовые проблемы
• Эмоциональное благополучие

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

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

Организуйте категории визуально в диаграмму

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

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

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

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

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

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

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

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

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

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

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

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

Так что помните, ваша структура должна помочь представить исследование и структуру проекта. И это должно помочь сосредоточиться на решении проблем в конкретных областях.

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

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

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

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

 

Начните сегодня!

Загрузите нашу карточку с практическими рекомендациями по Design Frameworks для справки и поделитесь ею со своей командой.

 

О Крисе Конли

Крис был партнером-основателем Gravitytank, инновационной фирмы, присоединившейся к Salesforce в 2016 году.  Бывший штатный профессор Института дизайна IIT в Чикаго, а теперь он новатор в целом.

4. Разработка схемы или модели изменений

Этот набор инструментов помогает составить представление о пути от действий к намеченным результатам.

  1. Опишите предполагаемое использование вашей структуры или модели изменений:
    1. Чтобы передать цель и направление вашей инициативы или усилия (т. е. ожидаемые результаты и то, как вы их получите)
    2. Чтобы показать, как несколько факторов взаимодействуют, чтобы повлиять на проблему или цель
    3. Для определения действий и вмешательств, которые с большей вероятностью приведут к желаемому результату
       
      Как ваша организация или усилия будут использовать свою структуру или модель изменений?
       
      Связанные ресурсы :
      Разработка логической модели или теории изменений
       
  2. Опишите видение и миссию вашей инициативы или программы:
    1. Видение – кратко изложите свое заявление о мечте вашей инициативы на будущее. Это должно быть:
      1. Легко общаться
      2. Воодушевление/вдохновение для тех, кто участвует в работе
      3. Отражение взглядов сообщества, которое оно представляет
         
        Каково видение вашей группы в отношении усилий?
         
    2. Миссия — укажите миссию вашей группы. Он должен сообщать:
      1. Что собирается делать группа (например, «…подключая и поддерживая детей и заботящихся взрослых».)
      2. Что это будет делать (например, «Поощрять заботливые отношения…»)
         
        Какова миссия вашей группы в связи с этим?
         
        Связанные ресурсы :
        Провозглашение вашей мечты: разработка видения и миссии
         
  3. Укажите цели вашей инициативы или мероприятия:
    1. Обобщите все конкретные измеримые результаты вашей инициативы или программы, которые вы ожидаете. Они должны включать изменения в поведении и соответствующие результаты на уровне сообщества.
    2. Изложите свои предположения и гипотезы относительно личных факторов и факторов окружающей среды, способствующих возникновению проблемы или цели. Откройте для себя их, используя несколько стратегий:
      1. Логика вперед (но почему?) — спросите себя, почему эта проблема существует. Что привело к этому? Что его поддерживает?
      2. Обратная логика (Но как?) — спросите, как можно решить эту проблему или достичь цели?
      3. Определите, какие личные факторы (например, знания, убеждения, навыки) способствуют решению проблемы или достижению цели
      4. Определите факторы окружающей среды (например, поддержку и услуги, доступ, барьеры и возможности, последствия усилий, политику и более широкие условия), которые способствуют возникновению проблемы или достижению цели.
         
        Связанные ресурсы :
        Создание целей
        Сбор и использование индикаторов на уровне сообщества
        Индикаторы на уровне сообщества: некоторые примеры
        Анализ основных проблем проблем: «Но почему?» Техника
        Определение и анализ проблемы
          
  4. Опишите соответствующий масштаб или уровень вашей структуры или модели изменений:
    1. Общая инициатива — может включать все стратегии и отношения, используемые для осуществления изменений и улучшения общей проблемы или цели (например, снижение уровня насилия; способствовать заботливым отношениям)
    2. Конкретная инициатива или программа — может включать только компоненты и элементы конкретного аспекта общих усилий (например, образовательные программы; изменение политики)
    3. Конкретный план действий или модель сотрудничества между заинтересованными сторонами или участвующими агентствами
       
      Какой уровень описывает ваша модель изменений?
       
      Связанные ресурсы :
      Определение действий по изменению сообщества и системы
       
  5. Определите ВСЕ компоненты для включения в логическую модель или модель изменений. Включает:
    1. Цель или миссия – что собирается делать группа и почему
    2. Контекст и условия, в которых существует проблема или цель и которые могут повлиять на результат (например, история усилий, широкие культурные и экологические факторы, политическая ситуация, экономические условия)
    3. Входы — доступные ресурсы и поддержка, а также ограничения или барьеры для достижения целей инициативы
    4. Мероприятия или вмешательства – что делает инициатива или программа, чтобы добиться изменений и улучшений (например, усиление поддержки, изменение доступа)
    5. Выходы – прямые результаты или продукты деятельности группы (например, количество обученных людей или проведенных мероприятий)
    6. Эффекты — более широко измеряемые итоги или результаты (могут включать немедленные, промежуточные и долгосрочные эффекты)
       
      Связанные ресурсы :
      Создание и выбор решений
      Понимание факторов риска и защитных факторов: их использование при выборе потенциальных целей и перспективных стратегий вмешательств
      Провозглашение вашей мечты: разработка видения и заявлений о миссии
      Понимание и описание сообщества
      Определение и анализ проблемы
      Определение активов и ресурсов сообщества
      Определение действий в Осуществление изменения сообщества и системы
      Сбор и использование индикаторов уровня сообщества
      Индикаторы уровня сообщества: некоторые примеры
       
  6. Используя компоненты, нарисуйте схему или модель изменений. Включает:
    1. Ожидаемая временная последовательность (что происходит перед чем) для размещения компонентов и элементов структуры или модели.
    2. Стрелки или другие методы для сообщения направлений влияния и последовательности событий. Некоторые стрелки могут указывать в обоих направлениях, показывая взаимодействие или взаимное влияние.
       
      Связанные ресурсы :
      Разработка логической модели или теории изменений
       
  7. Проверьте полноту вашей логической модели.
    1. Выберите ситуацию (реальную или гипотетическую), в которой вы можете получить обратную связь о вашей логической модели
    2. Проверить полезность элементов модели (например, было ли понятно?)
    3. Проверка полноты модели (например, чего не хватало?)
    4. Пересмотреть и добавить, чтобы сделать его более полным.
       
      Какие исправления вы внесли после проверки полезности модели на конкретном примере?
       
      Связанные ресурсы :
      Разработка логической модели или теории изменений
       
  8. После того, как все текущие компоненты и элементы определены и включены в структуру или логическую модель, приступайте к их использованию. Варианты использования могут включать:
    1. Ориентирование тех, кто выполняет и поддерживает работу — используйте для объяснения того, как элементы инициативы или программы взаимодействуют друг с другом, где участвуют участники и что им нужно, чтобы заставить ее работать.
    2. Планирование — используйте для уточнения стратегии вашей инициативы или программы, определения целей и результатов, подготовки предложения о гранте, определения необходимых партнерских отношений и оценки сроков и необходимых ресурсов для работы.
    3. Внедрение — используйте, чтобы определить, какие элементы у вас есть, а какие нет в вашей инициативе или программе, разработать план управления и внести промежуточные корректировки.
    4. Коммуникация и адвокация – используйте, чтобы объяснить другим, почему инициатива/программа будет работать, и объяснить, как будут использоваться инвестиции.
    5. Оценка — используется для документирования достижений, выявления различий между идеальной программой и действующей в настоящее время, определения показателей, которые будут использоваться для измерения успеха, и постановки вопросов об атрибуции (причины и следствия) и вкладе программы/инициативы в миссию. .
       
      Как бы вы могли применить свою модель изменений в вашей организации или сообществе сейчас? В будущем?
       
      Связанные ресурсы :
      Обеспечение программ ориентации персонала
      Обеспечение программ ориентации волонтеров
      Предоставление поддержки персоналу и волонтерам
       
  9. Пересмотрите модель (по мере необходимости), чтобы адаптировать элементы и включить новые. Использование модели и наблюдение взаимосвязи ее компонентов позволит вам:
    1. Связать путь деятельности с предполагаемыми эффектами или результатами
    2. Планируйте расширение деятельности для достижения ваших целей
    3. Понимание границ вашей программы или инициативы
    4. Скорректировать курс с учетом непредвиденных изменений
    5. Разработать новую структуру для расширенных усилий или новой инициативы
       

Советы по выбору программной среды для вашего стартапа

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

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

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

Прежде чем ответить на этот вопрос, давайте сначала определим, что такое программная среда.

Что такое программная среда?

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

Программные платформы чем-то похожи на интерфейсы прикладного программирования (API) , потому что они упрощают разработку приложений. Фреймворк обеспечивает основу для программирования. С другой стороны, API позволяет получить доступ к элементам, поддерживаемым фреймворком.
Кроме того, фреймворки часто имеют открытый исходный код. Они протестированы и оптимизированы несколькими опытными разработчиками программного обеспечения. Это делает программные среды очень универсальными и эффективными.

Платформы программного обеспечения предоставляют множество преимуществ команде разработчиков , например:

  1. Уменьшить или устранить избыточность и дублирование кода.
  2. Платформы обеспечивают лучшую безопасность кода.
  3. Помогает улучшить согласованность разработки кода.
  4. Уменьшить количество ошибок.
  5. Предварительно протестированные коды и функции повышают надежность.
  6. Более простые процессы тестирования и отладки.
  7. Значительно сокращает сроки разработки приложений.
  8. Помогает в создании лучших методов разработки и программирования.

Критерии выбора программной платформы

Нет сомнений в том, что программные среды предлагают множество преимуществ. Существуют фреймворки, соответствующие вашим потребностям, независимо от того, работаете ли вы над мобильным приложением, веб-сайтом или управлением базой данных. Some of the most popular software frameworks are:

  • Angular
  • React
  • Vue
  • Svelte
  • Ember
  • Django
  • Laravel
  • Apache Spark
  • Ionic
  • PyTorch
  • Flutter

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

Сообщество

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

Устойчивое развитие

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

Поддержка

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

Безопасность

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

Документация

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

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

Опыт и навыки команды

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

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

Бизнес-стратегия

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

Например, изначально Twitter был на Ruby on Rails (RoR). Тем не менее, бизнес увидел необходимость улучшить свои функции поиска. Понимая потребности своего бизнеса, Twitter перенес части своего стека на Java и Scala , тем самым решив насущную проблему.

Конечные пользователи

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

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

No related posts.