He leído: Joel on Software de Joel Spolsky

Joel on Software El título completo del libro es ‘Joel on Software: And on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and Managers, and to Those Who, Whether by Good Fortune or Ill Luck, Work with Them in Some Capacity’, y la verdad es que es totalmente adecuado. Trata los temas más diversos relacionados con el desarrollo de software y es de interés para todos los diversos perfiles que trabajan en el desarrollo de software.

Si un blog he seguido con auténtica devoción en mis años de desarrollador a sido el de Joel Spolsky (www.joelonsoftware.com). Esto no tiene nada de particular pues probablemente se trate del blog más leído sobre desarrollo de software.

Este libro reúne los más destacados artículos que Joel ha publicado en su blog entre 2000 y 2004. Es un libro muy diferente a cualquier otro, especialmente diferente si se le compara con cualquier otro libro de informática. Nunca he leído un libro de informatico que toque, dentro de un tema común, aspectos tan variados. Esto convierte a este libro en sumamente facil de leer. Se lee con la avidez de no saber que tema vas encontrar diez páginas más allá. Esto le da al libro el dinamísmo de un libro de relatos breves. Se trata de el libro de informática más amenos que he leído junto con otro que también tenia la firma de Joel, aunque no fuese su autor: The Best Software Writing I de Joel Spolsky.

Es cierto que todos los temas tratados se tratan desde una componente profundamente subjetiva, pero eso es lo que más valor tiene, desde mi punto de vista, de este libro. Joel Spolsky atesora una experiencia nada desdeñable desarrollando software, dirigiendo equipos y gestionando su empresa de desarrollo. Y lo mejor de todo es que es capaz de trasmitir todo este conocimiento a través de historias reales o fabulas, según el tema lo requiera, que enganchan de principio a fin.

Hay miles de fuentes en las que beber a la hora de aprender sobre desarrollo de software, pero el blog de Joel, y por tanto este libro, es un lugar único a la hora de informarse sobre el desarrollo de software en un sentido amplio, que abarca desde cuestiones técnicas, pasando por aspectos relacionados con la gestión de proyectos (Top Five -Wrong- Reasons You Don’t Have Testers), la arquitectura del software (Don’t Let Architecture Astronauts Scare You), la gesitón de equipos (Interviewing -The Guerrilla Guide to Interviewing-) o la gestión de negocios relacionados con el software, hasta la más pura ingeniería del software. Especialmente destacable es ‘Getting things done when you’re only a grunt’, toda una guia para los miles de desarrolladores que se queman por la ineptitud o indolencia de sus jefes. Incluso se puede encontrar alguna joya de la ingeniería del software que debería ser estudiada en las facultades, artículos que transcienden lo que es un blog, y que deberían pasar a considerarse teoremas universales de la ingeniería del software: ‘The Law of Leaky Abstractions’, cuyo corolario podría ser: ‘Toda abstración tiene fugas’.

No faltará quien piense que no vale la pena gastarse el dinero que el libro cuesta por algo que se puede leer en internet y además en castalleno (el blog de Joel es traducido por voluntarios a un buen puñado de idiomas), yo creo que ha sido una gran inversión que me ha rentado horas de disfrute.

Es cierto que para el lector habitual de su blog nada resultará original, todo ha sido leído antes. Pero para los que pensamos que el papel sigue siendo el material en el que se saborean a fondo las historias, tener entre las manos este libro y poder doblar sus esquinas es un placer. Los blogs tienen eso en su contra, no te los puedes llevar a la cama, no puedes anotar sobre ellos, no puedes doblar las esquinas…

Si decidís comprarlo, no creo que lo lamentéis. Además es barato!!!

¿Quíen no ha necesitado alguna vez una excusa?

Descubro a través de Navegapolis, el imprescindible blog de Juan Palacio, un interesantísmo cuadro para generar escusas…


excusas_t


No deja de ser paradójico que a parte de ‘excusas’ que todos hemos usado en alguna ocasión, este cuadro ponga de relevancia un buen puñado de riesgos que encontramos en los proyectos día a día y que si no son atajados convenientemente inevitablemente van a suporner retrasos para nuestro proyecto.

¿Deben los test unitarios usar la base de datos?

ojoUna duda que me plantean habitualmente cuando hablo de testeo unitario en una charla o cuando trato de implantar el uso de esta técnica en un cliente es: ¿Deben los test unitarios usar la base de datos?

La respuesta ‘académica’ es NO. Pero la verdad es que en esto del software la única verdad absoluta es que las verdades absolutas son pocas… y está pregunta no escapa a esta máxima.

