Не понимаю, откуда берётся вопрос "куда развиваться дальше сеньор-аналитику?". Причем с ответами типа "идти в продакты / архитекторы / лиды аналитики".

Очевидно же, что после сеньора нужно идти в стафф-аналитики, потом — в сеньор-стафф, потом — в принципал, и, наконец, в феллоу аналитика.

Это же типовая линейка инженерных ступеней в западных компаниях. А то у нас, как обычно — краем уха услышали, что есть такие джуны-мидллы-сеньоры, побежали внедрять, до конца не дослушав. И что там после сеньора ещё целая лестница есть — так и не узнали.

Нет после сеньора выбора: архитектор или управленческий трек. Это у вас в компании что-то неправильно поняли. Сеньор — это старший аналитик на одном проекте. Стафф — аналитик, курирующий несколько проектов. Принципал — это тот, кто закладывает принципы работы всех системных аналитиков в компании (опыт — 8+ лет). Феллоу — советник CTO или директора по системному анализу и проектированию систем (10+).

Там ещё могут быть промежуточные уровни вроде "бизнес-партнер" (слышали же про HR BP? вот то же самое, только по технологиям) и distinguished (это перед fellow). И это всё должности специалистов! Людьми руководить не нужно, не менеджерский трек!
Вопросов, как повысить зарплату очень ценному чуваку, не делая его начальником, не возникает — сделай ещё грейдов, бери, повышай.

Начиная с уровня партнера это может называться не "системный анализ", а просто "технологии"; к этому моменту системный аналитик уже должен был повидать всякого и разобраться в деталях всех технологий и подходов к архитектуре. При этом необязательно становится архитектором, архитектор — проектирует решение, аналитик — задаёт границы решения и выявляет все аспекты, которые должны быть учтены.

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

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

Жаль, что не все компании (и руководители) понимают всю полезность такой роли. Вопросов было бы сильно меньше.

Кто нас учит. Раньше меня часто просили порекомендовать какую-нибудь книгу по системному анализу и смежным областям. В последние пару лет почти перестали — теперь просят порекомендовать курс! Так вот книг именно по системному анализу и управлению требованиями давно уже никаких не выходило, тема себя исчерпала. Свежие книги только про продукты и архитектуру.

Но книги — это, в общем, попсовый источник знаний. Есть более формальные тексты: стандарты (и руководства по их применению), научные статьи и своды знаний — Body of Knowledge. Сегодня про них.

Ну, все точно слышали про PMBoK и BABoK.
Но есть ещё куча интересных сводов знаний, в которых собраны по кусочкам разные знания, которые вообще-то нужны продвинутым аналитикам! Поехали:

SWEBoK — Software Engineering, он же — ISO/IEC TR 19759:2015. Свод знаний по программной инженерии, ни много, ни мало! Современные программисты про него и не слышали. Тут нас могут интересовать разделы про требования, software architecture, software design и software construction (это всё разные понятия!), а ещё софт-скиллы и экономика разработки (это 11 и 12 главы).

SEBoK — Systems Engineering, а это уже по системной инженерии в целом. Кстати, более-менее свежие идеи про работе с требованиями приходят именно из системной инженерии, это у них одна из основных практик. Тут всё начинается с самого начала: что такое система, что такое системное мышление, что такое модель и т.д.

Из наших тем: бизнес-анализ и анализ миссии (как космические миссии, что-то более осмысленное и менее структурированное, чем проект), анализ потребностей стейкхолдеров, определение архитектуры; собственно системный анализ (этот термин мало где ещё встречается). Ещё из интересного: рассмотрены нюансы приложения инженерии к продуктам, сервисам и предприятиям (Часть 4).

Системный анализ, при этом, понимается как работа по выбору решения: определение критериев оценки, оценивание проектных свойств разных вариантов решения, выбор итогового решения. Здесь же предполагается изучение компромиссов (Trade-Off Studies), включающее анализ эффективности, стоимости и технических рисков. Ну это на случай, если вы не знаете, чем должен заниматься системный аналитик — вот этим, в основном.

EABoK — Enterprise Architecture, тут всё понятно. Непонятен только статус: на сайте MITRE лежит черновик от 2004 года (pdf), есть ли что новее, я не понял. В черновике, судя по всему, авторы пытаются не заблудиться между TOGAF, DODAF, Zachman Framework и другими способами описания EA, но у них не получается.

BIZBoK — Business Architecture, свод знаний по бизнес-архитектуре. Стратегия, бизнес-возможности, структура организации, бизнес-инициативы, ценности, продукты, нормативка — всё тут. А также референсные модели бизнес-архитектуры для разных индустрий.

