Ответ
В такой ситуации я действовал проактивно, чтобы принести пользу команде и продукту, всегда согласовывая свои действия с тимлидом или продакт-менеджером. Мои типичные шаги:
-
Помощь команде:
- Code Review: Проводил более глубокий анализ открытых пулл-реквестов, уделяя внимание не только синтаксису, но и архитектуре, тестируемости и потенциальным edge-кейсам.
- Тестирование и баг-фиксинг: Подключался к тестированию новой функциональности, искал и документировал баги в бэклоге, либо брал в работу критические баги с высоким приоритетом.
- Парное программирование: Предлагал помощь коллегам, которые могли застрять на сложной задаче.
-
Работа с техническим долгом:
- Рефакторинг: Улучшал читаемость и поддерживаемость кода в модулях, с которыми недавно работал. Например, выделял повторяющуюся логику в отдельные методы или классы.
- Улучшение тестов: Повышал покрытие unit-тестами, писал интеграционные тесты для критичных сценариев, рефакторил "хрупкие" тесты.
// Было: простой тест [Fact] public void CalculateDiscount_ShouldReturnCorrectValue() { var result = Calculator.CalculateDiscount(100, 10); Assert.Equal(90, result); }
// Стало: параметризованный тест для покрытия граничных случаев [Theory] [InlineData(100, 10, 90)] [InlineData(100, 0, 100)] // Скидка 0% [InlineData(100, 100, 0)] // Скидка 100% [InlineData(0, 10, 0)] // Нулевая цена public void CalculateDiscount_EdgeCases(decimal price, decimal discountPercent, decimal expected) { var result = Calculator.CalculateDiscount(price, discountPercent); Assert.Equal(expected, result); }
* **Документация:** Обновлял README, комментировал сложные участки кода, документировал API. -
Подготовка к будущему:
- Исследование (Spike): Изучал новые библиотеки, подходы или фичи языка, которые могли бы быть полезны в предстоящих задачах. Создавал минимальный прототип для демонстрации идеи.
- Планирование: Углублялся в анализ требований к задачам из следующего спринта, чтобы начать работу с четким пониманием контекста.
-
Автоматизация и инструменты:
- Настраивал или улучшал pipeline CI/CD (например, добавлял этап анализа кода, кэширование зависимостей).
- Писал скрипты для рутинных операций (генерация данных, деплой, мониторинг).
Главный принцип — оставаться полезным и не создавать незапланированной работы для других, поэтому все активности, выходящие за рамки текущего спринта, всегда обсуждались с командой.
Ответ 18+ 🔞
А, ну это когда все задачи по спринту сделаны, а до ретро ещё как до Луны, да? Классика, блядь. Сидишь такой, вроде и свободен, но просто так хуярить в стену — не комильфо. Я обычно в такие моменты не жду, пока мне на голову сядут, а начинаю шастать по проекту, как голодный таракан по кухне.
Первым делом — команда. Смотрю, у кого пулл-реквесты висят, особенно большие. Залажу туда не просто галочку поставить, а реально въебусь с головой. Смотрю: а че это он тут накосячил с архитектурой? А где тесты на эти ебушки-воробушки? Edge-кейсы кто покрывать будет? Пишу развернутый коммент, не просто «исправь», а с вариантами решения. Если вижу, что чел встал в тупик — подхожу и предлагаю: «Давай на пару порешаем, а?». Часто быстрее выходит, чем ему одному биться.
Потом иду техдолг выкуривать. Проходишься по коду, в котором недавно копался, и понимаешь — тут же пиздец, а не модуль. Логика повторяется в трёх местах, тесты хрупкие как мои нервы после утреннего кофе. Беру и рефакторю по-тихому. Не глобально, конечно, а то продакт охуеет, а точечно. Или тесты дописываю — чтобы они не просто были, а реально от багов защищали. Вот смотри, как было и как стало:
// Было: простой тест
[Fact]
public void CalculateDiscount_ShouldReturnCorrectValue()
{
var result = Calculator.CalculateDiscount(100, 10);
Assert.Equal(90, result);
}
// Стало: параметризованный тест для покрытия граничных случаев
[Theory]
[InlineData(100, 10, 90)]
[InlineData(100, 0, 100)] // Скидка 0%
[InlineData(100, 100, 0)] // Скидка 100%
[InlineData(0, 10, 0)] // Нулевая цена
public void CalculateDiscount_EdgeCases(decimal price, decimal discountPercent, decimal expected)
{
var result = Calculator.CalculateDiscount(price, discountPercent);
Assert.Equal(expected, result);
}Видишь разницу? Теперь если кто-то передаст ноль или скидку в 100%, всё не посыпется. А то потом ночью разбудят — «всё упало!». Не, лучше я днём это предупрежу.
Ещё документацию навожу. Читаешь README, а там последний коммит — когда мамонта хоронили. Обновляешь. Или в коде встречаешь какой-нибудь зашкварный алгоритм, над которым час тупил — пишешь нормальный комментарий, чтобы следующий бедолага не ебал себе мозг.
Если совсем затишье, можно в будущее заглянуть. Смотрю, что в бэклоге нарисовалось на следующий спринт. Может, там новая библиотека нужна или подход? Быстренько гуглю, пишу прототип на коленке — чисто чтобы понять, насколько это вообще адекватная идея. Или в CI/CD пайплайне ковыряюсь — может, этап анализа кода добавить, или кэширование настроить, чтобы билды быстрее летали.
Но главное, блядь, правило — ничего не начинать втихушку, что может аукнуться другим. Перед тем как какую-нибудь свою инициативу в прод запускать, всегда иду к тимлиду или продакту и говорю: «Слушай, я тут пока свободен, хочу вот это и вот это подшаманить. Как думаешь, надо? Не сломаю ли я чего?». Потому что если начнёшь без спроса архитектуру перелопачивать, а потом окажется, что это никому не нужно, получишь по шапке, да ещё и команду подставишь. А нам это нахуй не сдалось.