Mutation testing es una forma de evaluar la calidad de nuestros tests, que aunque según el artículo enlazado comenzó a plantearse en la década de los 70, no ha sido hasta hace relativamente poco tiempo que está adquiriendo relativa presencia en entornos empresariales. De hecho, diría que aún le falta mucho camino por recorrer para implantarse definitivamente. Espero, desde este modesto blog, aportar mi granito de arena para que su uso vaya aumentando como realmente merece.
“¿Complejidad qué? ¿De qué demonios hablas?”, pensarán muchos lectores (o al menos un porcentaje de los que me leen :)). Trataré en este post de aclarar estos conceptos, que, siendo algo omnipresente en nuestro día a día como desarrolladores de software, seguramente el hacerlos patentes nos haga reflexionar más sobre nuestas decisiones en el futuro.
En la versión 7 de Java se incluyó una nueva API llamanda MethodHandle, y que fue presentada como una alternativa a Reflection para poder acceder de forma dinámica a los miembros de una clase en tiempo de ejecución. Además, al parecer, el rendimiento es superior al ofrecido por Reflection, acercándose al obtenido por invocaciones directas a los métodos.
He estado jugando un poco con esta API, y comprobando si las afirmaciones sobre rendimiento son ciertas. Crearé un par de ejemplos sencillos, accediendo a métodos mediante Reflection y Method Handles, y comparando el tiempo de ejecución.
El multithreading es quizás el área más peliaguda del desarrollo software. No es mi intención en este post desgranar todos los problemas que nos podemos encontrar al diseñar e implementar un sistema con máxima concurrencia, pero seguramente os suenen conceptos como deadlocks, liveness, etc, que son increíblemente difíciles de depurar debido al indeterminismo de este tipo de aplicaciones.
Como en cualquier ámbito de ingeniería, el uso de patrones facilita enormemente el desarrollo de sistemas concurrentes. En concreto, el patrón Producer-Consumer, además de ser extremadamente sencillo, permite optimizar y ajustar el rendimiento de nuestros sistemas dinámicamente jugando con el número de threads afectados. Veamos en qué consiste.
Los patrones de diseño del Gang of Four son una de las piedras angulares en el desarrollo de software. Algunos de ellos tan importantes que han sido absorbidos por implementaciones nativas en los lenguajes de programación y los damos como algo dado sin darnos cuenta del patrón que reside detrás (caso de Iterator).
Para aprender el funcionamiento de estos patrones se suele remitir al libro original, aunque en mi caso los aprendí con el magnífico Head First Design Patterns. Internet está lleno de referencias y explicaciones, por supuesto, y yo aportaré mi granito de arena con ejemplos prácticos de uso de algunos de ellos.