Refactorizar se ha convertido en una de las actividades más importantes para mantener un codigo sano, sobre todo en productos que llevan años en producción. En este artículo se explica qué es refactorizar, cuándo tiene sentido hacerlo y cómo introducirlo en tu flujo de trabajo sin frenar la entrega de nuevas funcionalidades.

Qué es realmente refactorizar

Refactorizar es cambiar la estructura interna del código sin modificar su comportamiento observable. El sistema debe seguir haciendo exactamente lo mismo, pero la implementación se vuelve más simple, más legible y más fácil de extender.

No es una reescritura completa desde cero, ni una excusa para introducir cambios funcionales disfrazados. Tampoco es “optimizar performance” porque sí. Es una actividad deliberada orientada a mejorar diseño, claridad y mantenibilidad.

Por qué refactorizar importa al negocio

Aunque la refactorización parezca una preocupación "técnica", su impacto real se ve en:

• Menor coste de mantenimiento: cambiar una parte del sistema es más rápido cuando el código es claro y está bien estructurado.

• Mayor velocidad para entregar features: una base de código limpia permite implementar nuevas funcionalidades con menos fricción.

• Menos bugs y regresiones: el código simple, con responsabilidades claras, es menos propenso a errores.

• Mejor experiencia del equipo: trabajar sobre un “código agradable” reduce frustración, rotación y facilita la incorporación de nuevas personas.

Al final, refactorizar es una forma de controlar la deuda técnica para que no se convierta en una bola de nieve que paralice el desarrollo.

Serilog es una de las librerias para manejar el loggeo en .NET mas conocida: aparte de ser muy flexible, siempre esta actualizada, hay muchos pluggins y soporta practicamente todas las versiones de .NET (tanto viejas como nuevas).

Yo la tengo en la API del blog, pero nunca la habia configurado, siempre la habia dejado como venia de fabrica.

Entre las cosas que mejore, es que me agregue desde que clase se esta produciendo el log: eso me viene espectacular para poder filtrar en Grafana lo que quiero ver. Por ejemplo, asi se ve un warning de LaunchDarkly, que uso para los flags:

{"Message":"\"Timed out\" sending \"2 event(s)\"; \"will retry after one second\"","MessageTemplate":"{0} sending {1}; {2}","0":"Timed out","1":"2 event(s)","2":"will retry after one second","SourceContext":"LaunchDarkly.Sdk.Events","Application":"Peorth.Blog.API","level":"warning"}

Como pueden ver, en la propiedad SourceContext se puede ver desde que Libreria viene el warning. Esto me permitio hacer una buena limpieza de un monton de eventos que no me servian para nada, y si veo algun error importante, puedo saber inmediatamente desde que clase viene.

Pero para hacer esto, no solo necesito Serilog, sino que tengo que hacer unas modificaciones en el codigo.

1. Primero instalar Serilog en la API
2. En el appSettings.json, debemos configurar el template que queremos usar para nuestros mensajes:

{
  "Serilog": {
    "Using": [ "Serilog.Sinks.Console" ],
    "MinimumLevel": {
      "Default": "Information"
    },
    "Enrich": [ "FromLogContext" ],
    "WriteTo": [
      {
        "Name": "Console",
        "Args": {
          "outputTemplate": "[{Timestamp:HH:mm:ss} {Level:u3}] [{SourceContext}] {Message:lj}{NewLine}{Exception}"
        }
      }
    ]
  }
}

La parte importante es el outputTemplate, y principalmente, el SourceContext, junto con el Sink (donde va a escribir el log basicamente). Para AWS Lambda, cuando la app en .NET escribe a la consola, se manda automaticamente a Cloudwatch (siempre y cuando tengas permisos para escribir ahi, claro esta).

3. En nuestro Program.cs, debemos agregar la llamada para poder registrar Serilog como nuestro logger por default. Esto es importante, porque tambien registra las clases ILogger<T> que vamos a usar al hacer DI

var loggerConfig = new LoggerConfiguration()
				.ReadFrom.Configuration(configuration);
Log.Logger = loggerConfig.CreateLogger();
...
serviceCollection.AddLogging(builder => builder.AddSerilog(Log.Logger));

4. Ahora en nuestras clases, en vez de inyectar el Serilog.Log o ILogger (solo), debemos cambiarlo para que inyecte ILogger<T> donde T es nuestra clase. Por ej, si tenemos un servicio de search, hariamos ILogger<SearchService> o algo por el estilo. Al hacer esto, automaticamente Serilog va a imprimir en el SourceContext la palabra "SearchService", haciendo que sea facil desde que clase se escribio el log.

PD: Lean el site de loggingsucks.com, es excelente si quieren mejorar su logs 😊

AWS esta siendo mucho mas rapido en implementar los frameworks de .NET en AWS Lambda, y acaba de anunciar que ya se puede usar .NET 10 como managed runtime y como container images.

Aparte de las mejoras de performance que tiene .NET 10 de las que ya hablamos, tambien viene con soporte para File-Based applications, que es la posibilidad de tener TODO en un solo archivo .cs, sin necesidad de tener .csproj u otros archivos. Esto es algo muy bueno para funciones serverless sencillas que podamos necesitar.

Voy a ver si puedo migrar el blog de .NET 8 a .NET 10, y les cuento que tal me fue en algun post 😊

Pueden leer mas informacion en el post oficial del blog de AWS: .NET 10 runtime now available in AWS Lambda