Тестов - недостаточно
Бенчмарков - недостаточно
Исключений - недостаточно

Время нескучных историй!

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

(какие то скучные нескучные истории)

А теперь она решает потестировать все в продакшене!

Повключать feature flag'и и посмотреть что случиться

так она может сравнить всякую всячину с кластером

А еще таким макаром можно включать фичи по частям и увеличивать сколько людей получают новые фичи!

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

Очень хочется знать откуда баг появился

Идея! Давайте тегировать error rate еще и build number'ом

В конце дня наш девелопер научилась тестировать в продакшене, смотреть в мониторинг и ваще стала лучше

(или нет, прим. записывающего человека)

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

А давайте посмотрим на http запросы! Иногда ведь помогает понять что нам возвращается мусор или не то что нужно!

Best Practices:
1. Структурированные данные
2. Именуем все в единой манере.
3. Пусть юзкейс диктует то как данные попадают в систему.

Например каждый рид реквест стоит интерументировать, а запись вот не очень

А еще можно добавлять временные поля если надо

например понадобилось нам - добавили количество горутин

перестало быть нужно - выкинули нафиг

Миссия девелопера:
- Не пишите код основываясь на интуции, соберите, блин, данные!
- Учитесь observability
- Пусть observability будет центром сбора данных