5 errores comunes en C# que hacen que su software sea imposible de mantener - Explicado por Derek Comartin

1. Falta de propiedad sobre el estado

Derek comienza identificando el error de permitir que varios límites o servicios actualicen datos compartidos sin una propiedad clara. Utiliza un ejemplo en el que el sistema de facturación llega a otra parte de la aplicación y cambia el estado. Esto da lugar a problemas de coherencia de los datos, sobre todo cuando ese objeto reside en una ubicación diferente dentro del sistema.

Este tipo de enfoque de "todos contra todos" crea errores en los que los desarrolladores preguntan: "¿Por qué este dato es incorrecto?" o "¿Quién lo cambió?" Derek insiste en que hay que definir la propiedad. Cada parte del sistema debe exponer una API o método bien definido - responsable de la gestión del estado.

En lugar de permitir que cualquier parte de la aplicación modifique los datos compartidos, Derek sugiere crear comandos y consultas explícitos. Por ejemplo, cuando se desea actualizar un envío, se emite un comando a través de una interfaz específica. Esto proporciona estructura y evita fugas de recursos por cambios no rastreables.

2. Código implícito frente a flujos de trabajo explícitos

Según Derek, muchos sistemas dependen en gran medida de las operaciones CRUD (Create, Read, Update, Delete), pero esto da lugar a flujos de trabajo implícitos. El código es técnicamente funcional pero le falta claridad sobre lo que hace. Si su clase solo admite operaciones genéricas, el flujo de trabajo empresarial real queda oculto.

Tomemos el siguiente ejemplo: un conductor recoge un paquete y se genera un conocimiento de embarque. Si el sistema sólo ejecuta UpdateShipment, no está claro si el cambio de cadena (como el número de BOL) se debe a una recogida o a una corrección. Derek señala que deberíamos sustituir las actualizaciones imprecisas por operaciones explícitas como PickupStopLoaded.

El resultado es un código más legible. También ayuda en la gestión de excepciones, ya que cuando se produce una excepción ex, la traza de la pila indicará claramente qué operación falló. Los métodos explícitos también ayudan a mejorar los estándares de codificación, ya que cada función tiene una única responsabilidad.

3. Añadir indicaciones inútiles

Derek pasa a la indirección: la inserción de capas innecesarias entre el método de llamada y el de destino. Lo ilustra con conexiones a bases de datos. Un controlador puede llamar a un servicio, que llama a un ayudante, que llama a otro servicio, que finalmente ejecuta la consulta a través de Entity Framework.

Esta pirámide de abstracciones dificulta la localización de problemas y la mejora del rendimiento. Aunque crear abstracciones puede ser útil, como envolver interfaces IDisposable para una mejor gestión de los recursos, Derek advierte que no hay que exagerar. Pregúntese si su abstracción simplifica la API, o si sólo está ocultando una dependencia de terceros que sólo existe en un lugar.

En lugar de poner capas por poner capas, Derek sugiere gestionar directamente el acoplamiento. La indirección excesiva no sólo desordena el código, sino que también aumenta la posibilidad de fugas de memoria y debilita los beneficios de la recolección de basura.

4. Jugar al "Y si..."

El siguiente error que identifica Derek es prepararse para casos de uso hipotéticos que puede que nunca se produzcan, lo que él llama el "What-If Game" Muchos desarrolladores de C# escriben clases y funciones flexibles para tener en cuenta necesidades futuras. Por ejemplo: "¿Y si necesitamos dar soporte a dos idiomas?" o "¿Y si necesitamos cambiar de tecnología?"

Derek advierte de que esta mentalidad conduce a frameworks hinchados y código demasiado genérico. Menciona que se encuentra con lógica de concatenación de cadenas y envolturas de tipos de referencia que nadie entiende porque solo sirven para un caso de uso real.

En lugar de prepararse para lo desconocido, Derek aconseja centrarse en los requisitos reales. Cada método y variable debe servir a un propósito actual y justificado. Las funciones no utilizadas solo añaden costes de mantenimiento. Como dice Derek, no se trata sólo del tiempo de desarrollo, sino del coste de propiedad. Si tu implementación pública de bool Equals, por ejemplo, cubre todos los casos extremos que puedas imaginar, pero ninguno que ocurra realmente, habrás perdido un tiempo valioso.

5. No gestionar correctamente los flujos de trabajo

Por último, Derek comenta el error de tratar los flujos de trabajo como bloques de procedimientos en lugar de pasos modulares. Utiliza un ejemplo real: hacer un pedido en línea. Una vez que el usuario completa el pago, el sistema realiza el cargo en la tarjeta de crédito y envía un correo electrónico de confirmación.

Si falla un paso -por ejemplo, el proceso de pago-, ¿cómo reacciona su código? ¿Se puede anular el pedido? ¿Mostrar un error? ¿Enviar un correo electrónico de error? Derek explica que agrupar todo esto en un solo bloque crea una complejidad inmanejable.

Recomienda diseñar los flujos de trabajo como unidades pequeñas y aisladas que se comunican a través de mensajes. El uso de operaciones Task async y yield return facilita la gestión de estos pasos. Además, el uso de la sentencia using y del bloque using en torno a recursos externos como el acceso a archivos o las conexiones a bases de datos puede ayudar a evitar fugas de memoria.

Por ejemplo, un bloque using alrededor de un flujo garantiza que se elimine correctamente, un punto vital cuando se trabaja con interfaces IDisposable. Cuando los flujos de trabajo se vuelven complejos, estas mejores prácticas garantizan que las excepciones se detecten y gestionen de forma eficaz, preservando el rendimiento y la capacidad de mantenimiento.

Envolviendo: Escribir código limpio y mantenible

Como concluye Derek en su vídeo a las 12:45, reflexiona sobre estos errores no sólo como cosas que ha visto, sino también como cosas que ha cometido personalmente mientras construía grandes sistemas empresariales. Se trata de lecciones aprendidas a través de la experiencia, y anima a los espectadores a compartir sus propios errores en los comentarios.

Los consejos de Derek se aplican no solo a C#, sino también a muchos otros lenguajes. Tanto si trabajas con comparaciones de cadenas, métodos Equals() o diseñando nuevas funciones, la clave está en la claridad, la intención y el mantenimiento del código.

Si estás interesado en mejorar tus habilidades en C# y evitar estos errores comunes, el canal de Derek ofrece muchos recursos gratuitos sobre arquitectura de sistemas, patrones de diseño y consejos sobre el lenguaje de programación en el mundo real. Evitar uno solo de estos errores puede mejorar significativamente la calidad de tu proyecto.

Así que, la próxima vez que empieces a escribir código, recuerda las palabras de Derek y pregúntate: "¿Estoy haciendo esto más complejo de lo necesario?"

Para más contenido como este, echa un vistazo al canal de YouTube de Derek Martin CodeOpinion.