No escribo pruebas unitarias porque... (manual de excusas)
- Detalles
- Publicado: Martes, 17 Agosto 2010 12:07
Siendo alguien que vive los beneficios de hacer TDD, creo profundamente en el desarrollo guiado por pruebas. Esta práctica agrega un nuevo nivel de calidad y madurez al desarrollo de software, y sin embargo todavía no es la técnica más usada en los proyectos de software. Cuando hay que elegir entre características, tiempo y calidad, siempre sufre la calidad. No queremos agregar tiempo extra para hacer pruebas, y tampoco queremos comprometer las características que vamos a entregar. Si no se pusieron como objetivo hacer TDD al iniciar el proeycto, es dificil hacerlo después.
Hay muchísimas prácticas que podemos adoptar para mejorar la calidad de nuestro código. ¿Por dónde empezar? ¿Existe una lista única y completa? En este artículo veremos un pequeño listado de buenas prácticas, que nos pueden ayudar a comenzar ese largo camino que implica trabajar con más profesionalismo, mejorando los productos que desarrollamos.
Se ha hablado mucho en los últimos años sobre los ESB, los web services y el fenómeno SOA en general. 
¿Cuál es la diferencia entre ser inteligente o ser tonto? Creo que podría resumirse en dos cosas: qué tan lejos en el futuro podés pensar, y qué tan rápido podés generar este pensamiento. Cuando alguien juega ajedrez, o poker, sus habilidades están determinadas por cuántas movidas puede pensar por adelantado. Cuánta historia pueden recordar, y así planificar el siguiente movimiento.
En nuestro trabajo con clientes a menudo tenemos discusiones sobre la función de la arquitectura y el rol de los arquitectos. Estas discusiones ocurren porque la arquitectura no contribuye de forma visible a los objetivos organizacionales, y por lo tanto se la percibe como una molestia para los proyectos. Muchas discusiones se origina por la falta de entendimiento sobre el rol y el lugar de los arquitectos dentro de la organización. Hemos definido tres objetivos de la función de la arquitectura en organizaciones de TI: Las Tres C de la Arquitectura. Estas son: Conexión, Cohesión y Cambiabilidad. Al tomar estos conceptos como principios básicos de la arquitectura logramos enfocarnos en qué hacer y cómo posicionar a la arquitectura dentro de la organización.
Hoy en día tenemos muchas herramientas que dicen limpiar de forma mágica nuestro código. Mueven, modifican, emprolijan y mágicamente resuelven todos nuestros problemas. Lamentablemente, como la mayoría ya sabe, escribir buen código lleva trabajo. No existen herramientas mágicas que puedan salvarnos (y no importa lo que nos digan los vendedores), pero si hay una herramienta que funciona muy bien para ayudarnos a mantenernos en forma.
El 
Como desarrolladores, nuestro entregable es el código fuente, es lo que producimos, y por lo tanto debemos hacer que se vea bien. Pero, ¿qué significa "bien"? ¿Cómo debería verse? Podríamos armar debates interminables sobre el tema, y los resultados nos desilusionarían. No existe algo como el Mejor Estilo De Codificación.
¿No estaría bueno si, una vez que termináramos una historia, nunca tuviéramos que volver a agarrarla? Esta es la idea detrás del "terminado terminado". Una historia no es un desparramo de código sin integrar, sin probar. La historia debe estar lista para ser desplegada.
Los sistemas de gestión de errores (o "bug trackers") son cuellos de botella, y perpetúan el continuo idea y vuelta entre testers y desarrolladores, además de requerir de mucha documentación para mantenerlos.
¿Qué es el código "testeable"? ¿Cómo saber si mi código es testable o no? En los equipos ágiles se habla mucho sobre asegurarse de construir código testable, pero ¿qué significa exactamente? John Boal nos ayuda a definir este concepto con más precisión.