BTABoK — Business Technology Architecture, это про цифровую трансформацию. Хотя сами авторы оплёвывают этот термин, заявляя, что это только чтобы у вас деньги выманить, а говорить нужно про цифровое превосходство (Digital Advantage). Дальше они также оплёвывают TOGAF, SAFe, BABoK и так далее. В целом, замах тут "как говорить с бизнесом про ИТ". Дико интересно, но местами неокончено.

BPMCBOK — тут всё понятно, управление бизнес-процессами. Есть русский перевод, и даже довольно активное российское отделение соответствующей международной ассоциации.

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

DMBoK — Data Management, свод знаний по управлению данными. Всё, что вы хотели узнать про данные в любом виде (в том числе — про качество данных и интеграцию данных). Есть перевод и открытый конспект на русском, но при случае рекомендую обзавестись оригиналом, если вы много работаете с данными в каком-либо аспекте.

Знаете ли вы ещё какие-нибудь своды знаний? А пользу в них видите?

Про REST слышали наверняка все.
Некоторые даже слышали про RESTful. Единицы вспомнят модель зрелости REST Леонарда Ричардсона и её уровни.

Между тем, есть отличная статья Guy Levin, перевода которой я почему-то не нашел. Нужно это срочно исправить! Здесь дам короткий вольный пересказ.

Уровень 0: The swamp of POX (Plain old XML) — Болото старого доброго XML.
Это нам напоминает, с чем боролся Рой Филдинг: XML, SOAP и вызовы разных функций из одного эндпоинта методом POST.

Даже тут есть правила:
1. В названиях эндпоинтов слова нужно разделять дефисом: "-", это spinal case или kebab-case, "шашлычный стиль" — слова как бы нанизываются на шампур.
2. Подчеркивания в названиях эндпоинтов лучше не использовать. Почему так: потому что ссылки в тексте подчеркиваются, и символы "_" могут визуально потеряться, в отличие от "-".
3. Все ссылки должны быть в нижнем регистре. Это всё рекомендации RFC3986.
4. Расширения (то есть точку) лучше не использовать, формат ответа задаётся заголовком Content-Type.
Пример: http://api.example.com/blogs/guy-levin/posts/this-is-my-first-post

Уровень 1. Ресурсы.
Идея: разные эндпоинты для разных ресурсов. Названия эндпоинтов - существительные.
Правила:
1. Слэш ("/") в конце названия эндпоинта не нужен. Каждый ресурс имеет один адрес (URI). Разные URI указывают на разные ресурсы.
2. Слэш употребляется для указания иерархии ресурсов:
http://api.canvas.com/shapes/polygons/quadrilaterals/squares,
http://api.college.com/students/3248234/courses/2020/fall
3. Существительные в единственном или во множественном числе? Тут у автора сомнения, но большинство фреймворков поддерживают названия ресурсов во множественном числе. Мне лично тоже больше нравится во множественном.

Уровень 2. Методы.
Используем для операций с ресурсами стандартные методы http, соответствующие CRUD: POST, GET, PUT, DELETE, PATCH + дополнительные HEAD и OPTIONS. Если вам не хватает операций CRUD, автор рекомендует сделать подчиненный ресурс /actions, и делать к нему POST с указанием типа операции и дополнительных параметров. Такой небольшой кусочек RPC-like style, когда RESTful не одобряет, но очень хочется.

2.1. Заголовки HTTP
Используйте заголовки! Тема тут обширная, но в основном заголовки используются для безопасности, переговоров клиента и сервера о форматах и кодировках контента, о кэшировании, версиях и обновлениях ресурсов, их размерах. Собственно, запрос HEAD возвращает заголовки без самого тела ресурса, чтобы клиент мог понять — нужно ли запрашивать ресурс вообще.

