Финал: софт-скиллы и поведенческие кейсы (STAR)

STAR: Situation → Task → Action → Result. Главная ошибка — застрять в Situation и не дойти до Action.

1. Критика на код-ревью

Реальный кейс: PR #31431 в helm/helm (mustToToml). Мейнтейнер не согласился с подходом.

• S: предложил, чтобы toToml не роняла шаблон при ошибке, а тихо возвращала сообщение об ошибке. Не согласился.
• T: либо отстоять версию, либо перестроить так, чтобы устроило обоих.
• A: разделил задачу — бесспорную часть (новый строгий mustToToml, как уже есть mustToYaml/mustToJson) вынес в отдельный PR #31957, спорную (менять поведение toToml) оставил для дальнейшего обсуждения.
• R: #31957 смёржили быстро — критика архитектуры не заблокировала бесспорную часть работы.

2. Факап

Реальный кейс: в Avito.Кухне CreateOrder при невалидном fulfillment_type возвращал 409 invalid_transition вместо 400 invalid_fulfillment_type. Найден на ревью, не тестами.

• S: существующие тесты (happy-path, "не хватило остатка") этот вход не покрывали.
• T: признать причину — не тест не поймал, а я не подумал про этот вход.
• A: локализовал вход, завёл отдельную ErrInvalidFulfillmentType → 400 вместо переиспользования ErrInvalidTransition, синхронизировал с OpenAPI-схемой.
• R: класс багов закрыт как правило — каждая новая доменная ошибка получает свой HTTP-код.

3. Непонятное ТЗ

• S: [впиши своё — например: бизнес-сценарии в тестовом заданы общими словами].
• T: не молчать и не заваливать вопросами то, что можно решить самому.
• A: вёл DECISIONS.md (реальная практика в Avito.Кухне) — вопрос → варианты → выбор → почему. Это разделяет "решил сам" и "нужно уточнение у лида".
• R: [впиши своё].

4. Сжатые сроки

Реальный кейс: в Avito.Кухне переход с HTTP push+callback на Kafka по запросу на пересмотр архитектуры.

• S: рабочая HTTP-версия уже была готова, пришёл запрос пересмотреть под другие требования к надёжности.
• T: честно оценить, закрывает ли новая версия больше рисков, и успеть её сделать.
• A: назвал trade-off вслух: HTTP проще, но требует ручной реконсиляции при недоступности; Kafka сложнее, но даёт durable-очередь. Приоритет — сначала гарантия доставки (transactional outbox), DLQ потом.
• R: переписался только транспорт, домен и usecase-слой не тронуты — уложился в срок.

Чек-лист перед созвоном

• На каждый кейс — реальный пример или продуманный [впиши своё].
• В каждом ответе есть отдельное предложение-Result с числом/фактом.