Usare la Data Science per esplorare lo sviluppo software

Molti sviluppatori software stanno imparando la data science per analizzare i dati dei loro clienti. Un numero crescente si rende conto che può usare le stesse tecniche per rispondere alle proprie domande, ad esempio:

• Quando sarà pronto questo progetto per la consegna?
• Quali componenti della nostra applicazione hanno più bisogno di test?
• Chi dovrebbe correggere questo bug?
• Quali parti della mia API le persone trovano più difficili da usare?

Negli ultimi 15 anni c'è stata un'esplosione di ricerche empiriche nell'ingegneria del software per esplorare queste domande, alimentata in parte dalla disponibilità di dati da siti come GitHub e Stack Overflow. Questo post presenta alcuni risultati rappresentativi, quindi approfondisce i metodi dietro tre di essi.

Se vuoi saperne di più su come usare la data science per ottenere insight di questo tipo nei tuoi progetti, fammi sapere.

Data science e ingegneria del software: esempi

Iniziamo con un risultato che riguarda chiunque faccia data science su larga scala: la scoperta di Yuan et al. secondo cui test semplici possono prevenire la maggior parte dei guasti critici nei sistemi distribuiti data-intensive. Hanno esaminato i guasti su Cassandra, Hadoop MapReduce e sistemi simili e hanno scoperto che:

1. Quasi tutti i guasti richiedevano 3 o meno nodi di calcolo per essere riprodotti. Cioè, di solito non ti serve un cluster per effettuare il debug di un cluster.
2. I log degli errori contenevano di solito dati sufficienti a consentire la riproduzione.
3. La maggior parte dei guasti catastrofici avrebbe potuto essere facilmente prevenuta eseguendo semplici test sul codice di gestione degli errori.

L'ultimo punto è il più inaspettato. Mentre di solito i professionisti testano che il loro codice di analisi funzioni quando tutto va bene, raramente verificano che faccia la cosa giusta quando qualcosa va storto. Aggiungere solo alcuni test di questo tipo durante lo sviluppo eviterebbe molti problemi a valle.

Un altro risultato su larga scala arriva dal lavoro di Altadmri e Brown, che hanno analizzato 37 milioni di tentativi di compilazione di programmi da parte di studenti delle scuole superiori nel Regno Unito. Hanno poi chiesto agli insegnanti quali fossero gli errori più comuni dei loro studenti e hanno scoperto che:

1. Gli insegnanti non erano d'accordo tra loro su quali errori gli studenti fossero più propensi a fare.
2. Ancora più importante, le previsioni degli insegnanti avevano solo una debole correlazione con ciò che gli studenti sbagliavano davvero.

Ovviamente, il data mining non è l'unico modo per generare insight utili e basati su evidenze nella programmazione. Nel 2013, il team di Andreas Stefik ha pubblicato il secondo di una serie di studi per capire se alcuni linguaggi siano più facili da imparare di altri. Come baseline, hanno incluso nel loro studio un linguaggio inventato, i cui keyword erano generati casualmente.

Con loro sorpresa, i linguaggi con parentesi graffe come Java e Perl erano difficili da imparare a riconoscere per i principianti quanto un linguaggio generato a caso. Python e Ruby erano entrambi significativamente più facili da imparare, e Quorum, che effettua A/B test sulla sintassi di ogni nuova funzionalità prima di aggiungerla, era ancora più semplice. Andreas discute questo risultato, e i motivi per cui i progettisti di linguaggi di programmazione prestano così poca attenzione all'usabilità, in questo podcast divertente.

Identificare le segnalazioni di bug di sicurezza

Come esempio di come vengono condotti questi studi, Fayola Peters presso LERO ha utilizzato modelli di previsione basati su testo per trovare segnalazioni di bug di sicurezza nei bug tracker di grandi sistemi, così da poterne prioritizzare il lavoro. In uno studio, ha utilizzato dati dai progetti Chromium, Wicket, Ambari, Camel e Derby; questi contengono in totale 45.940 segnalazioni di bug, ma solo lo 0,8% riguarda bug di sicurezza.

Alcuni bug di sicurezza sono etichettati manualmente e possono essere usati per addestrare classificatori in grado di rilevare quelli non etichettati. Tecniche come Naïve Bayes e Random Forest sono un punto di partenza, ma l'efficacia di modelli generici può spesso essere migliorata filtrando parole chiave specifiche. Il controllo più importante è valutare quanto bene modelli costruiti da progetti con bug di sicurezza etichettati riescano a trovare bug simili in altri progetti. I risultati sono stati incoraggianti: Peters ha riscontrato che i suoi classificatori funzionavano abbastanza bene da essere utili nella pratica.

Il mio patch verrà accettato?

Come secondo esempio, le aziende vogliono che le loro modifiche vengano incluse nei progetti per evitare di dover mantenere il codice in proprio, e i volontari vogliono un'indicazione sul fatto che il loro patch abbia delle possibilità. Dato che spesso passa molto tempo tra l'invio e l'accettazione, Bram Adams e il suo gruppo alla Polytechnique Montréal hanno costruito modelli per prevedere quali patch verranno accettati.

