😁😆😁 на выходных закончить чек-лист по переходным требованиям. Заодно разобраться со странностями в Word.

🤸‍♀️ "Бесполезные" слова JSON Schema

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


✅ multipleOf
Позволяет ограничивать кратность числовых значений заданному числу. Если по-простому: проверяемое значение должно без остатка делиться указанное вами. Примеры:

🔘Бронирование переговорных комнат доступно на любую продолжительность в минутах с шагом в 15 минут (15 мин, 30 мин и т.д.).

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "minutes" : {
      "type": "integer",
       "multipleOf": 15
    }    
  }
}

😀Общая площадь квартиры должна иметь точность до 1 знака после запятой.

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "area" : {
      "type": "number",
      "multipleOf": 0.1
    }    
  }
}

🔘Цена должна иметь точность до 2 знаков после запятой. Дополнительно явно учтём, что величина должна быть строго положительной.

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "price" : {
      "type": "number",
      "multipleOf": 0.01,
      "minimum": 0,
      "exclusiveMinimum": true
    }   
  }
}

🔘Заказ на производство ПЭТ-бутылок ограничен ассортиментом тары с ёмкостью в 0.5л, 1.0л, 1.5л, и 2.л. Значит значение должно делиться на 0.5 с дополнительными ограничениями на диапазон.

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "capacity" : {
      "type": "number",
      "minimum": 0,
      "exclusiveMinimum": true,
      "maximum": 2.5,
      "exclusiveMaximum": true,
      "multipleOf": 0.5
    }
  }
}

😫 const
Ограничивает значение поля единственным значением. Формально использование const эквивалентно использованию enum с одним единственным значением, но const позволяет выстраивать более гибкие условия. Пример:

🔘Роль пользователя должна строго соответствовать значению "seller" либо "cashier", хотя ролевая модель может предусматривать больше доступных вариантов.

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "role" : {
      "type": "string",
      "oneOf": [
        {"const": "seller"},
        {"const": "cashier"}
      ]
    }
  }
}

✅ if-then-else
Позволяет задать условия проверки полей. Например, мы можем проверить значение и в зависимости от результата проверки потребовать выполнение других условий. Пример:

🔘Для любого оплаченного заказа обязательно должны присутствовать реквизиты оплаты в составе номера счёта и суммы платежа.

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    
    "order_status": { "enum": ["pending", "processing", "paid"] },
    "payment_details": {
      "type": "object",
      "properties": {
        "account_number": { "type": "string" },
        "amount_paid": { "type": "number" }
      },
      "required": ["account_number", "amount_paid"]
    }
  },
  "if": {
    "properties": { "order_status": { "const": "paid" } }
  },
  "then": {
    "required": ["payment_details"]
  },
  "else": {}
}

✅ not
Позволяет запретить использование конкретных значений или целых групп значений. Использование not полезно, когда проще описать исключение, чем правило. Примеры:

🔘При регистрации пользователей необходимо удостовериться, что их имена не входят в перечень зарезервированных слов.

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "name" : {
      "type": "string",
      "not": { "enum": ["admin", "root", "guest"] }
    }
  }
}

😀Название книги не должно быть пустым и не должно состоять только из пробелов.

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "title": {
      "type": "string",
      "minLength": 1,
      "not": { "pattern": "^\\s*$" }
    }
  }
}

#проектирование #интеграции #сервисы #форматы

Ⓜ M-shaped: расширяем словарный запас

Наверняка многие из вас слышали, что нужно стремиться стать T-shaped специалистом. Сам я тоже часто сталкивался с этой идеей и считал её вполне обоснованной. Но буквально сегодня услышал, что теперь гораздо правильнее быть M-shaped 🙈

Что это вообще означает? Думаю, пересказывать саму концепцию не лучший выход. Проще сразу поделиться полезными ресурсами👇

🙂Если хотите быстро познакомиться с этой новой моделью, почитайте вот эту статью: https://www.rbc.ru/education/07/11/2025/6905df819a7947dd6c6fb913

🙂Но если интересуетесь деталями и личным опытом, рекомендую посмотреть это видео: https://youtu.be/ExvUFrHuBHM?si=xP4QCkSW01oVG2dG
Мне оно очень понравилось, многое стало понятно, и точно есть над чем поразмыслить.

#карьера #статьи #видео

🔂 Границы системы: иллюзия покоя и нескончаемый поток работ

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

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

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

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

☝️ Отсюда мораль: заморозка функциональности вовсе не означает статику, а границы системы — это не предел, а источник постоянных задач.

Знакомо? Если да, поделитесь в комментариях своим опытом и впечатлениями.

#системныйподход

☠ История про 12000 часов, или как угробить компанию

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

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

Заинтриговал? Тогда рекомендую обратиться к отрезвляющей 👉 статье

