Больше кодишь или ревьюишь на работе?

Баланс между написанием кода и код,ревью на Senior/Lead позиции

На позиции Senior C# Backend разработчика с опытом 10+ лет баланс смещается от чисто писательской деятельности к комплексной инженерной работе, где код,ревью занимает существенную, а иногда и преобладающую часть времени. В моей текущей практике это соотношение примерно 40% кодирования / 60% ревью, архитектурного анализа и менторства.

Почему ревью выходит на первый план?

Это не просто проверка синтаксиса, а критически важный процесс обеспечения качества и распространения знаний.

1. Масштабирование качества и знаний: Одна из моих ключевых задач — не только писать хороший код самому, но и помогать всей команде делать это. Тщательное ревью позволяет:

    *   **Обнаружить архитектурные антипаттерны** на ранней стадии (нарушение **SOLID**, неправильное использование паттернов, сильную связанность).
    *   **Предотвратить потенциальные баги** и проблемы с производительностью (неэффективные запросы к БД, утечки памяти, блокировки в многопоточном коде).
    *   **Распространить лучшие практики** (использование современных возможностей C# и .NET, корректное применение async/await, работу с **null**, безопасность).

1. Пример глубокого ревью, а не поверхностной проверки:

    Вместо комментария "Исправь код", ревью часто выглядит так:

```csharp
// Было в PR:
public class OrderService
{
    private readonly IRepository _repo;
    public OrderService(IRepository repo) => _repo = repo;

    public async Task ProcessOrder(int orderId)
    {
        var order = await _repo.GetOrderAsync(orderId);
        // ... много логики ...
        order.Status = OrderStatus.Processed;
        // Проблема: сохранение в середине метода, смесь ответственностей.
        await _repo.SaveAsync(order);

        // Следующая логика отправки уведомления зависит от успешного сохранения.
        await _notificationService.SendAsync(order);
    }
}
```

```csharp
// Мой комментарий в ревью с объяснением:
/*
## Архитектурное замечание

Метод `ProcessOrder` нарушает **принцип единственной ответственности (SRP)** и скрывает транзакционную границу.

1. **Проблема:** Если `SendAsync` выбросит исключение, заказ уже будет сохранен с статусом `Processed`, что может привести к несогласованности данных.
2. **Решение:** Инкапсулируйте логику изменения заказа и его сохранения в отдельный **Domain Service** или **Unit of Work**. Метод `ProcessOrder` должен координировать высокоуровневую операцию:
    - Открыть транзакцию (явно или через `DbContext`).
    - Выполнить все изменения.
    - Сохранить разом.
    - Отправить уведомление (возможно, через асинхронную очередь, чтобы не блокировать бизнес-Mтранзакцию).

Предлагаю рассмотреть паттерн **Command Handler** или явное использование `ITransaction`.
*/
```

3. Обучение и менторство: Ревью — это диалог. Для джуниоров и миддлов я подробно объясняю, почему нужно изменить код, ссылаясь на принципы чистого кода, документацию .NET или наш внутренний гайдлайн. Это мощнейший инструмент роста команды.

Когда и как много я пишу код сам?

Мое личное кодирование сконцентрировано на сложных задачах, где требуется глубокая экспертиза:

• Проектирование и реализация ключевых модулей: Например, разработка высоконагруженного фонового сервиса на BackgroundService или IHostedService с правильной обработкой отмены (CancellationToken) и устойчивостью к ошибкам.
• Архитектурные прототипы (Proof of Concept): Когда команда выбирает новую технологию (например, переезд с MongoDB Driver на Marten для событийно,ориентированной архитектуры), я создаю рабочий пример, чтобы доказать жизнеспособность и задать стандарты.
• Рефакторинг критических участков: Улучшение legacy,кода, внедрение медиаторов (MediatR), разделение монолитных методов.
• Сложная бизнес,логика: Реализация алгоритмов или специфичных доменных правил, где важно избежать ошибок.

Вывод

Соотношение в пользу ревью — это естественная эволюция роли. Моя основная ценность для компании и команды теперь заключается в умножающем эффекте: через ревью, архитектурные решения, планирование и менторство я влияю на качество и скорость работы 5-10 разработчиков, а не только на свой собственный код. Однако я сознательно сохраняю значительную личную практику написания кода, потому что:

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

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