2.2. Параметры запроса
Используйте параметры запроса! (та часть, которая после @?"). Не забывайте про такие операции, как фильтрация, поиск, сортировка и пагинация. Для фильтров добавляем названия полей ресурса, по которым можно отфильтровать результат, указав значения или диапазон:

https://example.com/api/products?category=electronics&price=50-100

Для поиска — параметр ?q={строка поиска}.
Для сортировки: ?sort={поле, по которому сортируем}&order={ASC|DESC}. Как вариант, для сортировки по нескольким полям: ?sort=name,-price (сортируем по названию в прямом порядке, по цене — в обратном).
Для пагинации указываем число элементов на странице и номер страницы:
?limit=10&offset=20.

2.3. Коды ошибок
Используйте коды ошибок HTTP.

Уровень 3. Управление гипермедиа.
Тут два аспекта: обсуждение формата и HATEOAS.

3.1. Обсуждение формата — это про заголовки. Клиент и сервер договариваются, в каком формате сервер вернет ресурс. Может, в json, может в XML, а может просто в виде текста. В теории должно работать, и серверы должны отдавать ресурс в удобном для клиента представлении. На практике реализация встречается очень редко, но во внутренних гетерогенных системах может быть полезным. Запрос OPTIONS как раз про это: какие действия допускает сервер над ресурсом и в каких форматах готов его отдавать.

3.2. HATEOAS. Hypermedia As Transfer Engine Of Application State. Не бывает. Хотя идея в целом хорошая: к ответу сервер должен цеплять перечень эндпоинтов, связанных с запрашиваемым ресурсом, показывая всю иерархию подчиненных ресурсов. В теории, если вы обращаетесь к корню API, сервер должен отдать всю структуру API, фактически -- документацию. Но реализации такого почти не встречается.

3.3. Версионирование. Тут понятно: у вас может быть несколько версий API, и клиент может пользоваться только какой-то конкретной. Варианта два — добавляем версию в URL: /v2/user или в кастомный заголовок типа X-API-VERSION или похожий.

Вот такие уровни зрелости и правила REST. И цитата из Роя Филдинга:

A REST API should be entered with no prior knowledge beyond the initial URI and set of standardized media types that are appropriate for the intended audience. [...]
In other words, if the engine of application state (and hence the API) is not being driven by hypertext, then it cannot be RESTful and cannot be a REST API. Period.

К вопросу про развитие "после senior": обнаружилась забавная история — некоторые работодатели, когда хотят написать "опытный аналитик", пишут "Бизнес-архитектор"; особенно такое название любят интеграторы.

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

Или вот:

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

Иногда, конечно, под этим названием попадаются и настоящие бизнес-архитекторы, основная задача которых, по-честному: "Развивать возможности бизнеса, идентифицировать и реагировать на изменения рынка и окружающей среды" и "Исследовать и описывать бизнес-архитектуру компании на языке потоков ценностей и business-capabilities, бизнес-функций, бизнес-сервисов, бизнес-возможностей и бизнес-процессов" — но это буквально только в одной вакансии.

В общем, хотите стать архитектором — просто назовите себя архитектором! Делов-то.

Придумал игру "Снежинки среди нас": новогодняя ИТ-мафия. Позволяет и развлечься, и прокачать софт-скиллы, и украсить офис к Новому году.

Правила как в Мафии, только роли такие:
— Скрам-мастер — ведущий. В игре не участвует, но следит за ритуалами.
— Заказчики. Их несколько, никто не знает, кто они, но каждую ночь они просыпаются и подбрасывают в бэклог новые таски, и могут, на выбор — либо забраковать произвольное число готовых задач ("не прошли приемку"), или потребовать снять кого-нибудь с проекта. Таски выбираются из отдельной колоды с идеями по украшению офиса: вырезать снежинку, раскрасить гномика, сделать гирлянду и т.п. За одну ночь можно подкинуть в бэклог столько тасок, сколько осталось игроков. В начале игры бэклог наполняется тасками по числу игроков x2.
— Команда. Ночью спят, днём выполняют таски из бэклога. Заодно обсуждают, как вообще успеть сделать всё, что навалили, и кого можно выгнать, чтобы уже перестали наваливать. Тот, кого выгоняют, вскрывает свою карту и дальше участвует только как наблюдатель. Во время спринта ("днем") Заказчики работают, как члены команды.
— Продакт-оунер. Просыпается раньше всех, может либо проверить кого-то — не является ли тот Заказчиком, либо выкинуть из бэклога несколько задач, которые ещё не взяли в работу (до половины от числа оставшихся игроков).
— Ресурсный менеджер. Может спасти от снятия с проекта одного из членов Команды, но не дважды подряд. Себя может спасти только один раз за игру.
— Человек-снежинка. Не является Заказчиком, но выигрывает, когда выигрывают они. Никакими специальными умениями не обладает, ночью не просыпается, но старается незаметно парализовать работу команды.

Игра заканчивается победой Команды, если всех Заказчиков выкинули (объявлен фича-фриз и можно спокойно доделать все задачи в работе).

Заказчики (и Снежинки) побеждают, когда Команда полностью разобрана (результат работы им достаётся бесплатно + неустойка).

Пока на практике играть не пробовал, но должно быть весело!

Практически на каждом Летнем аналитическом фестивале умудрённые опытом аналитики жаловалась, что для них мало докладов, а всё в основном для начинающих и миддлов. И вот, наконец, организаторы решили сделать отдельное событие для опытных системных аналитиков! Причём зимой. Меня пригласили в качестве председателя программного комитета, что очень лестно. Я ещё помню, как 10 лет назад выступал на ЛАФ, и это было чуть ли не первое выступление моё на отраслевой конференции вообще.

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

🎙 Итак, идея Зимних аналитических выходных 2024 — настоящее и будущее индустрии системного анализа. Кроме традиционных докладов и мастер-классов мы запланировали сессии совместного выявления основных трендов и требований к самим задачам системного анализа, к людям, которые работают в этой сфере, и к подразделениям, выполняющим эту роль в компании.
В течение 2 дней на площадках мероприятия пройдет более 20 докладов, мастер-классов, круглых столов и деловых игр от топовых экспертов, основателей сообществ аналитиков, авторов профессиональных стандартов и карт компетенций, руководителей направлений СА.

📆 Даты: 17-18 февраля 2024 года.

🏨 По традиции ЛАФ, это загородный отель, проживание по системе "все включено", зимние развлечения, бассейн, скалодром и всё такое. И afterparty с музыкой и общением 🎉.

Мы уже собрали звездный пул спикеров, но программа ещё будет пополняться. Регистрация уже открыта: участвуйте в самом ярком аналитическом событии зимы! 🚀❄️

Интересная мысль про необходимость роли системного аналитика из-за протечек абстракций (а точнее — ещё и из-за слабой изоляции контекстов).

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

Одновременно в системах ещё и слои абстракций дырявые: представление данных для пользователя не отделено от способов хранения данных, а логика вообще размазана по всем слоям.

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

Продолжая тему игр — это Дженга наоборот получается: как напихать в систему ещё функций, пока она не совсем не развалится. Причем в N-мерном пространстве.

Собственно, задачи по интеграции почти все такие — понять, в какой из N систем должна быть новая функция, найти K систем, из которых нужно данные взять и в которые отправить, и решить — кто именно будет брать, что брать, куда отправлять, кто за всем этим будет следить + всё это ещё и во времени.

Ergo, если мы имеем чистую архитектуру, low coupling high cohesion, да ещё и единый язык бизнеса и разработки, то системные аналитики становятся ненужными. Хм, кажется, я только что сформулировал основные принципы DDD.

Аналитики! Сопротивляйтесь внедрению в своих компаниях DDD! Запутывайте архитектуру! Ломайте станки! Храните документацию в Ворде!

В крупных организациях, опять же, по моему опыту (он достаточно обширный) системный аналитик занимается тремя основными вещами:
1. Проводит сбор требований со стейкхолдеров
2. Пытается определить в каких ИС и какие изменения необходимо реализовать (это следствие бесконечно огромных протечек моделей предметных областей друг в друга, высокой привнесенной сложности)
3. Фиксирует требования и какие ИС затрагиваются в документах

СМИ и блогеры тиражируют исследование Head Hunter'а — хотя первоисточник не находится почему-то — по профессиям специалистов с самой большой средней зарплатой.

И там на первом месте Devops (214 тыс.) , на втором — дата саентисты (202), а вот на третьем — системные аналитики (150). С чем всех коллег и поздравляю!

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

Но в целом вы теперь знаете, на что в среднем ориентироваться.

А вот ещё интересный взгляд на роль аналитика (и архитектора) с точки зрения Теории ограничений (TOC) Голдратта. Если у вас разработка является ограничением, логично перед ней ставить звено предобработки, чтобы на вход подавать не сырье, а заготовку. (Помним, что Голдратт в основном анализировал материальные производства).

Как вам кажется, похоже это на работу аналитика? Не постановка задачи, а предобработка, подготовка материала для работы, создание заготовок.

Если с этой точки зрения посмотреть на процесс, можно уточнить у разработки — что именно им полезно в качестве заготовки, а что не нужно (заготовка не должна быть излишне тщательной).

Про Винcтона Ройса, Agile и разработку программного обеспечения.

На заре индустрии разработки программного обеспечения был хороший доклад Винстона Ройса (Winston Royce 1970) про то, как БЫСТРЕЕ выводить программный продукт в эксплуатацию. Так, как основная проблема отрасли это... ОШИБКИ!

Ключевая мысль доклада: Пиши БОЛЬШЕ документов, чтобы БЫСТРЕЕ выводить программный продукт в эксплуатацию.

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

И тут на курсе (который сейчас провожу), при разборе применения Теории Ограничений коллеги заметили что, на самом деле Ройс решал проблему ЗАЩИТЫ ОГРАНИЧЕНИЯ!

То есть:

Пиши много документов для того, чтобы..... ЗАЩИТИТЬ ОГРАНИЧЕНИЕ!
Где Ограничение - машинное время ЭВМ.

Другими словами, это шаг "три" из пяти фокусирующих шагов ТОС.

Отсюда вывод:

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

#ответы_на_вопросы #TOC

С наступившим Новым годом! Всем профессиональных успехов и развития в новом году!

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

Вот, например, руководства по стилю REST API. Как мы все знаем, REST -- это просто набор архитектурных принципов, но, когда доходит дело проектирования конкретных API, возникает множество мелких вопросов. Иногда совсем мелких: какой регистр использовать для названий полей в json? А в названиях эндпоинтов? А имена ресурсов писать во множественном числе или в единственном?

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

Образцы таких гайдлайнов, как ни странно, можно найти у правительств разных стран. Они есть у Австралии, Новой Зеландии, Канады, Великобритании, у США конечно. Но мне больше всего нравится бельгийский гайдлайн: https://www.belgif.be/specification/rest/api-guide . Он и устроен наиболее логично, и как-то по-человечески, что ли. И при этом учитывает разнообразные аспекты, о которых и вправду стоит подумать.

В частности, в нём есть:

👉🏻 формат для URI эндпоинтов: рекомендуется lowerCamelCase, без расширений файлов;
👉🏻 три типа ресурсов: документ, коллекция и контроллер.
Документ — единичная сущность, с которой можно делать CRUD, у неё есть id, URI и поля;
Коллекция — набор однотипных сущностей, с которыми можно делать только GET и POST, и в редких случаях DELETE - если мы хотим удалить все элементы сразу;
документы обычно лежат в коллекциях, и могут содержать подчиненные коллекции:
/{имя коллекции}/{id документа}/{имя подчиненной коллекции}/{id подчиненного документа}.
Ну а контроллер — это подчиненный ресурс документа, представляющий бизнес-операцию, не укладывающуюся в CRUD (примеры: POST /accounts/123/withdraw, GET /convertMoney?from=EUR&amount=45&to=USD). При этом для долгих операций рекомендуется создавать ресурс типа документ, и уметь возвращать промежуточный статус операции (превращая её, таким образом, в асинхронную).

👉🏻 спецификация дополнительных операций: для документов — ?select={(поле,(поле,поле))}, чтобы выбирать только указанные поля — убираем overfetching;
для коллекций — сортировка: ?sort={поля для сортировки} , пагинация: ?page, ?next, ?prev, ?pageSize= , полнотекстовый поиск: ?q={поисковый запрос}, фильтрация: ?{поле}={значение}.
👉🏻 механизм для встраивания ресурсов (возможности GraphQL в REST!): ?embed={название связанной сущности, которую мы хотим встроить в ответ}, убираем underfetching.
👉🏻 требования к идентификаторам документов: рекомендуется текст, URI или UUID, а вообще там множество нюансов: идентификатор должен хорошо запоминаться, легко вводиться, легко проверяться, распечатываться, подсказывать природу объекта (по структуре идентификатора), предупреждать коллизии, не содержать чувствительной информации, не быть легким для подбора (если идентификаторы выдаются последовательно - легко угадать предыдущие и последующие, и даже вычислить, например, количество сущностей), использоваться в разных системах, быть расширяемым, вставляться в URL, логичным образом сортироваться... То есть вообще непонятно, бывают ли идентификаторы, удовлетворяющие всем требованиям!
👉🏻 рекомендации по использованию кодов ошибок;
👉🏻 соглашение об использовании значений null в json (решение: не должны использоваться, чтобы не создавать неоднозначности; если значение null, то оно не передаётся. При этом [] — это не null!)
👉🏻 кэширование (по времени и по содержимому, управление через параметры заголовка:
👉🏻 эволюция и версионирование API (обсуждаются совместимые и несовместимые изменения)
👉🏻 интернационализация (фильтрация языка через ?lang={код языка})
👉🏻 отслеживание (Trace-Id в заголовках)
👉🏻 статус API (ресурс health)

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

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


Друзья, коллеги, всем привет! 🙌
Просим всех принять участие в опросе об интересных для вас темах докладов на IT-конференциях.

Результаты будут доступны для широкого круга. Это поможет и ПК, и спикерам выбирать для вас наиболее актуальные и интересные темы.

Две минуты вашего драгоценного времени сейчас - бесценный вклад 💎 в качество конференций!

Будем благодарны за репосты коллегам-айтишникам любых ролей!

Пройти опрос 🔥 ОПРОС О ТЕМАХ ДОКЛАДОВ 🔥