#методыуправления #статьи

🌭 Иллюзии, или Как я дважды наступил на одни и те же грабли за одну неделю

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

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

И вот в процессе возникает красивое требование переводить пользователя на то или иное место в системе, если он кликнет на описание продукта. Критерий — вид продукта. Звучит просто, да? Да и верхнеуровнево всё выглядит пристойно. Смежники тоже настраивают на оптимистичный лад: тип продукта есть, мы работаем в одном домене, говорим на одном языке  🌐

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

Выяснилось:
1⃣в зависимости от кейса экраны с продуктами, по которым предполагаем клики, разные. Всего возможно 2 варианта (и на том спасибо);
2⃣данные для них надо тянуть из двух разных сервисов;
3⃣у каждого из сервисов своя, уникальная и неповторимая классификация продуктов.

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

Стадии принятия неизбежного прошли по классике: гнев ("Как так?!"), отрицание ("Этого не может быть, у нас же есть стандартизованная типизация...") и торг ("А может, всё-таки можно как-то..?").

Торг, кстати, провалился с треском. Пришлось выкручиваться самому и придумывать варианты 🛠️ на своей стороне.


🧐 Мораль

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

А раз так, то пока вы не докопались до сути и не подтвердили всё сами, заверения смежников о том, что "это есть" — это лишь иллюзия.

👉 Кстати, на тему иллюзий могу порекомендовать статью на Хабре. Букв много, но интересно.

#статьи #психология #мозг

💡 CodeFest завершился: о чём подумалось

Основные итоги мероприятия:
🛑Торт съеден, кофе выпит
🛑Лут мерч собран
🛑Фоточки сделаны
🛑Круг общения расширен
🛑Бесконечный список книг к прочтению пополнился 

Вроде, ничего не забыл... 

А если без шуток (но мы-то знаем, что в каждой шутке есть доля шутки), то на минувших выходных ушёл на CodeFest🎙 с головой. И только сейчас выдалась возможность поделиться общими впечатлениями.


🤩 Про технологии 🤖
В какой бы области мы ни оказались — роботы, автопилоты, медицина или новые конструкции двигателей — сейчас везде важную роль играет ИИ. Он добрался и до нашей сферы: анализа и разработки. Поэтому немудрено, что ряд выступлений касался именно этой сферы. Но не ИИ единым жив человек, и приятно, что организаторы сохранили определённый баланс в программе 👍. Ведь по моим наблюдениям, некоторые организаторы конференций, следуя за модой, отталкивают часть аудитории, которой интересны традиционные вопросы архитектуры, тестирования, управления командами и т.п. 


🤩 Про людей 🤝
На конфу участники съезжались со всей страны. С кем бы ни довелось пообщаться, разговор всегда получался увлекательным, и находились точки соприкосновения. Так, на препати в поисках свободного места я на какое-то время попадаю в компанию ML-инженеров из Москвы и Питера, с которыми весело провожу время. А в ходе обсуждения доклада Сергея Нужненко руководитель отдела разработки одной из компаний произносит что-то вроде: "Теперь я понял, что составленную мною программу обучения аналитиков надо будет переделать"💻.

Именно поэтому я не могу согласиться с мнением, что конференции себя изжили. Сидеть дома перед условным Zoom'ом, слушая доклады, конечно, удобно, но это сводит всё к механизму передачи информации по канонам "лектор-студент" (кстати, о проблеме формальной начитки,  часто не переходящей в знания, отлично говорил Максим Дорофеев 💪). Живой формат даёт энергию, эмоции и возможность просто подойти к другому участнику в перерыве, чтобы лично обсудить наболевшее. 

#события #codefestru #CodeFest

😱 Про нечитаемый сиквенс

Хочу поделиться с вами историей из релизного ада ⚙️🔥.

Есть у нас система со строгим процессом: для каждого релиза нужно готовить мега-артефакт. Один из ключевых разделов — описание логики через UML-диаграмму последовательностей. Без неё никуда.

К счастью, эту работу теперь ведёт другой аналитик, так что я могу наблюдать этот эпик со стороны 🍿🍿.

А главным героем нашей истории выступает согласующий эксперт. Его запрос — нужно больше золота полнота отображения всех задействованных систем и вариативности логики. Каждый раз его комментарии звучат примерно так:

А если пользователь откажется? Где эта ветка?

А почему не показан поход в сервис... за...?

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

Так мы дошли до 4-го релиза. Эксперт открывает эту огромную простыню и сокрушается, что не понимает, где посмотреть произошедшие изменения относительно прошлой версии...😵‍💫

Наш аналитик глубоко задумался и распилил всё на две отдельные диаграммы: "Существующие сценарии" и "Новые сценарии". Значительно легче не стало, но это лишь отсрочка решения.

