Veel softwareontwikkelaars leren data science om de data van hun klanten te analyseren. Steeds meer van hen beseffen dat ze dezelfde technieken kunnen gebruiken om hun eigen vragen te beantwoorden, zoals:
- Wanneer is dit project klaar om te lanceren?
- Welke onderdelen van onze applicatie moeten het hardst getest worden?
- Wie zou deze bug moeten oplossen?
- Welke delen van mijn API vinden mensen het lastigst om te gebruiken?
In de afgelopen 15 jaar is er een explosie geweest aan empirisch onderzoek in software engineering om dit soort vragen te verkennen, mede mogelijk gemaakt door de beschikbaarheid van data van sites als GitHub en Stack Overflow. Deze blogpost presenteert een paar representatieve resultaten en gaat daarna dieper in op de methoden achter drie ervan.
Wil je meer weten over hoe je data science kunt inzetten om dit soort inzichten in je eigen projecten te krijgen, laat het me dan weten.
Data Science en Software Engineering: voorbeelden
Laten we beginnen met een bevinding die iedereen raakt die op schaal aan data science doet: de ontdekking van Yuan et al. dat eenvoudige tests de meeste kritieke storingen in gedistribueerde, data-intensieve systemen kunnen voorkomen. Ze onderzochten storingen in Cassandra, Hadoop MapReduce en vergelijkbare systemen en ontdekten dat:
- Bijna alle storingen konden worden gereproduceerd met 3 of minder compute-nodes. Met andere woorden: je hebt meestal geen cluster nodig om een cluster te debuggen.
- Foutlogboeken meestal genoeg data bevatten om reproductie mogelijk te maken.
- De meerderheid van catastrofale storingen gemakkelijk had kunnen worden voorkomen door eenvoudige tests uit te voeren op foutafhandelingscode.
Het laatste punt is het meest onverwacht. Professionals testen doorgaans wel of hun analysecode werkt wanneer alles goed gaat, maar zelden of die het juiste doet als er iets misgaat. Slechts een paar van dit soort tests toevoegen tijdens de ontwikkeling zou veel pijn stroomafwaarts voorkomen.
Een ander grootschalig resultaat komt van het werk van Altadmri en Brown, die keken naar 37 miljoen pogingen van middelbare scholieren in het Verenigd Koninkrijk om programma’s te compileren. Ze vroegen vervolgens aan docenten wat de meest voorkomende fouten van hun leerlingen waren, en ontdekten dat:
- Docenten het onderling niet eens waren over welke fouten leerlingen het vaakst zouden maken.
- Belangrijker nog: de voorspellingen van docenten slechts zwak correleerden met wat leerlingen daadwerkelijk fout deden.
Data-analyse is natuurlijk niet de enige manier om bruikbare, evidence-based inzichten in programmeren te krijgen. In 2013 publiceerde het team van Andreas Stefik de tweede in een reeks studies naar de vraag of sommige talen makkelijker te leren zijn dan andere. Als nulpunt namen ze een verzonnen taal op in hun studie, waarvan de keywords willekeurig waren gegenereerd.
Tot hun verrassing bleken accolades-talen zoals Java en Perl voor beginners net zo moeilijk te herkennen als een willekeurig gegenereerde taal. Python en Ruby waren aanzienlijk makkelijker te leren, en Quorum, dat de syntaxis van elke nieuwe feature A/B-test voordat die wordt toegevoegd, was nog eenvoudiger. Andreas bespreekt dit resultaat, en de redenen waarom ontwerpers van programmeertalen zo weinig aandacht besteden aan bruikbaarheid, in deze onderhoudende podcast.
Beveiligingsbugrapporten identificeren
Als voorbeeld van hoe dit soort studies worden uitgevoerd, gebruikte Fayola Peters bij LERO tekstgebaseerde voorspellingsmodellen om meldingen van beveiligingsbugs te vinden in de bugtrackers van grote systemen, zodat daar prioriteit aan kan worden gegeven. In één studie gebruikte ze data van de projecten Chromium, Wicket, Ambari, Camel en Derby; die bevatten in totaal 45.940 bugrapporten, maar slechts 0,8% daarvan zijn beveiligingsbugrapporten.
Sommige beveiligingsbugs zijn handmatig gelabeld, en die kunnen worden gebruikt om classifiers te trainen om ongelabelde te detecteren. Technieken als Naïeve Bayes en Random Forests zijn een vertrekpunt, maar de efficiëntie van generieke modellen kan vaak worden verbeterd door te filteren op specifieke trefwoorden. De belangrijkste toets is hoe goed modellen die zijn gebouwd op projecten met gelabelde beveiligingsbugs soortgelijke bugs in andere projecten kunnen vinden. De resultaten waren bemoedigend: Peters ontdekte dat haar classifiers goed genoeg werkten om in de praktijk nuttig te zijn.
Wordt mijn patch geaccepteerd?
Als tweede voorbeeld: bedrijven willen dat hun wijzigingen in projecten worden opgenomen om te voorkomen dat ze de code zelf moeten onderhouden, en vrijwilligers willen ook een indicatie of hun patch een kans maakt. Omdat er vaak veel tijd zit tussen het indienen en het accepteren van een patch, bouwen Bram Adams en zijn groep aan de Polytechnique Montréal modellen om te voorspellen welke zullen worden geaccepteerd.
Zoals veel data science-projecten begint dit met het ophalen en opschonen van data uit meerdere bronnen, waaronder Git-repositories en Gerrit-codebeoordelingen. Voor projecten die e-mailgebaseerde review gebruiken, zoals de Linux-kernel, betekent dat het scrapen van mailinglist-archieven en het gebruiken van heuristieken zoals checksums van patches of set-gebaseerde intersectie van gewijzigde regels om patches aan gesprekken te koppelen. Zelfs met hulp van tools zoals GrimoireLab zullen er altijd patches zijn waarvan meerdere versies zijn beoordeeld, en patches die in meerdere delen zijn opgesplitst en afzonderlijk zijn beoordeeld. Zoals in alle data science is het aan de analist om een model te bouwen, en de aannames daarin hebben een grote impact op de uiteindelijke conclusies.
De tweede stap is beslissen welke variabelen je onderzoekt en welke metriek je voor elke variabele gebruikt, zoals:
- patchkwaliteit
- de ervaring van de patchontwikkelaar
- het reviewproces (bijvoorbeeld reviewopmerkingen en aantal reviewers)
- reviewkwaliteit (bijvoorbeeld de mate van detail in reviews)
- reviewtijd
- interactie tussen patchauteur en reviewers (bijvoorbeeld vriendelijk versus boos)
Alleen al dit half dozijn kan alles vereisen van survivalstatistiek tot sentimentanalyse. Zodra je hebt besloten wat je meet, kun je de data science-tools toepassen die de cursussen van DataCamp leren. Aangezien je echte doel is om de acceptatie van toekomstige patches te voorspellen, is de meest rechttoe-rechtaan aanpak logistische regressie, maar er zijn veel andere.
Tot slot kun je variabele belangrijkheid meten om de impact van elke variabele op patchacceptatie te bepalen. Dit zal onvermijdelijk deels kwalitatief zijn, omdat je doel is te identificeren wat ontwikkelaars kunnen doen om de kans te vergroten dat hun werk in het product terechtkomt. Zoals altijd moet je oppassen dat je correlatie niet verwart met causaliteit, maar zelfs een paar simpele aanbevelingen (zoals "GEBRUIK GEEN HOOFDLETTERS IN JE COMMIT-BERICHTEN") kunnen echt verschil maken.
Hulp vinden
De grootste verandering in hoe programmeurs werken in de afgelopen 20 jaar zit niet in de talen die ze gebruiken: het is de bijna universele afhankelijkheid van Stack Overflow om vragen te stellen en antwoorden te krijgen. Christoph Treude aan de University of Adelaide en zijn samenwerkers ontwikkelen methoden om sites als deze nuttiger te maken.
Hun startpunt is de Stack Overflow-dump. Na wat verkennende statistiek om te kijken naar het aantal woorden en zinnen, meest voorkomende woorden, term frequency–inverse document frequency (TF-IDF), enzovoort, is de volgende stap om te zien welke woorden in Stack Overflow-threads samen voorkomen met hogere stemmen, hogere acceptatiepercentages en hogere weergavetellingen.
Omdat softwaredocumentatie veel onvolledige zinnen en code-elementen bevat, gaan kant-en-klare natural language processing-bibliotheken vaak de mist in. Softwaredocumentatie die in andere talen dan het Engels is geschreven, is nog moeilijker te parsen, omdat technische terminologie nog steeds vaak in het Engels wordt gebruikt. Met andere woorden: het mixt twee natuurlijke talen en code-elementen. Ad-hocoplossingen en meer geavanceerde modelleertechnieken moeten samen worden gebruikt om dit soort gevallen aan te kunnen.
Door de stukjes samen te brengen is het mogelijk een tool te bouwen die de naam van een Python-module als input neemt en betekenisvolle zinnen over die module uit Stack Overflow-threads produceert. Nog verdergaand konden Treude en zijn samenwerkers grammaticale afhankelijkheden tussen woorden gebruiken om automatisch softwaredocumentatie te vinden die uitlegt hoe je een taak uitvoert, en vervolgens automatisch codefragmenten te identificeren die die taak kunnen uitvoeren.
Conclusie
Al te vaak zijn algemeen aanvaarde waarheden over softwareontwikkeling gebaseerd op sterke meningen en luide stemmen in plaats van op bewijs. Zoals aan het begin beschreven, verandert dat nu honderden kwalitatief sterke studies elk jaar sommige overtuigingen ondersteunen, zoals "code review is echt de beste manier om bugs te vinden", en andere uitdagen, zoals "test-driven development is niet zo effectief als sommigen denken, en goto-statements zijn niet echt schadelijk".
"Engineering" is gedefinieerd als "de toepassing van de wetenschappelijke methode om nuttige dingen te creëren". Als dat waar is, dan zou softwareontwikkeling dankzij data science eindelijk op weg kunnen zijn om een echte ingenieursdiscipline te worden. Als je graag cursussen zou zien die je laten zien hoe je data science toepast op softwareontwikkeling, laat het ons dan weten.
Verder lezen
Onderzoekers presenteren elk jaar tientallen nieuwe bevindingen op dit gebied op conferenties zoals Mining Software Repositories. Sommige van deze proceedings zitten nog steeds achter academische betaalmuren, maar steeds meer onderzoekers stellen preprints beschikbaar.
Voor wie een overzicht zoekt: het boek Making Software uit 2010 was een "greatest hits"-collectie van de interessantste resultaten van dat moment. Een nieuwe trilogie getiteld Perspectives on Data Science for Software Engineering, The Art and Science of Analyzing Software Data en Sharing Data and Models in Software Engineering biedt een bredere en actuelere dekking van dezelfde onderwerpen, en los daarvan werkt Derek Jones aan een nieuw boek met de titel Empirical Software Engineering Using R.
