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

При принятии рискованного решения в пользу скорости или качества я оцениваю несколько ключевых факторов:

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

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