Как проектировать веб-API: 7 самых важных вопросов

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

Читать статью

​​Алоха, друзья! Сегодня мы поговорим о двух парнях - SOAP 🙋🏻и REST 🙋🏼‍♂️. Постараюсь рассказать простыми словами о них, чтобы было всем понятно, кто же эти парни))

👉🏻SOAP - мужик, который любит все делать в порядке. Он очень правильный и точный, всегда следует стандартам и правилам. Это тот чел, который всю жизнь работал в банке и никогда не опаздывал на работу. SOAP использует подход "запрос-ответ", что означает, что если вы что-то запросили, то вам обязательно придет ответ. SOAP считает, что порядок и правильность - это главное. Но, конечно, это может занять некоторое время.

👉🏻 А вот REST - это совсем другой тип. Он далек от стандартов и может быть очень неформальным. Это парень, который любит свободу и самостоятельность, он не любит ограничений и правил. REST использует подход "совместное использование ресурсов", что означает, что данные хранятся в одном месте и могут быть получены множеством клиентов одновременно. REST всегда готов к действию, главное - быстро и качественно.

Итак, какое же отличие между этими двумя парнями; спросите вы?
- SOAP может быть довольно медленным, потому что он всегда следует стандартам и держится правил, но все же он очень аккуратный.
- REST же быстр и готов к действию, он не признает границ и может работать с многими клиентами одновременно.

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

Источник: @ba_and_sa
#API #REST #SOAP

📎Ну а для углубления в тему предлагаю вам несколько статей:
- Применение SOAP при интеграции систем
- Everything about SOAP, REST, and Message Brokers


Всем удачи в выборе своего SOAP или REST!

​​Алоха, друзья! Сегодня продолжаем разбирать вопросы, которые любят задавать на собеседовании на роль BA/SA и затронем тему архитектуры:

#вопросыссобеседования

Часть 8:

📍Вопрос 1: Что такое архитектура программного обеспечения (ПО)?

✅Краткий ответ:
Архитектура программного обеспечения (ПО) - это структура и организация системы, которая определяет ее компоненты, взаимодействия между ними и их отношения с внешней средой. Также можно сказать, что Архитектура представляет собой основу для дальнейшей разработки ПО, определяет его функциональность, надежность, масштабируемость, производительность и возможности расширения.

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

Более подробно расскажу в следующий раз))

📎Материалы по теме:
- Разработка архитектуры для чайников. Часть 1 / Часть 2
- Архитектура ПО: разница между архитектурой и проктированием

📍Вопрос 2: Что такое микросервисная, монолитная и клиент-сервисная архитектура? В чем разница между ними?

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

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

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

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

📎Материалы по теме:
- Сравнение микросервисной и монолитной архитектур
- Микросервисы или монолит. Какую архитектуру выбрать при разработке сложного приложения для крупного бизнеса
- Клиент-серверная архитектура в картинках

📍Вопрос 3: Какие вы знаете виды и способы интеграции систем?

✅ Краткий ответ:
Существует несколько видов интеграций систем, в том числе:

1. Интеграция API (Application Programming Interface) - это способ связывания различных программных приложений через их программные интерфейсы.
2. Интеграция через файловые форматы - это способ интеграции, основанный на конвертировании файлов в разные форматы для обмена информацией между ПО.
3. Интеграция баз данных - это способ обмена информацией между различными базами данных на основе протоколов обмена.
4. Интеграция с помощью платформы - это способ связывания различных приложений через одну платформу.

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

📎Материалы по теме:
- Видео - Способы интеграции систем


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

Источник: @ba_and_sa
#собеседование

‼️Предыдущие части смотрите по #собеседование #вопросыссобеседования

p.s.Делитесь своими мыслями в комментариях и напишите, какие вопросы были у вас на собесах

Ой, да мы и без документации, на изи, эту таску затащим

​​Алоха! Сегодня мы поговорим о такой важной теме, как архитектура ПО.

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

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

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

Также не стоит забывать, что есть разные способы создания архитектуры ПО, и каждый выбирает ее сам. Например, кто-то разделяет свою программу на три компонента - "ядро", "косточки" и "внешность", т.е. создает Model-View-Controller (MVC). А кто-то делает все в виде множества "скромных сервисов", каждый сам по себе ("микросервисная архитектура"), чтобы каждый мог потом по отдельности танцевать с табуреткой.

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

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

Источник: @ba_and_sa

Требования к информационной безопасности: кого вовлекать в выявление?

Риск-ориентированный подход. Этапы и особенности выявления требований кибербезопасности. Матрица ответственности за выявление рисков ИБ и согласование требований.

Перейти с статье

Смотреть видео

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

❗️Во-первых, плюсов здесь немало. Микс знаний и компетенций бизнес-аналитика и тестировщика позволяет получать более точные результаты и выявлять более точные недочеты в работе.
К тому же, если бизнес-аналитик и тестировщик работают в одной команде, это значительно экономит время и снижает риски получения неверных результатов.

❗️Тем не менее, есть и некоторые минусы. Как известно, каждый из этих специалистов имеет свой набор задач и целей на проекте. Это может привести к тому, что у них будут разные представления о том, какие процессы или продукты важны, и потенциально даже к конфликтам.

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

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

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

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

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

Таким образом, понимание задач и обязанностей друг друга поможет бизнес-аналитику и тестировщику работать слаженно и совместно достигать общей цели - создание качественного продукта.❗️❗️

Алоха! Добавила на канал теги для удобного поиска моих постов с разными рубриками (они будут обновляться и добавляться):

📌#профлитература
📌#вопросыссобеседования
📌#моделированиеПО
📌#программы #сервисы
📌#сбортребований
📌#api #rest #soap #интеграция
📌#жизненныйцикл
📌#дорожнаякарта
📌#БД #базыданных
📌#случайизжизни
📌#карьерныйпуть
📌#вопросотподписчика
📌#расширяемкругозор
📌#развитие
📌#повышениеквалификации