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?".

Escrito por Martin Fowler
Traducido por Carmen Vidal
Revisado por Jorge Ferrer
Una base de datos en memoria (también denominada base de datos embebida) es una base de datos que corre completamente en la memoria principal, sin utilizar el disco duro. Por lo general, es creada cuando un proceso comienza, se ejecuta embebida dentro del proceso, y es destruida cuando el proceso termina.

A primera vista una idea tan bestia parece ridícula. Los dos objetivos principales de la mayor parte de bases de datos son persistir la información entre invocaciones del proceso y manejar el acceso concurrente a datos entre procesos. Las bases de datos en memoria no cumplen ninguno de estos objetivos – ¿ Cuál es su utilidad?

El caso más común en el que las he usado recientemente es para pruebas. Cuando se desarrolla una aplicación empresarial, las pruebas que atacan a la base de datos pueden consumir mucho tiempo cuando se ejecutan las baterías de pruebas. En estos casos, emplear una base de datos en memoria puede tener un efecto de un orden de magnitud que reduce tiempos de construcción radicalmente. Ya que a la mayor parte de los ThoughtWorkers se les da un aviso si no han tenido una barra verde recientemente, esta arquitectura es un hecho diferenciador.

Una de las prácticas común a las metodologías ágiles es escribir código fácilmente mantenible. Una gran frase al respecto es Cualquier desarrollador puede escribir código que una máquina pueda entender, pero sólo los buenos desarrolladores saben escribir código que otro desarrollador sepa entender.

Pues bien, según Roedy Green esta teoría está equivocada. Si te has encontrado casos de nombres de variables de una sóla letra, métodos con nombres tan explicativos como doIt, handle, etc., uso de la notación húngara, comentarios camuflados o líneas de código que no hacen nada, entonces su desarrollador estaba siguiendo los consejos para escribir código inmantenible que le asegurarán ser siempre imprescindible. Una lectura muy recomendable ;)