Я вангую, что когда в 5-м или 6-м релизе изменения будут точечными (новая ветка, дополнительный вызов микросервиса и пр.), вопрос вернётся бумерангом. Ведь к тому моменту уже всё окажется внутри "Существующих сценариев", а новые правки уже будут разбросаны 🌪️ по всей диаграмме.

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

Вы сталкивались с подобным? Как разрешали противоречие между требованиями эксперта? 👇

#визуализация #uml

🔒 Дилемма заключённого из IT

В теории игр 🎲 есть знаменитая задача: "дилемма заключённого". Её суть проста: когда каждый участник действует только в своих интересах, не доверяя другим, результат для всех оказывается хуже, чем если бы они договорились.

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

Иллюстрацию этой мысли предлагаю рассмотреть на примере стриминговой платформы (вроде Netflix). Итак, у нас есть:

🧠 "Мозг" — единая система рекомендаций с ML-моделью внутри. Она знает, что вам предложить, но может обработать только 1000 запросов в секунду.
📺 "Лента" — главная страница с подборками фильмов.
🔎 "Поиск" — сервис, который находит фильмы по вашему запросу и заодно показывает "похожие".

За каждую из этих частей отвечает своя команда разработчиков.

В обычное время всё идёт по плану: "Лента" и "Поиск" вместе отправляют меньше 1000 запросов, и "Мозг" справляется.

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

⚖️ В чём подвох?

Команды "Поиска" и "Ленты" смотрят на свои графики и видят проблему: их сервисы тормозят, потому что ждут ответа от "Мозга". У команд есть два пути:

1⃣ Подождать. Продолжать действовать по правилу: если ответ не пришёл сразу, повторную попытку выполнить с некоторой задержкой. Этот вариант поможет снизить нагрузку, но точно не решит вопрос здесь и сейчас.
2⃣ Поторопиться. Начать повторять запросы быстрее, не откладывая повторы на потом. Это не очень честно по отношению к остальным, но так их собственный сервис будет работать шустрее и потенциально покажет результат пользователю первым.

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

🌪️ Шторм запросов

В итоге мы получаем равновесие Нэша происходит катастрофа. Вместо того чтобы успокоиться, система входит в штопор. Лавина повторных запросов от обеих команд окончательно добивает "Мозг". Он начинает массово отклонять обращения. В результате пользователи видят пустые экраны: ни в ленте, ни в поиске рекомендаций больше нет. Система легла целиком 🌟 из-за того, что её части пытались спасти себя поодиночке.

🤔 Мысли и выводы

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

Вывод: не стоит полагаться на добрую волю и координацию причастных команд, а необходимо встраивать защиту от таких сценариев в саму архитектуру. В первую очередь речь про Rate Limiter с отдельными лимитами по API-ключу. А далее уже можно смотреть в сторону приоритезации потребителей, обратного давление (Back pressure), предохранителя (Circuit Breaker) и других штуковин. 

#архитектура #проектирование #интеграции #сервисы #кейсы

⚡️ Запись к нам приходит

В комментариях к одному из постов меня спрашивали, когда будет доступна запись моего доклада на CodeFest🎙 этого года.

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

Ссылки:
🛑Выступление 📹: здесь.
🛑Презентация 🥩: здесь.
🛑Доп.чек-лист 🎆: здесь.

Материалы дополнительно продублирую в комментариях.

#события #выступления #codefestru #CodeFest #требования #видео #таблицы

🧠 ARC42 Quality Model: почти 200 атрибутов качества в одном месте

Открыл для себя интересный ресурс — ARC42 Quality Model.

На момент написания этого поста там собрано:

🔶 189 атрибутов качества
🔶 147 примеров формулировок
🔶 31 архитектурный подход для обеспечения качества

🕸️ В чём главная фишка?
Все эти элементы семантически связаны между собой, образуя разветвлённый граф. Такая структура отлично отражает реальность: у понятий не всегда есть строго один предок или одна причина. Это гораздо ближе к жизни, чем строгая иерархия.

Центральными узлами этого графа служат 9 так называемых измерений (в некотором смысле они пересекаются со стандартом ISO/IEC 25010):

🎯 Suitable (Пригодность)
🔒 Secure (Защищённость)
⚠️ Safe (Безопасность)
💪 Reliable (Надёжность)
🧩 Flexible (Гибкость)
⚡ Efficient (Эффективность)
🛠️ Maintainable (Ремонтопригодность)
⚙️ Operable (Эксплуатационная пригодность)
👤 Usable (Удобство использования)

Все остальные понятия модели так или иначе связаны с ними рёбрами.

В общем, очень интересная и полезная задумка для работы с требованиями и архитектурой! 👍

P.S. В скобках выше я для удобства восприятия указал свой вольный перевод.

#требования #архитектура #проектирование #майндмап