Зачем прописывать требования для ПО? 📝

Вопрос, которым задаются многие опытные разработчики. А самые опытные не задаются - а просто ищут новую работу 😁

Я видел множество команд и систем, где правила работы этой самой системы не были высечены в камне. Обычно в таких командах присутствуют так называемые "старожилы", которые знают зачем эта система нужна, и что при смене тарифа нужно отправить три уведомления, но только если пользователь из Краснодарского края, и списать бонусы только со второго платежа. Или все таки с первого? 🤔

В таких ситуациях я обычно задаю один и тот же вопрос: "а что будет, если этот товарищ завтра уйдет на пенсию?". Иногда можно получить в ответ: "вот тогда что-нибудь и придумаем". Стратегия, конечно, хорошая. Особенно, если придумывать придется кому-то другому 😉. Но если мы действительно заинтересованы в поддерживаемости нашей системы - соломку нужно подстилать заранее. Не говоря уже о том, что негативные последствия непрописанных требований будут ощущаться даже при наличии "старожилов".

Без прописанных требований: 🚫
1. Мы не можем нормально заниматься проектированием.
2. Мы не можем доказать правильность работы нашей системы.
3. Невозможным становится рефакторинг. Так как у нас, скорее всего, нет тестов.
4. Мы вынуждены постоянно драться за время "старожилов".
5. Сами "старожилы" могут начать противоречить друг другу или сами себе. Такая вот штука - человеческая память.
6. Сами "старожилы" занимаются транслированием своей мудрости, а не задачами. Прописанные требования делают это почти бесплатно.
7. Команда становится зависимой от конкретных людей, создавая риски.

С прописанными требованиям: ✅
1. Мы можем быть уверены в завтрашнем дне.
2. Мы знаем что строим.
3. Мы знаем - как это улучшить.

Что делать? 🛠
1. Собрать заинтересованных лиц и описать проблему. Обычно это менеджер проекта, тимлид.
2. Построить карту местности. Разбейте вашу систему на функциональные блоки (не микросервисы!)
3. Составить роадмап. Соберите все функциональные блоки в таблицу. Назначьте виноватых ответственных. Разбейте по командам, если необходимо.
4. Планировать. Поставьте короткую регулярную встречу (примерно раз в месяц), на которой вы будете делиться успехами за прошедший месяц, и планировать работы по документированию требований на месяц грядущий.
5. Контролировать. Пропишите гайдлайн - что вы хотите видеть в требованиях? Настройте кросс-ревью между аналитиками. Начните с совместных ревью сессий, постепенно замыкая процесс на аналитиков. Приходите в гости время от времени. Вам будут рады! (но это не точно 😄)

Высечены ли в камне требования вашей системы? ⛏️

На прошлой неделе резлинулся очередной подкаст со мной на GetAnalyst. Пообщались с Катей на тему наблюдаемости систем 🔍
Внутри есть конкретный запускаемый пример с OpenTelemetry, который можно посмотреть и потрогать.

В тестовом режиме можно запускать на небольших проектах и MVP "как есть" и сразу стать выгодополучателем. А выгодополучателем быть - всегда приятно.

За иллюминатором дождь ☔

А это значит, что я лечу в Екатеринбург штурмовать яндексовый pytup 😈

Буду рассказывать про чистую архитектуру (без кругов, воды, и кругов на воде)

На странице конференции появится трансляция для всех желающих

Приходите послушать, если интересно 😉

Небольшой бекстейдж 😄

Friendly reminder
Буду вещать через 5 минут. Приходите! 😉

Вы просили шаблон чистой архитектуры
Вы получили шаблон чистой архитектуры 😉

https://github.com/ulkenauer/fast-api-clean-architecture

Как ускорить сервис на FastAPI практически бесплатно

То что я сейчас опишу - я видел сильно чаще, чем ожидал. Есть в мире разработки что-то типа эффекта "туннельного зрения".

Представьте, что у вас есть сервис, который куда-то ходит по HTTP. Так или иначе по HTTP мы все постоянно куда-то ходим за редкими исключениями.

В нашем примере - мы ходим за расширенной моделькой продуктов с остатками. А остатки - в отдельном микросервисе.

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

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

А проблема действительно за пределами нашего скоупа. Но все куда прозаичнее.

Выглядит наш огород примерно вот так:

@app.get("/product/{product_id}")
async def get_product(product_id: int, db: Session = Depends(get_db)):
    query = select(products).where(
        products.c.id == product_id
    )
    result = await db.execute(query)
    product = result.first()

    async with httpx.AsyncClient() as client:
        response = await client.get(f'хттп://сервис_остатков/получить_остатки/{product_id}')

    # Героическая склейка всего и вся

   return result

Допустим, сервис остатков мы написали относительно хорошо. Он отдает остатки по конкретному id за 30 миллисекунд в 99 перцентиле. Попросить одну запись по id из БД нам будет стоить 10 миллисекунд. Ну и, предположим, еще 10 миллисекунд скушает фреймворк.

Исходя из этих расчетов, мы абсолютно обоснованно считаем, что эта ручка будет выполняться быстрее чем за 50 миллисекунд в 99% случаев. Но на практике мы видим, что наша ручка выполняется от 100 до 150 миллисекунд.

В абсолютных цифрах - это может и не много. Но не в нашем же случае! Время затрачиваемое на полезную работу у нас - от 50% до 33%. То есть половину или две трети времени мы занимаемся непонятно чем.

