Code review en C#: qué revisar y cómo dar retroalimentación a principiantes

Code review en C#: por dónde empezar y qué buscar

Code review (revisión de código) no es solo una formalidad, sino una herramienta poderosa para mejorar la calidad del proyecto y el crecimiento del equipo. Para los desarrolladores principiantes en C#, el proceso de revisar el código de otros a menudo genera miedo: «¿Y si paso por alto un error?», «¿Cómo le digo a un colega que su código es malo?». En este artículo, analizaremos en qué fijarse durante un code review en proyectos .NET y cómo dar retroalimentación para que lo escuchen y no se ofendan.

No hablaremos de cosas obvias como errores de sintaxis, que el compilador detecta. Nuestro objetivo es aprender a ver problemas de arquitectura, legibilidad y rendimiento, así como a formular observaciones correctamente.

1. Arquitectura y principios SOLID en C#

Lo primero que hay que verificar en el código C# es si cumple con los principios SOLID. Incluso en un método pequeño se puede ver una violación del principio de responsabilidad única (Single Responsibility).

Qué revisar:

• Tamaño de métodos y clases. Si un método tiene más de 20-30 líneas, probablemente está haciendo demasiado. Sugiera dividirlo en varios métodos privados.
• Inversión de dependencias. Las clases no deben crear sus dependencias con new. En su lugar, use inyección de dependencias (DI). Ejemplo de código malo:

// Mal: la clase crea su propia dependenciapublic class OrderService{    private readonly EmailSender _sender = new EmailSender();

    public void ProcessOrder(Order order)    {        // lógica...        _sender.SendEmail(order.CustomerEmail);    }}

La opción correcta es mediante interfaz y DI:

// Bien: la dependencia se inyectapublic class OrderService{    private readonly IEmailSender _sender;

    public OrderService(IEmailSender sender)    {        _sender = sender;    }

    public void ProcessOrder(Order order)    {        // lógica...        _sender.SendEmail(order.CustomerEmail);    }}

• Principio de sustitución de Liskov (LSP). Las subclases no deben romper el comportamiento de la clase base. Por ejemplo, si tiene una clase Bird con un método Fly() y crea Penguin : Bird, eso viola LSP porque los pingüinos no vuelan. Es mejor definir una interfaz IFlyable.

2. Manejo de errores y excepciones en .NET

En C# hay un potente sistema de excepciones, pero los principiantes a menudo lo usan incorrectamente. Durante un code review, preste atención a los siguientes puntos:

• Bloques catch vacíos. Código como catch (Exception) { } es una bomba de tiempo. El error se traga y nunca sabrá del problema. Siempre registre la excepción o reláncela.
• Excepciones demasiado generales. Capturar Exception es una mala práctica. Intente capturar tipos específicos: SqlException, InvalidOperationException, etc.
• Uso de excepciones para control de flujo. No use try-catch en lugar de if-else. Ejemplo de código malo:

// Mal: excepción como parte de la lógicatry{    int.Parse(userInput);}catch (FormatException){    Console.WriteLine("Formato inválido");}

La opción correcta es int.TryParse():

// Bien: verificación sin excepciónif (int.TryParse(userInput, out int result)){    // trabajar con result}else{    Console.WriteLine("Formato inválido");}

3. Rendimiento y gestión de memoria

Para los desarrolladores principiantes en C#, el tema del rendimiento a menudo pasa desapercibido. Sin embargo, el code review es un momento excelente para señalar construcciones ineficientes.

Problemas típicos:

• Excesivas