Les dije que proritizaran los problemas encontrados por el equipo de control de calidad e implementaran pruebas en el proceso de compilación para evitar que estos problemas volvieran a aparecer. Después de tres semanas de trabajo de un desarrollador, se ejecutaron 130 pruebas en el proceso de compilación. En el siguiente ciclo de lanzamiento, el control de calidad se redujo a 2 semanas y las llamadas de asistencia sobre el terreno se redujeron en 50%, lo que supuso un ahorro de millones de euros en tiempo de desarrollo y un aumento de las ventas de millones de euros. No he visto nada que funcione mejor que esto.
Google ha desarrollado una brillante estrategia automatizada llamada "Predicción de fallos" que hace esencialmente lo mismo. Parece que todos los equipos deberían hacer algo así.
Predicción de errores en Google
Sin embargo, los Googlers trabajan cada día en problemas cada vez más complejos, proporcionando las funciones y la disponibilidad de las que dependen nuestros usuarios. Algunos de estos problemas son necesariamente difíciles de abordar, lo que da lugar a un código inevitablemente difícil. A veces, ese código funciona muy bien y se despliega sin incidentes. Otras veces, el código crea problemas una y otra vez, a medida que los desarrolladores intentan resolverlos. Por el bien de este artículo, llamaremos a esta segunda clase de código "puntos calientes". Tal vez un punto caliente es resistente a las pruebas unitarias, o tal vez un conjunto muy específico de condiciones puede hacer que el código falle. Por lo general, nuestros diligentes, experimentados e intrépidos revisores de código son capaces de detectar cualquier problema y resolverlo. Dicho esto, todos somos humanos, y los errores furtivos todavía son capaces de colarse. Nos hemos dado cuenta de que puede ser difícil darse cuenta de cuándo alguien está cambiando un punto conflictivo frente a un código generalmente inofensivo. Además, a medida que aumenta el tamaño de la base de código y de los equipos de Google, es más improbable que el remitente y el revisor sean conscientes de que están modificando un punto conflictivo.
Para ayudar a identificar estos puntos conflictivos y advertir a los desarrolladores, nos fijamos en la predicción de fallos. La predicción de fallos utiliza el aprendizaje automático y el análisis estadístico para tratar de adivinar si un fragmento de código es potencialmente defectuoso o no, normalmente dentro de un cierto margen de confianza. Las métricas basadas en el código fuente que podrían utilizarse para la predicción son cuántas líneas de código, cuántas dependencias son necesarias y si esas dependencias son cíclicas. Pueden funcionar bien, pero estas métricas van a marcar nuestro código necesariamente difícil, pero por lo demás inocuo, así como nuestros puntos calientes. Sólo nos preocupan nuestros puntos calientes, así que ¿cómo los encontramos? Bueno, en realidad tenemos un gran registro fidedigno de dónde ha estado el código que requiere correcciones: ¡nuestro rastreador de errores y nuestro registro de commits de control de código fuente! La investigación (por ejemplo, FixCache) indica que la predicción de errores a partir del historial de fuentes funciona muy bien, por lo que decidimos implantarlo en Google.