El Libro

Sinopsis:

¿Dedicas una gran parte de tu tiempo de desarrollo a resolver incidencias de aplicaciones en producción?, ¿te enfrentas a sesiones de depuración interminables para encontrar la raíz de un problema?, ¿te extenúa descubrir innumerables fallos cada vez que introduces nuevas características a funcionalidades ya existentes?. Si respondes afirmativamente estas cuestiones y quieres promover el cambio, en este libro encontrarás la clave.

TDD es una técnica de desarrollo que se lleva aplicando durante años con gran éxito en lugares como EEUU y Reino Unido, sin embargo, la ausencia de información en español sobre la misma ha supuesto un freno para su difusión en los países hispano-parlantes. El objetivo de este libro es poner solución a este dilema y ofrecer una referencia completa, tanto teórica como práctica, que permita al lector iniciarse en su comprensión y aplicación.

Escrito por Uncle Bob

Traducido por el grupo de contenidos de agile-spain

Artículo Original

Últimamente hay un interes creciente por las Katas de Software. ¿Qué es todo este ruido, y por qué puede ser importante?

Hace varios años Dave Thomas (Pragmatic Programmer) inició un blog especial sobre la programación de katas. La idea era simple: los profesionales practican.

Quizás no se te había ocurrido antes, pero es evidentemente cierto por sí mismo. Los músicos profesionales practican. Los bailarines profesionales practican. Los médicos practican. Los soldados practican. De hecho, cualquier tipo de artesano profesional debe practicar el oficio que ejerce a fin de desarrollarlo bien a la hora de la verdad.

El punto de Dave fue que los programadores profesionales necesitan practicar como cualquier otro profesional. Estableció una serie de sencillos ejercicios y problemas que los programadores podían resolver durante su tiempo de práctica. También sugirió que el tiempo de práctica debía ser planificado y protegido como parte de la rutina normal de un desarrollador de software.

Escrito por Martin Fowler
Traducido por Carmen Vidal ( Paradigma Tecnológico)

¿Es el cambio de interfaz de parte del código una refactorización?

La respuesta a esta pregunta es bastante simple - el cambio de un interfaz es una refactorización que genera un cambio en todas las llamadas. Un gran ejemplo de esto es RenombradoDeMétodo, que es una refactorización de cambio de interfaz presente en la mayoría de herramientas de refactorización.

El cambio de todas las llamadas es una parte esencial de esta refactorización. Solamente el cambio de una declaración de interfaz romperá el sistema - y consecuentemente no es un comportamiento que conserve el cambio.

Las refactorización de cambio de interfaz asumen que se puede conseguir el mantenimiento de todas las llamadas, y esto es porque se tiene que ser mucho más cuidadoso con los InterfacesPublicados. Con un interfaz publicado, el interfaz sí mismo es la parte del comportamiento observable del sistema.

Los lenguajes dinámicos pueden hacer estos cambios mucho más difíciles. La mecanografía estática realmente ayuda aquí a controlar exactamente qué interfaz es llamado en varios puntos. Las llamadas reflexivas también pueden ser más difíciles de encontrar, bien integrando nombres de método en cadenas o componiéndolas en tiempos de ejecución. Esto es otra área donde las pruebas son esenciales incluso en los entornos que tienen instrumentos de refactorización.

¿Debo capturar o relanzar esta excepción? Si la lanzo, ¿debo imprimir una traza de log también? ¿Qué implicaciones tiene lanzar una excepción dentro de una transacción?

Si te has hecho preguntas similares a estas alguna vez te gustará el artículo Exception-Handling Antipatterns publicado hace unos días en Java.net en el que se tratan los principales casos de tratamiento de excepciones.

Escrito por Martin Fowler
Traducido por Rafael Vacas
Revisado por Jorge Ferrer

Uno de los elementos comunes de los métodos ágiles es que otorgan a la programación un papel central en el desarrollo de software – mucho más de lo que la ingeniería del software suele hacer. Para esto es necesario considerar el código como la principal documentación de un sistema software.

Casi de inmediato siento la necesidad de refutar un malentendido muy común. Tal principio no quiere decir que el código sea la única documentación. Aunque a menudo se dice esto de la ProgramacionExtrema, nunca lo he oído decir a los líderes de éste movimiento. Generalmente, se necesita documentación adicional como complemento al código.

La razón por la que el código es la fuente principal de documentación se debe a que es la única lo suficientemente detallada y precisa como para ocupar este rol - un punto explicado elocuentemente por Jack W. Reeves en su famoso ensayo "¿Qué es Diseño?".