¿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.
Alberto Gutierrez comparte una interesante reflexión sobre cómo crear el mejor sistema de gestión de errores: ¡dejar de reportar errores y empezar a escribir pruebas automatizadas!
¿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.
Dando vueltas por ahí me encuentro con un divertido post en el blog de Alan Shalloway, en donde el autor desvaría brevemente sobre el problema de la redundancia en el código, llegando así a dos simpáticos postulados, nombrados en su propio honor. Veamos...
La micro-optimización es una de las malas prácticas que pueden encontrarse en cualquier proyecto. La micro-optimización es una respuesta errónea a problemas potenciales o reales en un proyecto, aparece cuando el equipo falla en identificar la causa raíz y se enfoca en solucionar las consecuencias. Esto suele ocurrir por:
El objetivo de refactorizar y reescribir es "limpiar" el sistema mediante la mejora de la legibilidad, estructura y la claridad del código. Un código limpio es más fácil de mantener y mejorar. Sin embargo, en muchas ocasiones los equipos pasan en cierto tiempo decidiendo entre los dos enfoques.
Michael Dubakov sugiere las siguientes razones por las qué el código se deteriora con el tiempo:
Me encanta escribir títulos llamativos, especialmente cuando, como este, tienen un significado importante que no es evidente al principio. Una de las definiciones de arquitectura de Ralph Johnson es "La arquitectura trata sobre las decisiones que deseamos se tomen bien al principio del proyecto". ¿Por qué las personas sienten que necesitan hacer algunas cosas desde el principio del proyecto? Por supuesto, la respuesta es porque perciben que algunas cosas son difíciles de cambiar. Entonces podríamos terminar definiendo a la arquitectura como "las cosas que las personas perciben como algo difícil de cambiar".
Hace un tiempo me crucé con mi colega Dave Rice, y él estaba bastante enojado. Mi breve pregunta ocasionó una respuesta violenta: "No deberíamos entrevistar a nadie que dice ser 'arquitecto' en su currículum". Al principio me puso incómodo, porque usualmente presentamos a Dave como nuestro arquitecto líder...
Hace unos meses que no participo con notas en el sitio, esto se debe primero al nacimiento de Nico, mi tercer hijo y luego a una inminente y complicada decisión y mudanza al fin. Recién esta semana estoy volviendo a tener la cabeza despejada, y aunque el reader explota y por raro que parezca, no encuentro la nota que me guste mucho, eso debe ser que ahora me fui al extremo de no pensar en nada....
Bueno, les dejo aquí algo que me agrado y es un buen aspecto desde donde ver las pruebas unitarias automatizadas y explicarselas a los gerentes en términos monetarios.
Alberto Gutierrez nos comparte su punto de vista sobre lo que es la característica fundamental del Buen Código: la simpleza. El código simple es fácil de leer y fácil para cambiar. Y como es simple, es menos propenso a errores (mientras más complejo sea el algortimo que creamos, más probable que nos equivoquemos).
Como dicen: "No hay problemas dificiles, sólo soluciones difíciles". Así que cuando nos pongamos a escribir código tengamos presente los siguientes 7 consejos.
¿Qué es lo importante al momento de encarar un desarrollo ágil de software? Keith Swenson nos deja una compilación de 26 consejos que recolectó durante los años, sobre diversos temas.
