El problema con el code coverage

Me he permitido el lujo de parafrasear a los maestros en el título de este artículo para hablaros de un tema algo polémico, por lo menos en los círculos en los que lo he hablado. Se trata de la necesidad de una alta cobertura de código, o code coverage.

El tema me lo recordó una serie de tweets que intercambiamos el otro día algunos en Twitter, hablando sobre la importancia de tener una cobertura de código del 100%. En el fondo todos estábamos de acuerdo en que no es importante tener un 100%, aunque no es la opinión más habitual que leerás por internet o escucharás en empresas. Mi opinión es que exigir cierto porcentaje de cobertura de código no es que no aporte nada, sino que es algo perjudicial.


Read more

Share Comments

Yo no soy DHH. Long live TDD

DHH es un gran programador, creador de algo como Rails, framework que quedará en la historia de la programación web. Hoy, él, ha sido noticia por escribir un post titulado “TDD is dead”.

Quizá DHH está en lo cierto diciendo que TDD es algo que está muerto, que es momento de seguir hacia adelante y dejarlo atrás. Como cuando crecemos y dejamos de utilizar los ruedines de la bicicleta: es algo para niños pequeños, pero de mayores ya no nos hacen falta. Quizá tiene razón.

Si eres lo suficientemente experto, entonces quizá ya no tiene sentido. Porque para mí TDD es eso: unos ruedines para programar que me ayudan a conseguir un mejor código. Si fuese capaz de escribir el mejor código posible a la primera, que siguiese los principios SOLID, que fuese auto explicativo, etc., entonces yo tampoco haría TDD.  ¿Para qué molestarme?

Si me saliese a la primera, no necesitaría refactorizar muy frecuentemente y tener un unit testing que me avise cuando he roto algo. No me haría falta ese loop de feedback tan corto.


Read more

Share Comments

Utilizando Puphpet también en producción

Ya hablé en el pasado sobre Puphpet, una herramienta web que genera manifiestos de Puppet y de Vagrant de forma rápida y sencilla.

Llevo tiempo utilizándolo para configurar mis máquinas virtuales de desarrollo junto a Vagrant, pero siempre estaba un poco con la mosca detrás de la oreja por el hecho de no poder utilizarlo también en producción.

Así que el otro día me decidí a echar un ojo al código fuente de Puphpet y ver si podía utilizar solo la parte generada de Puppet, y olvidarme de la parte de Vagrant.


Read more

Share Comments

Sácale el máximo partido a tu terminal con zsh

No quiero tirar de términos de moda y hablar de DevOps, pero sí es cierto que, yo por lo menos, paso cada vez más tiempo delante de una terminal de UNIX. Estoy empezando a sentirme como en casa en algo que hace unos años me asustaba bastante.

Hoy vengo a hablaros de zshell, una alternativa a bash, el intérprete que viene por defecto en la mayoría de distribuciones. Algunos pensaréis… “¿Cambiar el intérprete? ¡Eso suena muy difícil!“, pero nada más lejos de la realidad! Otros diréis… “¿Para qué iba yo a querer uno distinto? ¿Cual es el problema con bash?” Problema ninguno! Pero con este post espero enseñaros todo lo que os estáis perdiendo por no utilizar zshell. Además, lo más importante es que no hay que aprender ningún comando nuevo: practicamente todo lo que usas en bash funcionará en zsh.


Read more

Share Comments

Sácale todo el partido a los tests haciendo que griten

Si tuviese que decir en qué se basa una prueba unitaria, diría que las principales características que debe cumplir son (sin ningún orden en particular):

  • Que sea rápido y sin efectos secundarios.
  • Que sea realmente unitario.
  • Que sea auto explicativo.

Pero con el tiempo veo que la gente tiende a centrarse en las dos primeras de mi lista.

Se busca que sea rápido y sin efectos secundarios porque de esa forma podemos lanzarlos siempre que queramos, dándonos confianza. Si tuviésemos que esperar minutos en saber el resultado, o tuviésemos que andar limpiando una base de datos cada vez que quisiésemos lanzar pruebas, simplemente no lo haríamos tan frecuentemente como debiéramos.

También se prioriza que sean unitarios y aislados, para que cuando algo falle, tengamos la granularidad suficiente para identificar el problema en cuestión de segundos. Si tuviésemos una prueba que lo probase todo, el día que fallase, no sabríamos cual de las partes ha sido la culpable.

Y aunque considero que estas dos características son importantísimas, creo que se desprecia la última de mi lista. Las pruebas deberían ser auto explicativas, en el sentido de que debería ser muy fácil saber qué se está probando en todo momento, y sobretodo, qué hace el componente que estamos probando.