Con Team System y la edición para Database Professionals, el testeo unitario llego a los procedimientos almacenados, pero no es de este tipo de testeo, que evidentemente si que usa la base de datos, del que voy a hablar aquí. Este post trata sobre la conveniencia o no de que nuestros test unitarios de las capas de acceso a datos y de lógica de negocio se ejecuten con una conexión a una base de datos real establecida y con un juego de datos de prueba.

Los motivos por los que la respuesta académica es no, son claros: Es una premisa universalmente aceptada es que los test deben poderse correr en cualquier entorno, sin dependencias más que del propio framework de testeo elegido. Podéis repasar Beneficios y caraterísticas de un buen test unitario y de TDD, antes de contuniar leyendo si quereís conocer más de estas premisas. Se busca minimizar al máximo las dependencias externas de nuestros test. Debe evitarse por lo tanto, siendo puristas, el depender de la presencia de un servidor de base de datos para que nuestros test se ejecuten satisfactoriamente. Esto a menudo supone que para lograr los niveles de cobertura adecuados debemos recurrir al uso de ‘mock object’ (objetos que simulan la funcionalidad provista por la base de datos, en el caso en que nos ocupa o que simulan cualquier servicio externo requerido por el componente que testeamos). Crear los ‘mock objects’ es una tarea tediosa, que obtiene como recompensa la independencia respecto a recursos externos de nuestros test. Otra de las ventajas claras de usar ‘mock objects’ es que el rendimiento de nuestros test será alto. Al fin y al cabo los ‘mock objects’ no hacen nada de proceso.

Que nadie entienda que no doy importancia a la independencia respecto del entorno de los test. Es algo importante pero para mi no siempre es lo más importante. Lo más importante que, en mi opinión el testeo unitario aporta es la detección temprana de regresiones y de impactos no previstos en partes del software que no han sufrido cambios pero que se han visto afectadas por cambios en otras partes. Dicho esto, y en base a mi experiencia, mi recomendación suele ser, que, en sistemas guiados por datos, donde el almacenamientos de datos es una cuestión central, los test unitarios utilicen la base de datos.

Mi experiencia es que a menudo es necesario realizar refactorizaciones o cambios en la base de datos que son muy susceptibles de producir regresiones, introducir problemas de rendimiento o impactar en partes inesperadas de nuestro software. A menudo pequeños cambios en la base de datos que parecen inofensivos tienen un gran impacto. Solo si nuestros test unitarios actúan sobre la base de datos y no solamente sobre ‘mock objects’ seremos capaces de detectar de manera temprana estos problemas, con el ahorro de tiempo de desarrollo que esta detección temprana de los errores lleva aparejada.

Además, ¿qué mejor manera de probar el comportamiento de nuestra base de datos frente a bloqueos y su rendimiento que tener a varios desarrolladores corriendo a menudo test  que ejercitan el acceso a datos de manera concurrente?.

Que nuestros test unitarios ‘tiren’ de la base de datos, nos proporciona la ventaja de poder hacer cambios en nuestro esquema de datos con la confianza de que detectaremos los errores que estos cambios puedan introducir, pero también introduce una serie de problemas que tendremos que abordar:

Tenemos que garantizar que los tests en cualquier caso, se ejecuten o no de manera satisfactoria, dejarán la base de datos en el estado inicial. Nunca la ejecución de test unitarios debe cambiar el estado del sistema. Si respetamos esta máxima podremos utilizar nuestros test unitarios para detectar problemas en un sistema en producción sin temer que los datos reales sean dañados. Lograr que los test no cambien el estado de la base de datos es abordable, pero no sencillo, utilizando las posibilidades transaccionales del gestor de base de datos. Resumiendo: los test serán responsables de generar y limpiar los datos necesarios para que se ejecuten satisfactoriamente.

Otro problema que tenemos que abordar es que todos los desarrolladores deberán disponer de una versión actualizada de la base de datos de manera que puedan correr los test siempre contra la versión de la base de datos más actualizada. Esto no es difícil de conseguir en equipos pequeños y que están ubicados en un único emplazamiento, pero mucho más complejo si se trata de proyectos físicamente distribuidos.

Por último esta la cuestión del rendimiento. Que los test realmente tiren de la base de datos hace que sean más lentos que si tiran de ‘mock objects’. Una máxima del testeo unitario dice que los test deben ser rápidos en su ejecución, pues sino se dejan de correr a menudo y pierden su utilidad. Esto nos pone en la necesidad de ser más cuidadosos con el diseño de nuestros test para que su rendimiento sea adecuado.

En cualquier caso aunque el precio a pagar es alto: los test deben generar y limpiar los datos de test, tendremos que tener un servidor de bases de datos continuamente actualizado y debemos de estar atentos al rendimiento de los test, la detección temprana de los errores introducidos por cambios en el esquema de la base de datos y la comprobación temprana del rendimiento y el comportamiento frente a concurrencia de nuestra base de datos hace que el esfuerzo merezca la pena.