Открываю портал в дискуссию на тему “Надо ли читать “Проектирование требований к ПО” К. Вигерса и Дж. Битти в 2024 году?”

Напишу свое мнение по этому поводу.

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

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

Также сильно изменились требования к аналитикам. Сейчас от нас больше ожидают умение описать контракты API, структуры БД и интеграционные схемы. А разобрался ли аналитик, нужен этот функционал бизнесу или нет - беспокоит далеко не всех нанимающих менеджеров. Во время последних поисков работы в 2021 году про процесс разработки требований меня спросили где-то в 5 компаниях из 10.

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

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

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

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

Чем опасен PATCH?

На собеседованиях часто спрашивают, чем отличается PUT от PATCH.

Самый простой ответ - что PATCH предназначен для частичного изменения ресурса, в то время как PUT всегда меняет ресурс полностью.

Рассмотрим пример ресурса с пользователем:

{
"id": 1,
"name": "John Doe",
"email": "john@example.com",
"phone": "12345678"
}

Метод PATCH может позволять менять параметры ресурса по отдельности.

PATCH /users/1

{
"email": "newemail@example.com"
} 

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

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

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

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

Также, даже если мы сделали PATCH идемпотентным, его применение может привести к нарушению целостности данных. Допустим, мы делаем вызов с удалением email:

PATCH /users/1

{
"email": null
} 

Примерно в это же время кто-то сделал другой вызов, с удалением номера телефона:

PATCH /users/1

{
"phone": null
} 

Однако, по бизнес-правилам у пользователя должен быть заполнен либо email, либо телефон.

Значит, надо это заранее продумать и добавить дополнительную проверку в момент транзакции в БД. В то время как в методе PUT мы бы могли ограничиться валидацией на поля запроса.

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

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

Как познакомиться с GraphQL:

1. Посмотреть вебинар.
2. Почитать официальную документацию(она короткая, но на английском).
3. Потренироваться на тестовых и открытых API:
▫️ Тестовый API выдуманной горнолыжной базы - https://snowtooth.moonhighway.com/,
▫️ SWAPI на GraphQL - https://graphql.org/swapi-graphql/,
▫️ API GitHub - https://docs.github.com/ru/graphql/overview/explorer,
▫️ Еще много открытых API: https://github.com/graphql-kit/graphql-apis (не все сейчас работают, но какие-то можно посмотреть).

Тестовые и открытые API взяты из книги “GraphQL” Алекс Бэнкс, Ева Порселло - ее можно почитать, если хочется углубить знания технологии.

Села обновлять своё резюме для международного рынка и выяснила, что первый в гугл-выдаче сайт для создания резюме Resume.io — это скам. Как пишут на Reddit, он предлагает за 2 доллара один(!) раз скачать резюме в pdf, а после еще списывает 20$ якобы за подписку. В общем, будьте осторожны.

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

Такие шаблоны можно найти, например, вот тут:

- Microsoft CV templates
- Google Docs Templates
- https://resumeworded.com/resume-templates

Еще в ЕС есть стандарт резюме, который называется Europass. Его можно бесплатно создать на официальном сайте https://europass.europa.eu/en.

Только начала разбираться в этой теме и много еще не понятно. Например, как толково описать 9 лет опыта в 4х компаниях в одностраничном формате. Или как не умереть, редактируя свое резюме под каждую компанию и ее ATS. Если у кого-то есть хорошие советы/ссылки/инструменты по этой теме - делитесь в комментариях🤗.

Мне сложно дается грамотное ведение LinkedIn, поэтому решила поучаствовать в прожарке профилей в прямом эфире AgileFluent. Мой и еще 10 профилей разберет эксперт по международному найму🫣.

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

Приходите посмотреть на мой позор 17 декабря в 19:00 Мск в канале ребят. Все подробности и канал тут.

UPD: Запись эфира https://youtu.be/ci_YU9hpCmI

О КАНАЛЕ И АВТОРЕ

Привет!

Меня зовут Таня, я системный и бизнес-аналитик, занимаюсь разработкой IT-систем с 2015 года. Работала в ритейле, строительстве и финтехе.

Это мой авторский блог, который я веду с 2019 года в формате хобби. Я не покупаю и не продаю рекламу, но иногда могу анонсировать мероприятия коллег.

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

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

Очень благодарна вам за то, что читаете этот канал, оставляете реакции и комментарии - это очень важно для меня❤️.

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

LinkedIn
Хабр
Medium (eng)
Донаты: ЮMoney | PayPal

Тем временем, прожарка моего LinkedIn уже завтра😳

Какого размера должны быть микросервисы?

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

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

По канонам, сервис может считаться микросервисом, если он соответствует основным принципам MSA:

- Он имеет чёткие границы и сферу ответственности,
- он независимо развертывается,
- у него своя база данных,
- он взаимодействует с другими сервисами через API.

То есть про размер ничего нет. Ни в большую, ни в меньшую сторону.

В рекомендациях часто косвенно связывают размер микросервиса с размером команды. То есть команда, разрабатывающая 1 (и в идеале только 1) микросервис, должна быть 6-12 человек (правило 2х пицц). И, кажется, что это правило - результат сложного опыта и ошибок.

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

Бывают и обратные ситуации. В примерах микросервисов часто можно увидеть такие агрегаты, как Оплата, Заказ, Доставка, Склад и др.

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

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

И если с этим справляется одна двухпиццевая команда, то все отлично - сервис автономен, не сильно зависит от других сервисов и представляет сам по себе ценность для бизнеса.

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

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

В общем, микросервисы это и так сложно, а тут еще приставка “микро-” сильно сбивает с толку.

Например, на одном моем проекте распределенную систему из “среднего” размера сервисов причисляли к SOA-паттерну. Хотя там не было ни ESB-шины, ни общих баз данных, ни централизованной оркестрации. По факту это была распределенная система из микросервисов и мини-монолитов, которые все вместе вполне отвечали принципам MSA.

По моему опыту все-таки лучше иметь дело с мини-монолитами, чем собирать слово “Вечность” из слишком мелких и сильно связанных микросервисов.

Многие эксперты тоже советуют “не мельчить”, например здесь и здесь.

А с какими микросервисами вы сталкивались в своей практике? И как вам такой опыт?