Открываю портал в дискуссию на тему “Надо ли читать “Проектирование требований к ПО” К. Вигерса и Дж. Битти в 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 уже завтра😳