Muchos desarrolladores de software están aprendiendo ciencia de datos para analizar datos de sus clientes. Cada vez más descubren que esas mismas técnicas les sirven para responder a preguntas propias, como:
- ¿Cuándo estará listo este proyecto para lanzar?
- ¿Qué componentes de nuestra aplicación necesitan más pruebas?
- ¿Quién debería arreglar este bug?
- ¿Qué partes de mi API resultan más difíciles de usar?
En los últimos 15 años ha habido una explosión de investigación empírica en ingeniería de software para explorar estas cuestiones, impulsada en parte por la disponibilidad de datos de sitios como GitHub y Stack Overflow. Este artículo presenta algunos resultados representativos y luego profundiza en los métodos detrás de tres de ellos.
Si te interesa aprender a usar la ciencia de datos para obtener este tipo de insights en tus propios proyectos, dímelo por aquí.
Ciencia de datos e ingeniería de software: ejemplos
Empecemos con un hallazgo que afecta a cualquiera que haga ciencia de datos a escala: el descubrimiento de Yuan y colaboradores de que las pruebas sencillas pueden evitar la mayoría de fallos críticos en sistemas distribuidos intensivos en datos. Analizaron fallos en Cassandra, Hadoop MapReduce y sistemas similares y observaron que:
- Casi todos los fallos requerían 3 nodos de cómputo o menos para reproducirse. Es decir, por lo general no necesitas un clúster para depurar un clúster.
- Los registros de error solían contener datos suficientes para permitir la reproducción.
- La mayoría de fallos catastróficos se podrían haber evitado fácilmente realizando pruebas simples del código de gestión de errores.
Este último punto es el más inesperado. Aunque se suele probar que el código funciona cuando todo va bien, rara vez se verifica que haga lo correcto cuando algo falla. Añadir solo unas cuantas pruebas de este tipo durante el desarrollo evitaría muchos dolores de cabeza más adelante.
Otro resultado a gran escala procede del trabajo de Altadmri y Brown, que analizaron 37 millones de intentos de compilación de estudiantes de secundaria en el Reino Unido. Después preguntaron al profesorado cuáles eran los errores más habituales de su alumnado y descubrieron que:
- El profesorado no coincidía entre sí sobre qué errores eran más probables.
- Y, lo más importante, sus predicciones correlacionaban débilmente con lo que el alumnado realmente hacía mal.
Por supuesto, la minería de datos no es la única forma de generar insights útiles basados en evidencia en programación. En 2013, el equipo de Andreas Stefik publicó el segundo de una serie de estudios sobre si algunos lenguajes son más fáciles de aprender que otros. Como referencia, incluyeron un lenguaje inventado cuyos keywords se generaron al azar.
Para su sorpresa, lenguajes con llaves como Java y Perl resultaron igual de difíciles de reconocer para personas novatas que un lenguaje generado aleatoriamente. Python y Ruby fueron significativamente más fáciles de aprender, y Quorum, que hace pruebas A/B de la sintaxis de cada nueva funcionalidad antes de incluirla, lo fue aún más. Andreas comenta este resultado, y por qué los diseñadores de lenguajes prestan tan poca atención a la usabilidad, en este entretenido podcast.
Identificar informes de bugs de seguridad
Como ejemplo de cómo se realizan estos estudios, Fayola Peters en LERO usó modelos de predicción basados en texto para encontrar informes de bugs de seguridad en los trackers de grandes sistemas y así poder priorizar su resolución. En un estudio, utilizó datos de los proyectos Chromium, Wicket, Ambari, Camel y Derby; en total, 45.940 informes de bugs, pero solo el 0,8% eran de seguridad.
Algunos bugs de seguridad están etiquetados manualmente y pueden usarse para entrenar clasificadores que detecten los no etiquetados. Técnicas como Naïve Bayes y Random Forests son un buen punto de partida, pero la eficiencia de los modelos genéricos a menudo mejora filtrando keywords concretas. La comprobación clave es qué tal funcionan los modelos entrenados con proyectos que sí tienen bugs de seguridad etiquetados para encontrar bugs similares en otros proyectos. Los resultados fueron prometedores: Peters comprobó que sus clasificadores funcionaban lo suficientemente bien como para ser útiles en la práctica.
¿Aceptarán mi patch?
Como segundo ejemplo, las empresas quieren que sus modificaciones se integren en los proyectos para evitar tener que mantener el código por su cuenta, y las personas voluntarias también quieren saber si su patch tiene posibilidades. Dado que a menudo pasa mucho tiempo entre el envío y la aceptación, Bram Adams y su grupo en la Polytechnique Montréal han estado construyendo modelos para predecir cuáles serán aceptados.
Como muchos proyectos de ciencia de datos, este empieza recopilando y limpiando datos de múltiples fuentes, incluidos repositorios Git y revisiones de código en Gerrit. Sin embargo, para proyectos que usan revisión basada en correo, como el kernel de Linux, recopilar datos implica rastrear archivos de listas de correo y usar heurísticas como checksums de patches o la intersección de líneas cambiadas para vincular patches con conversaciones. Incluso con herramientas como GrimoireLab, siempre habrá patches con múltiples versiones revisadas y patches divididos en varias partes revisadas por separado. Como en toda ciencia de datos, corresponde a la persona analista construir un modelo, y sus supuestos influirán de forma decisiva en las conclusiones.
El segundo paso es decidir qué variables analizar y qué métrica usar para cada una, por ejemplo:
- calidad del patch
- experiencia de quien desarrolla el patch
- proceso de revisión (por ejemplo, comentarios y número de personas revisoras)
- calidad de la revisión (por ejemplo, grado de detalle)
- tiempo de revisión
- interacción entre la autoría del patch y quienes revisan (por ejemplo, tono cordial frente a airado)
Solo esta media docena ya puede requerir desde estadísticas de supervivencia hasta análisis de sentimiento. Una vez decidido qué medir, puedes aplicar las herramientas de ciencia de datos que enseñan los cursos de DataCamp. Dado que tu objetivo real es predecir la aceptación de patches futuros, el enfoque más directo es la regresión logística, aunque hay muchas alternativas.
Por último, puedes medir la importancia de variables para determinar el impacto de cada una en la aceptación del patch. Esto será en parte cualitativo por fuerza, ya que tu objetivo es identificar qué pueden hacer las personas desarrolladoras para mejorar las probabilidades de que su trabajo llegue al producto. Como siempre, hay que evitar confundir correlación con causalidad, pero incluso unas recomendaciones simples (como "NO USES MAYÚSCULAS EN TUS MENSAJES DE COMMIT") pueden marcar la diferencia.
Encontrar ayuda
El mayor cambio en la forma de trabajar de quienes programan en los últimos 20 años no ha sido el lenguaje que usan: ha sido la dependencia casi universal de Stack Overflow para preguntar y obtener respuestas. Christoph Treude, en la Universidad de Adelaida, y su equipo han desarrollado métodos para que sitios como este sean aún más útiles.
Su punto de partida es el volcado de datos de Stack Overflow. Tras hacer estadísticas exploratorias (número de palabras y frases, palabras más comunes, TF-IDF, etc.), el siguiente paso es ver qué palabras en los hilos de Stack Overflow coaparecen con más votos, mayores tasas de aceptación y más visualizaciones.
Como la documentación de software contiene muchas frases incompletas y elementos de código, las librerías de PLN generales a menudo fallan. La documentación escrita en otros idiomas distintos del inglés es aún más difícil de analizar porque suele mantener la terminología técnica en inglés. Es decir, mezcla dos lenguas naturales y código. Para abarcar estos casos hay que combinar heurísticas ad hoc con técnicas de modelado más avanzadas.
Uniendo las piezas es posible construir una herramienta que tome el nombre de un módulo de Python como entrada y genere frases con sentido sobre ese módulo a partir de los hilos de Stack Overflow. Más allá de eso, Treude y su equipo usaron dependencias gramaticales entre palabras para localizar automáticamente documentación que explica cómo realizar una tarea y, después, identificar automáticamente fragmentos de código que permiten llevarla a cabo.
Conclusión
Demasiadas veces, las verdades más repetidas sobre desarrollo de software se basan en opiniones fuertes y voces altas más que en evidencias. Como decíamos al principio, eso está cambiando a medida que cada año aparecen cientos de estudios de calidad que respaldan algunas creencias, como "la revisión de código es realmente la mejor forma de encontrar bugs", y ponen en duda otras, como "el desarrollo guiado por pruebas no es tan efectivo como algunos creen, y las sentencias goto no son realmente dañinas".
Se ha definido "ingeniería" como "la aplicación del método científico para crear cosas útiles". Si eso es cierto, gracias a la ciencia de datos el desarrollo de software podría estar, por fin, en camino de convertirse en una disciplina de ingeniería de pleno derecho. Si te gustaría ver cursos que te enseñen a aplicar la ciencia de datos al desarrollo de software, cuéntanoslo.
Para saber más
Todos los años se presentan decenas de hallazgos nuevos en conferencias como Mining Software Repositories. Parte de esas actas sigue tras muros de pago académicos, pero cada vez más gente investigadora publica preprints.
Si buscas una panorámica, el libro de 2010 Making Software fue una recopilación de los "grandes éxitos" de los resultados más interesantes de la época. Una trilogía más reciente —Perspectives on Data Science for Software Engineering, The Art and Science of Analyzing Software Data y Sharing Data and Models in Software Engineering— ofrece una cobertura más amplia y actualizada de los mismos temas, y, por su parte, Derek Jones está trabajando en un nuevo libro titulado Empirical Software Engineering Using R.
