Сколько конечных точек в SOAP?
Anonymous Quiz
55%
Одна
8%
Нисколько
37%
Сколько угодно: на каждый ресурс своя конечная точка
👎1
4 шага как «раскопать» систему
1️⃣ Собери всё, что есть
В идеале документацияможет должна содержать:
1. описание потребности в этой функциональности (просто текстом, таблички, какие-то схемы в любой нотации);
2. описание фронта: поведение элементов, workflow пользователя;
3. описание бэка: внутренние сервисы, описание бд и компонентов;
4. описание интеграционных сервисов, включая примеры запросов и ответов, статусы ответов.
5. Требования к функциональности
6. Запротоколированные договоренности, в которых можно проследить какие-то несделанные пожелания
7. Требования регулирующих органов (если влияют напрямую)
8. Руководство пользователя/инструкции
2️⃣ Протыкать ручками (если есть возможность). Просто садишься и начинаешь тыкать везде и смотреть как реагирует система. При этом фиксируешь поведение, а сомнительные моменты отмечаешь для уточнения у носителей неявных знаний
3️⃣ Задай вопросы
Выясняешь у начальника (линейного, руководителя проекта, лида и прочее — нужное подчеркнуть), кто может проконсультировать по вопросам. Готовишь список вопросов. Задаёшь, конспектируешь ответ. Идёшь пропускать все это через себя.
4️⃣ Оформи то, что получил
Оформляешь полученную информацию в установленном порядке в своей фирме. Это может быть актуализация документов, или формирование базы знаний в конфлюенсе, может быть даже обновление родительских тикетов в таск-трекере — в общем удобное для вас место.
Задача аналитика — оставить после себя структурированную информацию. Оставить — это значит оформить и выложить в общедоступное место. А не разобраться, как школьник с новыми знаниями, и оставить их при себе. Структурированная информация — это значит разложить по полочкам все то, что до тебя плохо лежало.
Оригинал
#требования
1️⃣ Собери всё, что есть
В идеале документация
1. описание потребности в этой функциональности (просто текстом, таблички, какие-то схемы в любой нотации);
2. описание фронта: поведение элементов, workflow пользователя;
3. описание бэка: внутренние сервисы, описание бд и компонентов;
4. описание интеграционных сервисов, включая примеры запросов и ответов, статусы ответов.
5. Требования к функциональности
6. Запротоколированные договоренности, в которых можно проследить какие-то несделанные пожелания
7. Требования регулирующих органов (если влияют напрямую)
8. Руководство пользователя/инструкции
2️⃣ Протыкать ручками (если есть возможность). Просто садишься и начинаешь тыкать везде и смотреть как реагирует система. При этом фиксируешь поведение, а сомнительные моменты отмечаешь для уточнения у носителей неявных знаний
3️⃣ Задай вопросы
Выясняешь у начальника (линейного, руководителя проекта, лида и прочее — нужное подчеркнуть), кто может проконсультировать по вопросам. Готовишь список вопросов. Задаёшь, конспектируешь ответ. Идёшь пропускать все это через себя.
4️⃣ Оформи то, что получил
Оформляешь полученную информацию в установленном порядке в своей фирме. Это может быть актуализация документов, или формирование базы знаний в конфлюенсе, может быть даже обновление родительских тикетов в таск-трекере — в общем удобное для вас место.
Задача аналитика — оставить после себя структурированную информацию. Оставить — это значит оформить и выложить в общедоступное место. А не разобраться, как школьник с новыми знаниями, и оставить их при себе. Структурированная информация — это значит разложить по полочкам все то, что до тебя плохо лежало.
Оригинал
#требования
👍7🔥3❤1👎1🤔1
Чек-лист хороших требований
✅ Полнота. Все ли описано? Ничего не забыли? Вдруг у нас остался неописанный функционал или параметр API-метода? Чтобы проверить этот пункт, просто напишите чек-лист проверок функционала. Вот как начали читать ТЗ, сразу записывайте тесты. Важно именно писать, а не просто прикидывать в уме. Иначе что-то обязательно забудете.
✅ Однозначность. Требования должны трактоваться всеми одинаково.
Отчет должен загружаться быстро. Отчет за год должен загружаться не более секунды.
✅ Непротиворечивость. Требования не должны противоречить сами себе
Необходимость. Помните главный принцип: «Кратко, но емко». Пишите только то, что необходимо: функционал, основной сценарий и альтернативы, типы ошибок.
✅ Осуществимость. А можно ли реализовать то, что тут написано? Насколько это будет сложно и дорого?
✅ Тестируемость. Можно ли протестировать этот функционал? Подумайте об этом заранее. А то бывает так, что разработчик уже всё сделал, и тут только тестировщик понимает, что задачу никак нельзя проверить
✅ Атомарность. Не может быть разбито на ряд более детальных требований
Подробнее – см. свойства качественных требований
#требования
✅ Полнота. Все ли описано? Ничего не забыли? Вдруг у нас остался неописанный функционал или параметр API-метода? Чтобы проверить этот пункт, просто напишите чек-лист проверок функционала. Вот как начали читать ТЗ, сразу записывайте тесты. Важно именно писать, а не просто прикидывать в уме. Иначе что-то обязательно забудете.
✅ Однозначность. Требования должны трактоваться всеми одинаково.
✅ Непротиворечивость. Требования не должны противоречить сами себе
Необходимость. Помните главный принцип: «Кратко, но емко». Пишите только то, что необходимо: функционал, основной сценарий и альтернативы, типы ошибок.
✅ Осуществимость. А можно ли реализовать то, что тут написано? Насколько это будет сложно и дорого?
✅ Тестируемость. Можно ли протестировать этот функционал? Подумайте об этом заранее. А то бывает так, что разработчик уже всё сделал, и тут только тестировщик понимает, что задачу никак нельзя проверить
✅ Атомарность. Не может быть разбито на ряд более детальных требований
Подробнее – см. свойства качественных требований
#требования
Telegraph
Свойства качественных требований
В процессе тестирования требований проверяется их соответствие определённому набору свойств. 💡Завершённость (completeness). Требование является полным и законченным с точки зрения представления в нём всей необходимой информации, ничто не пропущено по соображениям…
🔥8
Пиши_Сокращай_Как_составлять_сильный_текст.pdf
12.9 MB
Чётко и ясно излагать мысли — один из главных навыков системного аналитика. И этот навык можно прокачать. А помочь в этом может книга от создателей сервиса glvrd.ru «Пиши, сокращай» М. Ильяхова и Л. Сарычевой
👍7🤔1
Открытый курс по документированию API
Позволяет узнать:
1. стандарты, инструменты и спецификации REST API
2. необходимые разделы в документации API
3. как присоединиться к опен-сорс проекту для получения опыта
4. Как использовать Postman и составлять запросы curl
5. как составлять спецификацию OpenAPI и Swagger
#интеграции #api
Позволяет узнать:
1. стандарты, инструменты и спецификации REST API
2. необходимые разделы в документации API
3. как присоединиться к опен-сорс проекту для получения опыта
4. Как использовать Postman и составлять запросы curl
5. как составлять спецификацию OpenAPI и Swagger
#интеграции #api
👍9❤1🤔1
Как выбрать технологию для интеграции, реализовать и не сойти с ума — доклад с Analyst Days 15
Анастасии Воробьевой, интеграционного аналитика из Райфа
#интеграции #api #архитектура
Анастасии Воробьевой, интеграционного аналитика из Райфа
#интеграции #api #архитектура
analystdays.ru
Как выбрать технологию для интеграции и не ошибиться?
Наверняка многие из вас сталкивались с ситуацией, когда нужно связать свою систему с другой удаленной системой, чтобы получить данные, необходимые для ваших процессов, например, данные о клиенте, или чтобы инициировать бизнес-процесс в другой системе, например…
🔥6
Создание микросервисов.pdf
13.2 MB
🔥Книга «Создание микросервисов, 2-е издание» за авторством Ньюмена Сэма.
Второе дополненное издание предлагает целостный взгляд на самые актуальные темы, в которых необходимо разбираться при создании и масштабировании архитектуры микросервисов, а также управлении ею.
Вы познакомитесь с современными решениями для моделирования, интеграции, тестирования, развертывания и мониторинга собственных автономных сервисов
#архитектура
Второе дополненное издание предлагает целостный взгляд на самые актуальные темы, в которых необходимо разбираться при создании и масштабировании архитектуры микросервисов, а также управлении ею.
Вы познакомитесь с современными решениями для моделирования, интеграции, тестирования, развертывания и мониторинга собственных автономных сервисов
#архитектура
👍5❤1
Graphana vs Kibana — в чём разница?
Кратко: Kibana — анализ логов и запросов, Graphana — визуализация и мониторинг нагрузки.
Подробнее. Оба инструмента с открытым исходным кодом, используются для анализа больших объёмов данных от разных систем. Хотя системы имеют созвучное название, они, как правило, используются в разных кейсах.
Graphana — система для визуализации и мониторинга временных рядов данных. Graphana позволяет создавать красивые и интерактивные дашборды, которые отображают данные из разных источников, таких как базы данных, API, файлы и т.д.
Какие задачи решает Graphana:
1️⃣ Расчёт нефункциональных требований (RPS, response time) для микросервисов
2️⃣ Мониторинг состояния и ресурсов серверов и приложений. Graphana позволяет отображать и анализировать различные метрики, связанные с работой серверов и приложений, такие как загрузка CPU, использование памяти, дисковое пространство
3️⃣ Визуализация данных из разных источников. Graphana поддерживает множество баз данных и API, которые могут быть использованы для получения и отображения данных в разных форматах
Kibana — система для поиска, анализа и визуализации данных, хранящихся в Elasticsearch. Собственно, это буква K в знаменитой ELK. Kibana позволяет использовать огромное число фильтров и поддерживает сложный поисковые (KQL) запросы для анализа логов и событий.
Какие задачи решает Kibana
1️⃣ Анализ логов запросов по определённому методу API. Kibana позволяет извлекать и анализировать данные из логов, хранящихся в Elasticsearch. Например, можно построить график распределения запросов по методам API, фильтровать по статусу ответа, времени выполнения, IP-адресу и другим параметрам
2️⃣ Визуализация данных из разных источников различными способами, используя диаграммы, таблицы, географические карты и другие типы визуализаций.
📎 Материалы
1. Руководство пользователя Kibana (ENG, RUS)
2. Видео по Кибане
3. Официальная документация Graphana
4.Обзорная статья о Graphana
#инструменты
Кратко: Kibana — анализ логов и запросов, Graphana — визуализация и мониторинг нагрузки.
Подробнее. Оба инструмента с открытым исходным кодом, используются для анализа больших объёмов данных от разных систем. Хотя системы имеют созвучное название, они, как правило, используются в разных кейсах.
Graphana — система для визуализации и мониторинга временных рядов данных. Graphana позволяет создавать красивые и интерактивные дашборды, которые отображают данные из разных источников, таких как базы данных, API, файлы и т.д.
Какие задачи решает Graphana:
1️⃣ Расчёт нефункциональных требований (RPS, response time) для микросервисов
2️⃣ Мониторинг состояния и ресурсов серверов и приложений. Graphana позволяет отображать и анализировать различные метрики, связанные с работой серверов и приложений, такие как загрузка CPU, использование памяти, дисковое пространство
3️⃣ Визуализация данных из разных источников. Graphana поддерживает множество баз данных и API, которые могут быть использованы для получения и отображения данных в разных форматах
Kibana — система для поиска, анализа и визуализации данных, хранящихся в Elasticsearch. Собственно, это буква K в знаменитой ELK. Kibana позволяет использовать огромное число фильтров и поддерживает сложный поисковые (KQL) запросы для анализа логов и событий.
Какие задачи решает Kibana
1️⃣ Анализ логов запросов по определённому методу API. Kibana позволяет извлекать и анализировать данные из логов, хранящихся в Elasticsearch. Например, можно построить график распределения запросов по методам API, фильтровать по статусу ответа, времени выполнения, IP-адресу и другим параметрам
2️⃣ Визуализация данных из разных источников различными способами, используя диаграммы, таблицы, географические карты и другие типы визуализаций.
📎 Материалы
1. Руководство пользователя Kibana (ENG, RUS)
2. Видео по Кибане
3. Официальная документация Graphana
4.Обзорная статья о Graphana
#инструменты
👍8🤔1
🚫Типовые ошибки младшего системного аналитика
Всем привет! Сегодня мы рассмотрим, какие ошибки совершает джун-аналитик Вася в процессе своей работы.
1️⃣ Пишет ТЗ в художественном стиле. Вася только недавно закончил вуз, где он прекрасно научился лить воду. Тексты Васи, как и он сам, на 80% состоят из воды, а разработчики не могут понять, о чём ТЗ в принципе. Пример: “В случае недоступности системы платежей, к которой посредством использования интерфейса API данный сервис отправляет данные, полученные из запроса от клиента шагом ранее, сервису обязательно необходимо передать полученные данные в очередь сообщений Kafka”
2️⃣ Плодит сущности. Ещё в вузе Вася хорошо научился обходить антиплагиат посредством подбора синонимов. И пытается улучшить своё красноречие обилием разных названий одной и той же сущности. Например, в одной части ТЗ использует термин “абонент”, в другой “клиент”, в третьей “пользователь”. Разработчикам остаётся только гадать, сколько на самом деле сущностей скрыто за этими синонимами
3️⃣ Прописывает в ТЗ очевидные требования. Вася пока ещё страдает тягой к излишней дететализации. Например, он пишет "Отчет должен формироваться по нажатию на кнопку “построить отчет”". Ладно, если бы это просто нагромождало ТЗ (отсылка к 1 пункту), так разработчик Георгий может принять такие требования как личное оскорбление.
4️⃣ Боится показаться глупым. Когда Вася получает задачу от старшего коллеги, он стесняется задавать глупые вопросы. В итоге Вася неправильно понимает постановку задачи и в лучшем случае теряет время впустую, пока его старший коллега не заметит косяк. Короче, Вася любит создавать себе сложности
5️⃣ Считает, что документация в конфлюэнсе всегда актуальная. Вася не успел окончательно разочароваться в людях, поэтому смело опирается на документацию. И вот, через неделю он показывает своё ТЗ коллеге: увы, придётся переделавать, так как эта система уже месяц как не используется, просто не обновили страничку…
6️⃣ Не фиксирует договорённости. Обсудив с заказчиком изменения требований в зуме, Вася никак не фиксирует, что такое-то требование было изменено и молча вносит правки в ТЗ. Через два месяца на Васю падает баг – изменения в требованиях оказались несовместимы с legacy бизнес-правилами в системе, о которых уже все забыли. Виноватым оказался конечно Вася, так как заказчик не помнит, что сам изменял требования.
7️⃣ Занимается улучшайзингом. Как истинный перфекционист, Вася не может позволить себе лишний пробел или не удалить ту самую точку на конце нумерованного списка, которая выпадает из общего ряда. А ещё однажды Вася, уже немного прокачавшись, получает задачу на небольшую доработку одного метода и решает переписать всё ТЗ целиком, так как текущие формулировки показались ему недостаточно прозрачными. От таких фокусов разработчик начал ругаться, мол, почему я должен переписывать метод заново, если мне нужно добавить всего один параметр. А ведь Вася ещё не понял, что он никогда не докажет разработчику, что это всего лишь уточнение формулировок в ТЗ без изменения логики работы метода…
А какие ошибки допускали вы? Делитесь в комментариях под постом 👇
P.S. Вася, прости
#развитие
Всем привет! Сегодня мы рассмотрим, какие ошибки совершает джун-аналитик Вася в процессе своей работы.
1️⃣ Пишет ТЗ в художественном стиле. Вася только недавно закончил вуз, где он прекрасно научился лить воду. Тексты Васи, как и он сам, на 80% состоят из воды, а разработчики не могут понять, о чём ТЗ в принципе. Пример: “В случае недоступности системы платежей, к которой посредством использования интерфейса API данный сервис отправляет данные, полученные из запроса от клиента шагом ранее, сервису обязательно необходимо передать полученные данные в очередь сообщений Kafka”
2️⃣ Плодит сущности. Ещё в вузе Вася хорошо научился обходить антиплагиат посредством подбора синонимов. И пытается улучшить своё красноречие обилием разных названий одной и той же сущности. Например, в одной части ТЗ использует термин “абонент”, в другой “клиент”, в третьей “пользователь”. Разработчикам остаётся только гадать, сколько на самом деле сущностей скрыто за этими синонимами
3️⃣ Прописывает в ТЗ очевидные требования. Вася пока ещё страдает тягой к излишней дететализации. Например, он пишет "Отчет должен формироваться по нажатию на кнопку “построить отчет”". Ладно, если бы это просто нагромождало ТЗ (отсылка к 1 пункту), так разработчик Георгий может принять такие требования как личное оскорбление.
4️⃣ Боится показаться глупым. Когда Вася получает задачу от старшего коллеги, он стесняется задавать глупые вопросы. В итоге Вася неправильно понимает постановку задачи и в лучшем случае теряет время впустую, пока его старший коллега не заметит косяк. Короче, Вася любит создавать себе сложности
5️⃣ Считает, что документация в конфлюэнсе всегда актуальная. Вася не успел окончательно разочароваться в людях, поэтому смело опирается на документацию. И вот, через неделю он показывает своё ТЗ коллеге: увы, придётся переделавать, так как эта система уже месяц как не используется, просто не обновили страничку…
6️⃣ Не фиксирует договорённости. Обсудив с заказчиком изменения требований в зуме, Вася никак не фиксирует, что такое-то требование было изменено и молча вносит правки в ТЗ. Через два месяца на Васю падает баг – изменения в требованиях оказались несовместимы с legacy бизнес-правилами в системе, о которых уже все забыли. Виноватым оказался конечно Вася, так как заказчик не помнит, что сам изменял требования.
7️⃣ Занимается улучшайзингом. Как истинный перфекционист, Вася не может позволить себе лишний пробел или не удалить ту самую точку на конце нумерованного списка, которая выпадает из общего ряда. А ещё однажды Вася, уже немного прокачавшись, получает задачу на небольшую доработку одного метода и решает переписать всё ТЗ целиком, так как текущие формулировки показались ему недостаточно прозрачными. От таких фокусов разработчик начал ругаться, мол, почему я должен переписывать метод заново, если мне нужно добавить всего один параметр. А ведь Вася ещё не понял, что он никогда не докажет разработчику, что это всего лишь уточнение формулировок в ТЗ без изменения логики работы метода…
А какие ошибки допускали вы? Делитесь в комментариях под постом 👇
P.S. Вася, прости
#развитие
🔥8❤3👎2😁2👍1👏1🤔1
SOA vs MSA: чем отличается микросервисная архитектура от сервисно-ориентированной?
Кратко. SOA использует ESB – единую интеграционную шину, все системы общаются только с ней, а та, как посредник, передаёт сообщения от одной системы к другой. В MSA сервисы общаются напрямую, отсутствует единая точка отказа, как ESB в SOA.
В SOA сервисы – это кирпичики, из которых собираются более крупные – максимальное переиспользование логики. В MSA микросервисы не зависят друг от друга и имеют ограниченный контекст
Подробнее
1️⃣ Внесение изменений
В SOA для внесения одного изменения требуется изменения сразу в нескольких сервисах. Так как отдельными сервисами владеют разные команды, то внесение элементарных изменений превращается в сущий ад из бесконечных совещаний, согласований и документов.
В MSA зависимости от других сервисов отсутствуют либо минимальны, то необходимость взаимодействия с другими сервисами и командами пропадает. Внесение изменений осуществляется командой, которая владеет сервисом/
2️⃣ Переиспользование
В SOA стремится переиспользованию. Разработчики часто тратят много времени, пытаясь интегрировать повторно используемые сервисы, которые потом мало используются повторно
В MSA избегают повторного использования: дублирование логики лучше зависимости от других сервисов. Повторное использование предполагает связанность, а архитектура микросервисов старается ее избегать. Это достигается за счет разбиения системы на сервисы по ограниченным контекстам (бизнес областям)
3️⃣ Команды
В SOA команды разделены так же, как архитектура. Требуются колоссальные усилия координации для простых изменений.
В MSA команда кроссфункциональна, то есть включает в себя всех специалистов, необходимых для развития сервиса. Так как сервис реализует процесс от и до, то команда владеет процессом от начала до конца. Как следствие они отвечают за процесс целиком
4️⃣ Взаимодействие
В SOA взаимодействие осуществляется через корпоративную шину. Если в ней со временем появляется много логики, то она легко становится бутылочным горлышком.
В MSA Каждый сервис обладает всеми частями своего ограниченного контекста и осуществляет связь с другими ограниченными контекстами с помощью обмена данными, используя брокер сообщений. Просто обмен, никакой сложной логики.
5️⃣ Автоматизация и развертывание
SOA состоит из множества развертываемых модулей, что затрудняет процесс автоматизации и координации
В MSA каждый cервис может быть развернут независимо от других сервисов (и другой инфраструктуры), что отражает ограниченный контекст
6️⃣ Тестирование
В SOA ни одна из частей архитектуры не является завершенной — все они являются частью более крупного рабочего потока и обычно не предназначены для изолированного тестирования
В MSA каждый сервис имеет хорошо определенную границу и минимум зависимостей, это позволяет легко тестировать сервис в изоляции от других частей системы
📎 Материалы
1. SOA vs MSA
2. Microservices Architecture – SOA and MSA
3. Как и зачем переходить от сервис-ориентированной архитектуры к микросервисам
4. ▶️ Различия SOA и микросервисной архитектуры за 9 минут
#архитектура #сравнение
Кратко. SOA использует ESB – единую интеграционную шину, все системы общаются только с ней, а та, как посредник, передаёт сообщения от одной системы к другой. В MSA сервисы общаются напрямую, отсутствует единая точка отказа, как ESB в SOA.
В SOA сервисы – это кирпичики, из которых собираются более крупные – максимальное переиспользование логики. В MSA микросервисы не зависят друг от друга и имеют ограниченный контекст
Подробнее
1️⃣ Внесение изменений
В SOA для внесения одного изменения требуется изменения сразу в нескольких сервисах. Так как отдельными сервисами владеют разные команды, то внесение элементарных изменений превращается в сущий ад из бесконечных совещаний, согласований и документов.
В MSA зависимости от других сервисов отсутствуют либо минимальны, то необходимость взаимодействия с другими сервисами и командами пропадает. Внесение изменений осуществляется командой, которая владеет сервисом/
2️⃣ Переиспользование
В SOA стремится переиспользованию. Разработчики часто тратят много времени, пытаясь интегрировать повторно используемые сервисы, которые потом мало используются повторно
В MSA избегают повторного использования: дублирование логики лучше зависимости от других сервисов. Повторное использование предполагает связанность, а архитектура микросервисов старается ее избегать. Это достигается за счет разбиения системы на сервисы по ограниченным контекстам (бизнес областям)
3️⃣ Команды
В SOA команды разделены так же, как архитектура. Требуются колоссальные усилия координации для простых изменений.
В MSA команда кроссфункциональна, то есть включает в себя всех специалистов, необходимых для развития сервиса. Так как сервис реализует процесс от и до, то команда владеет процессом от начала до конца. Как следствие они отвечают за процесс целиком
4️⃣ Взаимодействие
В SOA взаимодействие осуществляется через корпоративную шину. Если в ней со временем появляется много логики, то она легко становится бутылочным горлышком.
В MSA Каждый сервис обладает всеми частями своего ограниченного контекста и осуществляет связь с другими ограниченными контекстами с помощью обмена данными, используя брокер сообщений. Просто обмен, никакой сложной логики.
5️⃣ Автоматизация и развертывание
SOA состоит из множества развертываемых модулей, что затрудняет процесс автоматизации и координации
В MSA каждый cервис может быть развернут независимо от других сервисов (и другой инфраструктуры), что отражает ограниченный контекст
6️⃣ Тестирование
В SOA ни одна из частей архитектуры не является завершенной — все они являются частью более крупного рабочего потока и обычно не предназначены для изолированного тестирования
В MSA каждый сервис имеет хорошо определенную границу и минимум зависимостей, это позволяет легко тестировать сервис в изоляции от других частей системы
📎 Материалы
1. SOA vs MSA
2. Microservices Architecture – SOA and MSA
3. Как и зачем переходить от сервис-ориентированной архитектуры к микросервисам
4. ▶️ Различия SOA и микросервисной архитектуры за 9 минут
#архитектура #сравнение
❤10👍5👏3
Паттерны декомпозиции User Story / задач
1. Разделение на «Проще-сложнее»
2. Разделение по бизнес-правилам
3. Разделение по способу ввода/вывода данных
4. Разделение по вариантивности данных
5. Разделение по операциям
6. По шагам workflow
7. Выделение основного усилия
8. Разделение по наращиванию функционала
9. Исследование-разработка (спайки)
📎 Ещё статьи по теме в этом посте
#требования
1. Разделение на «Проще-сложнее»
2. Разделение по бизнес-правилам
3. Разделение по способу ввода/вывода данных
4. Разделение по вариантивности данных
5. Разделение по операциям
6. По шагам workflow
7. Выделение основного усилия
8. Разделение по наращиванию функционала
9. Исследование-разработка (спайки)
📎 Ещё статьи по теме в этом посте
#требования
Telegraph
Паттерны декомпозиции User Story / задач
Иногда продуктовые команды пренебрегают декомпозицией задач, которые попадают в их бэклог. Слишком большую пользовательскую историю часто вообще не удается оценить по сложности, потому что она не является достаточно понятным и прозрачным элементом бэклога.…
🔥3😢1
Кэширование — разбор по полочкам
🔹Кэширование – способ способов оптимизации приложений, при котором результаты выполнения операций сохраняются на некоторое время
🔹Кэширование позволяет ускорить время отклика системы и повысить устойчивость к увеличению нагрузки (росту RPS)
🔹Главный принцип работы с кэшем: если вы можете обойтись без кэширования, то именно так и сделайте
Как работает кэширование?
Логически кэш представляет из себя базу типа ключ-значение. Каждая запись в кэше имеет “время жизни”, по истечении которого она удаляется. Это время называют термином Time To Live или TTL. Размер кэша гораздо меньше, чем у основного хранилища, но этот недостаток компенсируется высокой скоростью доступа к данным. Это достигается за счет размещения кэша в быстродействующей памяти ОЗУ (RAM). Поэтому обычно кэш содержит самые “горячие” данные.
Процесс 1. Когда данные в кэше отсутствуют
1️⃣ Пользователь запрашивает некие данные
2️⃣ Кэш приложения ПУСТ, поэтому приложение обращается к базе данных (БД)
3️⃣ БД возвращает запрошенные данные приложению
4️⃣ Приложение сохраняет полученные данные в кэше
5️⃣ Пользователь получает данные
Процесс 2. В кэше есть данные
1️⃣ Пользователь запрашивает данные
2️⃣Приложение уже имеет эти данные в кэше (ведь они были записаны туда при первом обращении) и поэтому НЕ ОБРАЩАЕТСЯ за ними к БД
3️⃣Пользователь получает данные
Стратегии инвалидации кэша
➖ Инвалидация по TTL.
TTL (Time To Live) – время жизни данных в кэше. При сохранении данных в кэш для них устанавливается TTL и данные будут обновляться с периодичностью не менее TTL.
➖ Инвалидация по событию
При таком подходе данные инвалидируют при наступлении некоего события – обычно это обновление данных в источнике
Стратегии вытеснения
🔸LRU (Least Recently Used) – стратегия вытеснения, которая опирается на время последнего использования записи. Она удаляет записи, у которых время последнего использования старше остальных. Таким образом, в кэше остаются записи, которые использовались недавно. Эта стратегия опирается уже не на случай, а на паттерн использования данных, поэтому она гораздо эффективнее предыдущих.
🔸LFU (Least Frequently Used) – стратегия вытеснения, опирающаяся на частоту использования записи. Она удаляет записи, которые использовались реже всего. Так в кэше остаются данные, которые использовались чаще других. Эта стратегия тоже опирается не на случай, а на паттерн использования данных, поэтому она тоже эффективнее остальных и является альтернативой LRU.
Полную версию читайте на Хабре.
📎 Полезные ссылки
1. О стратегиях вытеснения на примере инструментов redis
2. Трудности и стратегии кэширования на сайте Amazon
3. Основы кэширования от Amazon
4. Базовый “ликбез” и ссылки на первоисточники от Wikipedia
#архитектура
➿ ➿ ➿ ➿ ➿ ➿ ➿ ➿
🧑🎓 Больше полезного в базе знаний по системному анализу
🔹Кэширование – способ способов оптимизации приложений, при котором результаты выполнения операций сохраняются на некоторое время
🔹Кэширование позволяет ускорить время отклика системы и повысить устойчивость к увеличению нагрузки (росту RPS)
🔹Главный принцип работы с кэшем: если вы можете обойтись без кэширования, то именно так и сделайте
Как работает кэширование?
Логически кэш представляет из себя базу типа ключ-значение. Каждая запись в кэше имеет “время жизни”, по истечении которого она удаляется. Это время называют термином Time To Live или TTL. Размер кэша гораздо меньше, чем у основного хранилища, но этот недостаток компенсируется высокой скоростью доступа к данным. Это достигается за счет размещения кэша в быстродействующей памяти ОЗУ (RAM). Поэтому обычно кэш содержит самые “горячие” данные.
Процесс 1. Когда данные в кэше отсутствуют
1️⃣ Пользователь запрашивает некие данные
2️⃣ Кэш приложения ПУСТ, поэтому приложение обращается к базе данных (БД)
3️⃣ БД возвращает запрошенные данные приложению
4️⃣ Приложение сохраняет полученные данные в кэше
5️⃣ Пользователь получает данные
Процесс 2. В кэше есть данные
1️⃣ Пользователь запрашивает данные
2️⃣Приложение уже имеет эти данные в кэше (ведь они были записаны туда при первом обращении) и поэтому НЕ ОБРАЩАЕТСЯ за ними к БД
3️⃣Пользователь получает данные
Стратегии инвалидации кэша
➖ Инвалидация по TTL.
TTL (Time To Live) – время жизни данных в кэше. При сохранении данных в кэш для них устанавливается TTL и данные будут обновляться с периодичностью не менее TTL.
➖ Инвалидация по событию
При таком подходе данные инвалидируют при наступлении некоего события – обычно это обновление данных в источнике
Стратегии вытеснения
🔸LRU (Least Recently Used) – стратегия вытеснения, которая опирается на время последнего использования записи. Она удаляет записи, у которых время последнего использования старше остальных. Таким образом, в кэше остаются записи, которые использовались недавно. Эта стратегия опирается уже не на случай, а на паттерн использования данных, поэтому она гораздо эффективнее предыдущих.
🔸LFU (Least Frequently Used) – стратегия вытеснения, опирающаяся на частоту использования записи. Она удаляет записи, которые использовались реже всего. Так в кэше остаются данные, которые использовались чаще других. Эта стратегия тоже опирается не на случай, а на паттерн использования данных, поэтому она тоже эффективнее остальных и является альтернативой LRU.
Полную версию читайте на Хабре.
📎 Полезные ссылки
1. О стратегиях вытеснения на примере инструментов redis
2. Трудности и стратегии кэширования на сайте Amazon
3. Основы кэширования от Amazon
4. Базовый “ликбез” и ссылки на первоисточники от Wikipedia
#архитектура
Please open Telegram to view this post
VIEW IN TELEGRAM
👍13❤7🔥3
Цикл статьей по изучению Postman (через VPN)
Часть 1 - Postman — как инструмент тестирования API
Часть 2 - Postman — менеджмент, структурирование, импорт и экспорт коллекций
Часть 3 - Postman. Смена окружений, предварительная настройка авторизации, установка переменных
Часть 4 - Postman — Collection runner, тесты и сниппеты (Snippets), запуск тестов в CI через Newman
#api #инструменты
Часть 1 - Postman — как инструмент тестирования API
Часть 2 - Postman — менеджмент, структурирование, импорт и экспорт коллекций
Часть 3 - Postman. Смена окружений, предварительная настройка авторизации, установка переменных
Часть 4 - Postman — Collection runner, тесты и сниппеты (Snippets), запуск тестов в CI через Newman
#api #инструменты
👍7👏2❤1
Бесплатная книга по проектированию API
Книга Сергея Константинова «API» состоит из шести разделов, посвящённых:
1. проектированию API,
2. паттернам дизайна API,
3. поддержанию обратной совместимости,
4. HTTP API и архитектурным принципам REST,
5. SDK и UI-библиотекам,
6. продуктовому управлению API.
📖 Читать онлайн
⬇️ Скачать PDF | EPUB
#api
Книга Сергея Константинова «API» состоит из шести разделов, посвящённых:
1. проектированию API,
2. паттернам дизайна API,
3. поддержанию обратной совместимости,
4. HTTP API и архитектурным принципам REST,
5. SDK и UI-библиотекам,
6. продуктовому управлению API.
📖 Читать онлайн
⬇️ Скачать PDF | EPUB
#api
❤13👍4⚡1