Come molti progetti di data science, questo inizia recuperando e pulendo dati da più fonti, inclusi repository Git e revisioni del codice con Gerrit. Tuttavia, per i progetti che usano revisioni via email, come il kernel Linux, raccogliere i dati significa fare scraping degli archivi delle mailing list e usare euristiche come i checksum delle patch o l'intersezione per insiemi delle linee modificate per collegare le patch alle conversazioni. Anche con l'aiuto di strumenti come GrimoireLab, ci saranno sempre patch di cui sono state esaminate più versioni, e patch suddivisi in più parti revisionate separatamente. Come in tutta la data science, spetta all'analista costruire un modello, e le assunzioni in esso avranno un forte impatto sulle conclusioni finali.

Il secondo passo è decidere quali variabili esaminare e quale metrica usare per ciascuna, ad esempio:

• qualità della patch
• esperienza dello sviluppatore della patch
• processo di revisione (per esempio, commenti di revisione e numero di revisori)
• qualità della revisione (per esempio, livello di dettaglio delle revisioni)
• tempo di revisione
• interazione tra autore della patch e revisori (per esempio, amichevole vs aggressiva)

Solo questa mezza dozzina potrebbe richiedere tutto, dalle statistiche di sopravvivenza all'analisi del sentiment. Una volta deciso cosa misurare, puoi applicare gli strumenti di data science che i corsi di DataCamp insegnano. Poiché il tuo vero obiettivo è prevedere l'accettazione di patch future, l'approccio più diretto è la regressione logistica, ma ce ne sono molti altri.

Infine, puoi misurare l'importanza delle variabili per determinare l'impatto di ciascuna sull'accettazione della patch. Questo sarà necessariamente in parte qualitativo, dato che il tuo obiettivo è identificare cosa possono fare gli sviluppatori per migliorare le probabilità che il loro lavoro entri nel prodotto. Come sempre, bisogna fare attenzione a non confondere correlazione e causalità, ma anche poche raccomandazioni semplici (come "NON USARE TUTTO MAIUSCOLO NEI MESSAGGI DI COMMIT") possono fare davvero la differenza.

Trovare aiuto

Il cambiamento più grande nel modo in cui lavorano i programmatori negli ultimi 20 anni non è stato nei linguaggi che usano: è stata la dipendenza quasi universale da Stack Overflow per fare domande e ottenere risposte. Christoph Treude dell'Università di Adelaide e i suoi collaboratori stanno sviluppando metodi per rendere siti come questo più utili.

Il loro punto di partenza è il dump dei dati di Stack Overflow. Dopo alcune statistiche esplorative per esaminare il numero di parole e frasi, le parole più comuni, la term frequency–inverse document frequency (TF-IDF) e così via, il passo successivo è vedere quali parole nei thread di Stack Overflow co-occorrono con voti più alti, tassi di accettazione più elevati e un maggior numero di visualizzazioni.

Poiché la documentazione software contiene molte frasi incomplete ed elementi di codice, le librerie di elaborazione del linguaggio naturale pronte all'uso spesso sbagliano. La documentazione software scritta in lingue diverse dall'inglese è ancora più difficile da analizzare, poiché tende comunque a usare l'inglese per la terminologia tecnica. Cioè, mescola due lingue naturali ed elementi di codice. Occorre usare insieme euristiche ad hoc e tecniche di modellazione più avanzate per gestire casi come questo.

Mettere insieme i pezzi rende possibile costruire uno strumento che prende il nome di un modulo Python come input e produce frasi significative su quel modulo partendo dai thread di Stack Overflow. Andando oltre, Treude e i suoi collaboratori sono riusciti a usare le dipendenze grammaticali tra le parole per trovare automaticamente documentazione software che spiega come eseguire un'attività e poi identificare automaticamente gli snippet di codice che possono svolgere quell'attività.

Conclusione

Troppo spesso, verità ampiamente accettate sullo sviluppo software si basano su opinioni forti e voci alte più che su evidenze. Come descritto all'inizio, questo sta cambiando, poiché ogni anno compaiono centinaia di studi di alta qualità che supportano alcune convinzioni, come "il code review è davvero il modo migliore per trovare bug", e ne mettono in discussione altre, come "il test-driven development non è così efficace come alcuni credono, e le istruzioni goto non sono davvero dannose".

"Ingegneria" è stata definita come "l'applicazione del metodo scientifico per creare cose utili". Se è vero, allora lo sviluppo software potrebbe finalmente, grazie alla data science, essere sulla strada per diventare una vera disciplina ingegneristica. Se vuoi vedere dei corsi che mostrino come applicare la data science allo sviluppo software, facci sapere.

Per approfondire

Ogni anno i ricercatori presentano dozzine di nuovi risultati in questo ambito a conferenze come Mining Software Repositories. Alcuni di questi atti sono ancora bloccati dietro paywall accademici, ma un numero crescente di ricercatori rende disponibili i preprint.

Per chi cerca una panoramica, il libro del 2010 Making Software era una raccolta dei "migliori successi" dei risultati più interessanti dell'epoca. Una nuova trilogia intitolata Perspectives on Data Science for Software Engineering, The Art and Science of Analyzing Software Data e Sharing Data and Models in Software Engineering offre una copertura più ampia e aggiornata degli stessi temi e, separatamente, Derek Jones sta lavorando a un nuovo libro intitolato Empirical Software Engineering Using R.