Eransé que se eran tres desarrolladores. Los tres tenían que sincronizar sus hilos, habían oido hablar de las terribles historias sobre problemas de corrupción de memoria, condiciones de carrera, y demás ‘lobos’ capaces de devorar cualquier aplicación cuando se ponía en producción. Menos más que existían los objetos de sincronización pensaron y se pusieron a trabajar.
El primero de los desarrolladores pregunto a su buscador favorito como sincronizar una porción de código en .Net y rápidamente encontró el siguiente código:
lock (typeof(Object))
{
. . .
}
Lo pegó en su programa y luego se fue a tomar unas cervecitas con sus colegas.
El segundo de los desarrolladores escribió el mismo código en su proyecto y se fue a tomar unas cervecitas con sus colegas. Una pena que no les gustase más el framework que la cerveza, como al bueno de Unai. Si no hubiesen sabido que su código no era lo suficientemente sólido…
Pero un día, cuando más tranquilos estaban estos desarrolladores, la aplicación se puso en producción y el ventilador del procesador sopló y sopló y sopló… y un interbloqueo apareció. Menos más que un cazador de bugs, Pablo Alvarez, pasaba por allí y milagrosamente salvo a los desarrolladores de ser devorados por el malvado deadlock.
No lejos de allí, el tercero de los desarrolladores, un desarrollador responsable, pensó: ‘Quiero que mi aplicación sea sólida, ¿que puedo hacer?’ y llego a la conclusión de que era una buena idea construir su aplicación ‘con sólidos ladrillos’ y activo el análisis estático de código de Visual Studio. A pesar de haber copiado el mismo código ‘de paja’ que había encontrado en su buscador favorito, el análisis de código detecto el error:
El desarrollador aprendió por que era una pésima idea hacer aplicaciones ‘de paja’ que estableciesen locks sobre objetos con identidad débil, corrigió su código y cuando el ventilador sopló y sopló y sopló y la aplicación aguanto.
Moraleja: Más vale prevenir que curar… Si en el casó del DOT que explicaba el amigo Pablo, hubiesen activado el analizador estático de código (FxCop para los amigos), Pablo no hubiese podido contar su apasionante sesión de depuración, pero la aplicación hubiese funcionado a la primera… Una vez más se cumple la máxima de que el coste de un bug aumenta exponencialmente respecto a cuanto tarda en detectarse. Coste de usar FxCop: cero, coste de que una aplicación en producción se caiga cada cierto tiempo… mejor ni pensarlo. ¡Menos mal que el Debugging and Optimization Team de Plain Concepts sale baratito! 🙂
Si alguien duda de la eficacia del análisis de código, solo puedo decir que es la segunda ocasión en la que publico como esta herramienta puede salvar el culo de un desarrollador.
¡Un saludo!
