Clean Code

Abre un archivo que no existe en Python y open() lanza un FileNotFoundError que sube por la pila de llamadas hasta salir de tu función. Haz lo mismo en Go y os.ReadFile te devuelve un valor error junto a un slice de bytes nil. El mismo fallo, dos formas de código completamente distintas a su alrededor. La diferencia no es cosmética: decide si quien llama puede ignorar el fallo por accidente, y si el compilador se da cuenta cuando lo hace. ...

Una clase que guarda un usuario en la base de datos, le manda un correo de bienvenida y da formato a un recibo: basta un cambio para romper dos funcionalidades que no tienen nada que ver entre sí. Tocas la plantilla del correo y arriesgas la escritura en la base de datos. Tocas el diseño del recibo y arriesgas el correo. SOLID son cinco reglas que atacan ese tipo de enredo desde ángulos distintos, y comparten una idea: una clase debe cambiar por un solo motivo, y el resto del código debe depender de lo que algo promete hacer, no de cómo lo hace. ...

Aquí tienes una clase que no puedes probar con un unit test sin una base de datos real y un servidor SMTP funcionando: 1 2 3 4 5 6 7 8 9 10 11 public class OrderService { private readonly SqlOrderRepository _repository = new SqlOrderRepository("Server=prod-db;Database=Orders;..."); private readonly SmtpEmailSender _emailSender = new SmtpEmailSender("smtp.company.com"); public void PlaceOrder(Order order) { _repository.Save(order); _emailSender.Send(order.CustomerEmail, "Order confirmed"); } } OrderService construye su propio SqlOrderRepository y SmtpEmailSender con new, con la connection string incluida. Cada test que toca PlaceOrder necesita una base de datos Orders real y un servidor de correo real, o falla antes de que se ejecute tu assertion. La lógica que quieres probar son dos líneas: guardar el pedido, enviar la confirmación. Está soldada a dos clases concretas que no puedes cambiar. ...

Abres una función para arreglar un bug de una línea y cuarenta minutos después sigues rastreando qué rama asigna qué variable. Tres tareas que no tienen nada que ver entre sí están soldadas en un solo bloque, y ninguna tiene nombre. Tiras de un hilo y no puedes saber cuáles otros se mueven. Eso es spaghetti code, y el nombre no tiene nada que ver con la indentación ni el estilo de nombres. Describe el flujo de control: la ejecución salta entre condiciones como un fideo que cruza todos los demás en el plato, y seguir un solo camino hasta el final significa tener cuatro niveles de if en la cabeza a la vez. ...