Code review в C#: что проверять и как давать обратную связь

Онлайн-тренажер Python для начинающих

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

Начать курс

Code review в C#: что проверять и как давать обратную связь

Code review — это не просто формальность, а один из ключевых процессов, обеспечивающих качество кода. Особенно это важно для проектов на C# и .NET, где высокая производительность, читаемость и соответствие современным стандартам играют решающую роль. В этой статье мы разберем, на что обращать внимание при ревью C#-кода и как давать обратную связь, чтобы она была полезной и конструктивной.

1. Архитектура и соответствие SOLID-принципам

Прежде чем смотреть на конкретные строки кода, оцените общую архитектуру. В C# это особенно важно из-за широкого использования ООП.

Single Responsibility: каждый класс и метод должны решать одну задачу. Если метод делает слишком много — это повод для ревью.
Open/Closed: проверьте, можно ли расширить функциональность без изменения существующего кода (например, через интерфейсы или абстрактные классы).
Dependency Injection: в .NET Core/5+ DI — стандарт. Убедитесь, что зависимости передаются через конструктор, а не создаются внутри класса.

// Плохо: нарушение SRP и DI
public class OrderService
{
    private readonly SqlConnection _connection = new SqlConnection("...");
    
    public void ProcessOrder(Order order)
    {
        // Логика валидации
        // Логика сохранения в БД
        // Логика отправки email
    }
}

// Хорошо: разделение на сервисы и DI
public class OrderService
{
    private readonly IOrderRepository _orderRepository;
    private readonly IEmailService _emailService;

    public OrderService(IOrderRepository orderRepository, IEmailService emailService)
    {
        _orderRepository = orderRepository;
        _emailService = emailService;
    }

    public void ProcessOrder(Order order)
    {
        _orderRepository.Save(order);
        _emailService.SendConfirmation(order);
    }
}

2. Безопасность и обработка ошибок

Безопасность — критическая часть любого приложения на C#. Обратите внимание на следующие аспекты:

SQL-инъекции: используйте параметризированные запросы или Entity Framework, а не конкатенацию строк.
Исключения: не глотайте исключения с пустыми catch. Логируйте ошибки и используйте finally для освобождения ресурсов.
Null-безопасность: в C# 8+ используйте nullable reference types. Проверяйте аргументы методов на null.

// Плохо: уязвимость к SQL-инъекциям
var query = "SELECT * FROM Users WHERE Name = '" + userName + "'";

// Хорошо: параметризированный запрос
var command = new SqlCommand("SELECT * FROM Users WHERE Name = @name", connection);
command.Parameters.AddWithValue("@name", userName);

Также проверяйте, что приложение корректно обрабатывает исключения на границах системы (например, в контроллерах ASP.NET Core).

3. Производительность и работа с памятью

C# — язык с автоматическим управлением памятью, но это не значит, что о производительности можно забыть. При ревью обращайте внимание на:

LINQ-запросы: избегайте множественных итераций по коллекциям. Например, .ToList() после каждого .Where() может серьезно замедлить работу.
Асинхронность: используйте async/await для I/O-операций, но не злоупотребляйте .Result или .Wait() — это может вызвать deadlock.
Пул объектов: для тяжелых объектов (например, подключений к БД) используйте пулинг, а не создавайте их каждый раз.

// Плохо: множественные итерации
var filtered = items.Where(x => x.IsActive).ToList();
var sorted = filtered.OrderBy(x => x.Name).ToList();

// Хорошо: одна цепочка
var result = items.Where(x => x.IsActive).OrderBy(x => x.Name).ToList();

Также проверяйте, что разработчик не использует string для больших конкатенаций в циклах — лучше использовать StringBuilder.

4. Читаемость и стиль кода

Код пишется для людей, а не для компилятора. Вот что стоит проверять:

Именование: используйте camelCase для локальных переменных, PascalCase для методов и классов. Избегайте сокращений.
Комментарии: не комментируйте очевидное. Комментарии должны объяснять почему, а не что.
Магические числа: выносите их в константы.

// Плохо: магическое число и плохое имя
var x = 3600 * 24; // что это?

// Хорошо: константа с понятным именем
private const int SecondsInDay = 86400;
var totalSeconds = days * SecondsInDay;

Также следите за длиной методов: если метод занимает больше 30-40 строк, его стоит разбить на несколько.

5. Как давать обратную связь: 5 правил

Техническая часть важна, но не менее важно как вы доносите свои замечания. Вот несколько рекомендаций:

Будьте конкретны. Вместо «этот код плохой» скажите: «В методе ProcessOrder нарушен SRP. Лучше вынести логику email-уведомлений в отдельный сервис».
Предлагайте решения. Если вы указываете на проблему, предложите хотя бы один вариант исправления.
Разделяйте критику и личность. Критикуйте код, а не разработчика. Вместо «ты написал плохой код» — «в этом блоке есть потенциальная проблема с производительностью».
Используйте «I» и «We». Вместо «вы должны исправить» — «я предлагаю рассмотреть такой вариант» или «давайте обсудим альтернативу».
Не затягивайте ревью. Если изменений много, разбейте их на несколько мелких PR. Это ускоряет процесс и снижает стресс.