Read more

Share Comments

Administrar recursos frontend con Assetic (sin Symfony2)

Buscando mejorar el rendimiento de nuestras aplicaciones web, muchas veces nos centramos en el backend sin prestar suficiente atención al frontend. Una de las mejoras que podemos aplicar en la parte frontal de nuestras webs para que vayan más rápidas es reducir el número de peticiones HTTP que son necesarias para cargar la web. Para ello podemos, por ejemplo, combinar varios archivos CSS o JS en uno solo para que, aunque tengamos que cargar muchos recursos, solo una petición HTTP sea necesaria.

Hacer esto a mano puede ser tedioso y llevar a problemas, por tanto una buena solución sería preguntarnos si alguien ya ha solucionado este problema antes. Como tantas otras veces la respuesta es que sí.

Hoy vengo a hablaros de Assetic, una herramienta que nos permite administrar fácilmente los recursos de la web, como archivos CSS o Javascript, para combinarlos, minificarlos u optimizarlos.


Read more

Share Comments

Caminante no hay camino, se hace camino al andar

Llevo 3 años enseñando buenas prácticas en el desarrollo de software entre el internship de Softonic y las colaboraciones esporádicas con la universidad, y algo que he aprendido de todo esto es que es muy difícil.

Es difícil explicarle a alguien que la duplicación es mala si no ha sufrido las consecuencias en sus carnes. Es complicado decirle que no abuse de la herencia entre clases si no se ha visto incapaz de cambiar su código por culpa de esto.

Es decir, podemos enseñar buenas prácticas a estudiantes, decirles que hagan esto y aquello, o que eviten eso de allí, pero no lo interiorizarán de verdad hasta que no vean claras las consecuencias. Podemos explicarles los beneficios, los pros y los contras de una decisión y lo memorizarán. Pero no lo entenderán del todo y lo dominarán hasta que no lo sufran y se digan a sí mismos: “mierda”.


Read more

Share Comments

¿Qué es el versionamiento semántico y por qué es importante?

Cuando decides utilizar un código que no es tuyo como puede ser un framework o una librería, una de las cosas de las que tienes que preocuparte es de estar al día con las últimas versiones que vayan sacando. No solo porque quizá incluyan cosas que te puedan interesar, si no porque puede que la última versión del framework en el que acabas de basar toda tu aplicación no sea compatible con código de versiones anteriores.

Aquí nacen dos problemas del mundo del software. Uno, para el consumidor de ese código, que necesita una forma de saber si la última versión de una herramienta es un cambio absoluto del comportamiento o solo arregla unos fallos menores. Y dos, para el creador de código, que necesita de una manera de comunicar a sus usuarios la naturaleza y el alcance de la última versión que va a publicar.

Para esto se inventó lo que conocemos a día de hoy como versionamiento semántico, o semantic versioning.


Read more

Share Comments

Limitar memoria máxima de Redis

Haciendo pruebas en uno de los proyectos que tengo, utilicé Redis como sistema de caché, en vez de utilizar Memcached que es el que normalmente uso. Por defecto, Memcached va llenando su memoria hasta que esta se llena, y es entonces cuando empieza a borrar valores existentes para hacer sitio a las nuevas. La estrategia elegida para borrar es eliminar aquellas keys de la cache que han sido menos utilizadas.

Cuando activé Redis para mi proyecto, el proceso _daemon_ del servidor empezó a ocupar más y más memoria hasta que ocupaba casi la totalidad de la RAM del servidor. Poco después, el propio sistema operativo decidió matar el proceso de redis para no morir en el intento.


Read more

Share Comments

Inspección continua de la calidad de nuestro código

Una de las formas que tenemos para poder mejorar el código de nuestro proyecto es someterlo a una inspección continua y constante. Lo primero que podemos hacer es lanzar nuestros tests tras cada push al repositorio, de forma que sabremos en todo momento si hay algo que no funciona bien.

También podemos analizar la complejidad del código y comprobar si estamos incrementándola o disminuyéndola.

Hasta ahora, todas estas tareas eran posibles solamente teniendo un servidor de integración continua configurado, siendo Jenkins el más famoso. En él podemos ejecutar todas estas tareas tras cada push. Recursos como http://jenkins-php.org/ te ayudarán a configurar este versátil servidor hecho en Java.

La buena noticia es que cada vez hay más herramientas online que te permiten hacer estas tareas sin necesidad de configurar practicamente nada. Hoy veremos como lanzar tests y analizar la calidad de nuestro código sin utilizar un servidor de integración continua.


Read more

Share Comments