Подрубив профайлер, мы обнаружим - все наши операции действительно в пределах 40 миллисекунд (не считая фреймворк). Но перед отправкой запроса по HTTP мы видим какой-то пробел во времени. Если измерим чуть точнее, то увидим, что это время съедает контекстный менеджер, который создает клиент httpx.

Нередко можно встретить вот такой утиль:

async def fetch_data(url: str) -> Dict[str, Any]:
    """Утиль для получения данных из другого сервиса"""

    async with httpx.AsyncClient() as client:
        ### Богоподобная обработка ошибок и таймауты!
    return result

И этот утиль потом используется во всех запросах. Удобно же, когда ошибки обрабатываются в одном месте? И сразу с таймаутами. Намерения благие. Но ими выложена дорога в ад. В таких ситуациях мы будем терять от 50 до 100 миллисекунд на каждый запрос. В сервисах, которые часто куда-то ходят по HTTP - это катастрофа.

Что же делать?

В нашем случае нужно создавать клиент httpx точно таким же образом, как мы создаем коннект к БД. Создавать клиент один раз в lifespan. И прокидывать готовый клиент как зависимость в другие компоненты (или например сразу в роут). И тогда сможем избежать дополнительных затрат по времени. И еще получить дополнительное ускорение за счет пулинга HTTP соединений.

Чего ждать?

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

Мораль?

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

Книжный биатлон

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

Для меня все изменилось на CrossConf 2024. Я поставил себе установку задавать максимально сложный вопрос, насколько это только возможно. На каждом докладе, независимо от его релевантности. Это стало моей целью нахождения в аудитории. Я записывал вопросы по мере выступления докладчика. Стирал, снова записывал - уже более интересные.

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

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

На фото - улов со вчерашнего Team Lead Today. Как и на многих конфах - давали книжку за лучший вопрос. Мне повезло - я выбил три, одну из которых сразу же подарил, так как выпал дубль 😁

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

Дорогие подписчики! Поздравляю вас с наступающим (а кого-то - с уже наступившим) Новым Годом! ❄️

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

В Новом Году хочется сделать акцент именно на вашем опыте. Написать про ваши истории успеха и ваши победы над инцидентами и техническим долгом.

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

Желаю вам зелёных пайплайнов и зелёных ёлок 🎄! Счастья, добра, безудержного роста во всём! 🎉

Как узнать вес коровы?

Один из рабочих способов - взять 800 человек, показать каждому одну и ту же корову. Попросить прикинуть вес коровы "на глаз". Записать ответ каждого респондента в книжечку и посчитать среднее.

Именно так и поступил сэр Фрэнсис Гальтон в 1906 году, проводя эксперимент с целью доказать, что мнение эксперта важнее и более правильно, нежели мнение менее опытного большинства. И доказал ровно обратное, открыв эффект под названием "мудрость толпы".

Тогда 800 человек не просто угадали лучше эксперта (мясника) - они угадали с точностью какую только могли гарантировать весы того времени. Ошибка составила всего 0.08%. Толпа ошиблась на 1 фунт.

Мудрость толпы - эффект очень интересный. Поскольку угадать можно не только вес коровы, но и практически что угодно. Важно лишь соблюсти 3 условия:

1. Независимость ответов респондентов. Если респонденты знают ответы друг друга - они начинают корректировать свои оценки и вся мудрость улетучивается .

2. Отсутствие предвзятости. Если респонденты слишком похожи друг на друга и уверовали в одно и то же - то их ответы (и вся картина в целом) будут искажены в сторону того, во что они уверовали.

3. Хотя бы какая-нибудь экспертность. Если респонденты выдают абсолютно случайные ответы - мудрость также улетучивается. Зато их можно использовать как идеальные ГСЧ (везде есть свои плюсы).

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

Совсем скоро расскажу - как и что мы угадываем (на покере и не только), а также - что не угадываем, но хотим попробовать угадать.

А пока предлагаю посмотреть - что угадывают другие люди, и насколько хорошо у них это получается - https://www.metaculus.com/.

Демократичный способ управления техдолгом

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

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

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

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

Более того - составили мы роадмап, например, на Q2. Но где гарантия, что все из этого сделаем? А если прилетит что-то горячее? А если горячее прилетит 2-3 раза подряд? Пересматривать наши наполеоновские планы?

Ответ вижу как раз таки - в коллективном угадывании. И в краткосрочном планировании.

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

Ранее мы уже говорили про управление рисками на примере доклада Алексея Грудина из WB&Russ. Мы использовали приоритезацию рисков. Здесь мы поступим похожим образом, но применительно не к рискам, а к уже имющимся проблемам, с которыми тоже нужно системно бороться.

По сути - мы собираем привычную покер сессию и грумим наш техдолг. Но оцениваем не трудоемкость, а приоритет.

Приоритет можно оценивать разными способами. Важно чтобы в финале получалось число. Как и в случае с рисками - мы ориентируемся на серьезность последствий (как сильно болит), вероятность реализации (как часто стреляет) и трудоемкость.

Можно прикидывать "в уме" соотношение этих трех параметров. Можно отдельно оценивать все три параметра по пятибалльной шкале и считать итоговое значение приоритета по формуле. Например - серьезность риска * вероятность реализации / трудоемкость.

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

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