Software Analytics

Lucas Dohmen:

Hallo und herzlich Willkommen zu einer neuen Folge des INNOQ Podcasts! Heute geht es um das Thema „Software Analytics“ und dafür habe ich mir den Markus eingeladen. Hallo Markus!

Markus Harrer:

Hallo Lucas!

Lucas Dohmen:

Bevor wir loslegen, wer bist du und was machst du so bei INNOQ?

Markus Harrer:

Mein Name ist Markus Harrer, ich bin Senior Consultant bei INNOQ. Ich mache vor allem Architektur, Design und Code Reviews, beschäftige mich oft mit Software-Modernisierung und -Sanierung und habe so ein kleines Steckenpferd, das ist die Datenanalyse in der Softwareentwicklung. Und ich freue mich, dass ich heute was darüber erzählen darf bei dir!

Lucas Dohmen:

Ja, cool! Dann lass uns doch direkt erstmal damit loslegen: Wie bist du denn auf dieses Thema gekommen? Und… Also was hat dich dahin geführt?

Markus Harrer:

Ja, ich bin eigentlich, ja, gestartet bin ich in das ganze Thema als ganz normaler Softwareentwickler. Ich war da vor allem, ja, ich sage mal bei der Weiterentwicklung von Bestandssystemen schon immer mit dabei, das macht mir irgendwie auch Spaß so Legacy Code und die ganzen Geschichten. Und ja, ich refactore auch gerne oder versuche dann auch so gewachsene Softwaresysteme wieder nach vorne zu bekommen. Und da hat es mir immer irgendwie so gefehlt an Gründen, weshalb ich denn dieses Softwaresystem jetzt verbessern möchte. Und da habe ich irgendwie mal versucht die ganzen Probleme, die in den Softwaresystemen stecken, ein bisschen so zu quantifizieren. Also einen Impact herauszukitzeln aus diesen Softwaresystemen, also wie schlimm ist es denn wirklich? Was kommt denn so an Aufwände auf uns zu, wenn wir jetzt da wirklich Hand anlegen? Und vor allem wo macht das jetzt noch Sinn im Softwaresystem was zu verbessern? Wo nicht? Und ja, da bin ich auf dieses ganze Thema gekommen und habe das bisher weitergetrieben und ja, habe mir da so einen Werkzeugkasten zusammengebaut, über den wir gerne mal reden können im Detail.

Lucas Dohmen:

Also ich glaube alle Entwicklerinnen und Entwickler kennen das, zumindest ich kenne das, dass man so ein System anschaut und man weiß tausend Dinge, die refactoren könnte, die noch besser sein könnten und irgendwann merkt man dann, wenn man länger entwickelt, dass diese Liste irgendwie unendlich lang wird und immer länger wird. Kann mir Software Analytics dabei helfen das zu priorisieren und wirklich die Dinge zu finden, wo es sich lohnt zu refactoren und zu verbessern?

Markus Harrer:

Ich denke schon. Die haben einen bisschen anderen Ansatz. Also wenn wir in der klassischen Entwicklung unterwegs sind haben wir ja sowas wie Quality Management Dashboards, sprich wir lassen mal so ein bisschen eine Software drüber laufen, die unsere eigene Software checkt und da kommen erstmal, ich sage mal tausende oder zehntausende an findings quer über diese ganze Codebasis verstreut. Und da ist natürlich klar, also das erschlägt einen erstmal, man weiß überhaupt nicht, wo man anfangen soll. Und das Software Analytics, so wie ich das sehe, bringt eben noch was mit, dass man diesen ganzen sehr feingranularen Probleme so zusammenfasst und später auch so kommunizierbar macht, dass letztendlich auch Entscheider oder Leute aus dem Fachbereich was mit anfangen können und dann nochmal Impact geben können, wie wichtig jetzt welche Bereiche von der Software sind. Wo wir dann wirklich Hand anlegen können, um einen Teil der findings wegzubekommen, diesem… ja das so ein statisches Codeanalyse Werkzeug beispielsweiser herausspuckt. Also diesen Transfer zu machen zwischen den was ganz unten unter der Haube ist in unserer Software und dem wie Business Leute auf Software die Augen drauf werfen, dass man damit eben Verbindungen herschaffen kann, da sehe ich Software Analytics vor allem.

Lucas Dohmen:

Sehr cool. Also du hattest das eben schon einmal kurz erwähnt, bevor wir da jetzt tiefer einsteigen, das Wort „Data Science“. Ich glaube davon haben schon viele gehört, aber kannst du mal ganz kurz erklären was Data Science ist? Weil das ist ja irgendwie ein bisschen die Grundlage zu dem Thema.

Markus Harrer:

Genau, ich habe auch in verschiedenen anderen Vorträgen immer gesagt: Ich mache letztendlich, wenn man es ganz vereinfacht, nichts anderes als Data Science auf Basis von Softwaredaten. Data Science normalerweise versucht ja aus geschäftlichen Daten neue Erkenntnisse herauszubekommen, ich versuche es eben mit den Daten, die bei der Entwicklung oder beim Betrieb der Softwareentwicklung anfallen. Und ja, das Thema Data Science, das an sich, ja, normale Definition ist auch: Ich suche versuche neue Erkenntnisse aus den Daten, die ich habe, herauszubekommen erstmal. Und was da noch mitschwingt ist eine komplette, ja, so ein Vorgehen, wie man denn wirklich auch strukturiert und nachvollziehbar diese Analysen im Data Science Bereich auch durchführt. Und davon kann man sich sehr stark auch inspirieren lassen für die eigenen Analysen in den Softwaresystem selbst. Man kann diese ganzen Methodiken verwenden, die es so gibt im Data Science Bereich. Dieses saubere Herausarbeiten, ja nach, ich sage schon fast wissenschaftlichen Prinzipien, damit andere auch verstehen, was man da gemacht hat in diesen Analysen und auch die Visualisierungsidee nehmen von Data Science heraus. Also wirklich auch dieses Wissen, nicht nur auf Zahlen, sondern auch vom Data Science Gedanken her getrieben so visualisieren, dass auch wieder Leute, die jetzt nicht gerade in der Materie oder in den Daten drinstecken, was mit anfangen können, was man da raus analysiert hat und auch passende Entscheidungen treffen zu können. Data Science für mich, also habe ich auch so definiert im Kontext von Software Analytics. Ich habe da mal so aufgeteilt zwischen dem Wort Data und Science logischerweise. Data Science das steht für mich so in dem Kontext von einem Zitat von Edwards Demings, der hat mal gesagt: „Without Data, you’re just another person with an opinion.“. Und ich sehe das Data auch so, dass man sagt: Wir versuchen halt wirklich auf Basis von den Daten, die wir haben, so Fakten herauszubekommen. Das ist für mich der Data Teil von Data Science und dann gibt es natürlich noch Science, da habe ich mir die Definition geschnappt im Lichte von einem Zitat von Albert Einstein. Der hat einmal gemeint, Science ist für ihn so, ja die explanation of complex facts in a simple way und dass sehe ich auch so aus den Science Bereich in Data Science. Wir versuchen nicht nur Daten eben herauszubekommen, sondern dass für anderen auch verständlich zu erarbeiten, nachvollziehbar zu machen.

Lucas Dohmen:

Okay. Also wenn ich jetzt deine Erklärung so höre, dann klingt das ja schon so ein bisschen nach Wissenschaft. Ich denke mal die meisten unserer Zuhörerinnen und Zuhörer sind so aus dem Architektur- und aus dem Entwicklungsbereich. Was für Skills brauche ich denn um mich mit dem Thema zu beschäftigen? Reichen da meine Programmier- und Architekturfähigkeiten aus oder brauche ich da noch irgendwas aus dem mathematischen Bereich oder so?

Markus Harrer:

Genau, so. Weshalb das alles so ein bisschen wissenschaftlich sich anhört, das hat auch einen Grund. Da kann man aber den Transfer zur Softwareentwicklung nochmal machen. Wo ich vor allem unterwegs bin, das ist die Analyse von so, ich sage mal, wirklichen Schlamasseln. Also Probleme, die jahrelang vielleicht irgendwie in der Softwareentwicklung bestehen oder an einen Softwareprodukt selbst bestehen und wo man vielleicht nicht mehr so genau hinschaut, weil dieses Problem halt schon ein gewisses Risiko ist für die erfolgreiche Weiterentwicklung von diesem Softwaresystem. Und ja, da kann man natürlich Analysen fahren, da kann man irgendwelche Tools aufmachen und mal kurz reinschauen, was denn noch so los ist, aber im Endeffekt sind solche, ja, Ergebnisse, die nur durch ein Werkzeug mal ganz kurz irgendwie platziert werden über ein Dashboard oder sowas, ja, nicht wirklich belastbar. Es kann sein, dass man nicht genau weiß wie das Werkzeug arbeitet intern, man weiß gar nicht wie man diese Zahl interpretieren kann, was da rauskommt. Und ich finde eben in diesen, ja Data Science basierten Ansatz, da schwingt so ein Weg mit, um auch anderen transparent zu machen, was ich denn aus den Rohdaten herausziehe, was ich daraus lese. Und das mache ich eben mit so einen offenen, ich sage mal wissenschaftlich angehauchten Weg, indem ich meine Analysen total transparent durchführe. Da gibt es von der Technik her einen schönen Ansatz, der nennt sich dann Computational Notebook Ansatz oder das kommt so aus literate programming, ein Werkzeug, ein ganz konkretes, das Jupyter Notebook. Damit kann ich eben so Analysen wirklich von Rohdaten bis hin zu, ja meinen Modellen, meinen Visualisierungen im Endeffekt, Schritt für Schritt aufzeigen, transparent machen, offen machen, damit andere auch wirklich lesen können: Was tue ich denn genau mit den Daten? Wie arbeite ich denn genau diese, ja, Probleme heraus, die mich da interessieren? Und dieses saubere Herausarbeiten, das bringt eben auch noch zusätzlich mit sich, dass man da auch weniger angreifbar ist mit seinen Analysen. Man lässt die, ich sage mal die Hosen herunter, man zeigt halt wirklich, was man so gemacht hat in seiner Analyse und das macht halt so eine Analyse auch robust und auch mehr Vertrauenswürdig.

Lucas Dohmen:

Also wenn ich es richtig verstehe, ist das schon anders, als wenn ich mir jetzt sowas wie SonarQube oder sowas anschaue, was irgendwie einfach… man gibt gar keine Aufgabe an das Tool, sondern man sagt einfach: Analysiere diese Software. Und das ist im Ansatz, den du beschreibst, anders, da habe ich schon eine Forschungsfrage, eine Frage, auf die ich eine Antwort will und auf die arbeite ich zu, richtig?

Markus Harrer:

Genauso ist das. Also du startest immer mit einer Frage, eine Problemstellung, die dich interessiert, um dann erstmal die Daten… Also im nächsten Schritt erstmal die Daten in deinem Unternehmen oder deinem Umfeld der Softwareentwicklung zu identifizieren, die dir weiterhelfen können diese Fragen, diese Fragestellungen zu beantworten. Wenn man sowas hat wie SonarQube, da hast du erstmal, ich sage mal Antworten auf Fragen, die du nie gestellt hast. Und ja, vielleicht suchst du so eine Frage aus, die eben durch so ein Werkzeug wie SonarQube beantwortbar ist, aber nicht wirklich eine Fragestellung, die du dann wirklich in deiner individuellen Softwareentwicklung weiterbringt.

Lucas Dohmen:

Okay. Okay, bevor wir jetzt irgendwie auf die Fragen eingehen: Welche Arten von Informationen fließen denn in meine Analyse ein? Also welche Arten von Daten gibt es auf denen ich meine Analyse dann durchführe?

Markus Harrer:

Ja, das ist auch wieder ganz vielfältig. Muss man ein bisschen die Augen aufmachen. Also ganz klassisch hat man natürlich den Quellcode, den man schreibt in einer Programmiersprache vorliegen, die man auch mag. Selbst da hat man schon sehr viele Informationen drinnen, wie beispielsweise, wenn ich eine Objekt-orientierte Programmiersprache habe wie Java, dann habe ich sowas drin wie Beziehungen zwischen Klassen, Methoden und Feldern, zu anderen Klassen, das sind so strukturelle Informationen, die ich nutzen kann. Ich kann auch beispielsweise direkt in den Quelltext selbst schauen. Ich könnte da auch sowas machen wie Textminingverfahren anwenden, um zu schauen ob es da vielleicht, ja, gewisse Bereiche meiner Software gibt, wo sich Begriffe ziemlich ähneln, um dann vielleicht heraus zu schlussfolgern, dass ich da ein neues Modul hineinbauen könnte, wo sprachlich zusammengehörende Begriffe sich dann befinden. Man kann auch Laufzeitdaten verwenden, also alles was irgendwie während des Betriebs der Software anfällt, klassisch irgendwo Log-Dateien, wo Zugriffsstatistiken drin sind, Nutzungsstatistiken oder auch Performance Messdaten. Bei Performance Messdaten kann ich nochmal tiefer gehen, ich kann so call traces oder stack traces mir anschauen, so sehen wie Aufrufbeziehungen sind wirklich während des Betriebs des Softwaresystems. Ich habe sowas wie chronologische Daten, das ist alles was irgendwie so in der Vergangenheit auch liegt, kann ich Ticketsysteme mit reinnehmen, um so ein bisschen auf den Prozess draufzuschauen, wie ich denn entwickle. Damit brauche, um dann auch Features weiterzuentwickeln. Ich kann aber auch Versionskontrollsysteme anzapfen und da mal gucken: Wer hat denn was wann warum geändert? Dann kann ich auch verschiedene Trendanalysen auch machen, mal schauen, wie Fortschritte in meiner Softwareentwicklung so passiert sind. Und so ein ganz anderes Thema ist noch so Community Daten. Wir entwickeln ja immer mal im, ich sage mal öffentlichen Raum teilweise im Internet, auf Plattformen wie GitHub oder es gibt Fragestellungen oder Frageplattformen wie Stack Overflow. Da kann man auch sehr schön Daten analysieren und schauen beispielsweise, wie fit ist denn so ein Open Source Projekt? Indem man guckt, ja was tut sich denn in diesen Software Projekt? Wie ist denn die Aktivität in den Foren? Wie sieht es denn aus auf Stack Overflow mit Fragen und Antworten? Wie aktiv ist denn da diese Community? Das kann man alles verwenden und dann, wenn so eine Frage da ist, die passenden Daten dann auswählen.

Lucas Dohmen:

Cool. Also was ich jetzt so in deiner Liste nicht gehört habe, wäre so etwas wie Anwendungsdaten, also in meine Datenbank reinschauen, was da für Daten abgelegt wird, das gehört gar nicht zu dem Thema dazu, richtig?

Markus Harrer:

Das würde ich ein bisschen abgrenzen, da gibt es einen ganz schönen Bereich mit Datenqualitätsmanagement Werkzeugen, die man da einsetzen kann. Ich würde eher sagen, ja man hat in den Software Analytics Bereich da mehr mit Strukturen zu tun. Also Datenbank Schemata analysieren beispielsweise, mal zu gucken, wie die ganzen Beziehungen auch sind zwischen Tabellen. Also was wir da eher sehen und weniger die eigentliche Anwendungsanalyse, das wäre ein anderes Gebiet.

Lucas Dohmen:

Okay. Wir haben jetzt so ein bisschen über die Datenquellen gesprochen. Du hast auch schon eins von deinen Werkzeugen erwähnt, das war Jupyter Notebooks. Was für Werkzeuge setzt du denn noch ein in so einer Analyse?

Markus Harrer:

Also mir war wichtig ein Stack zu finden, wo ich nicht viel Zeit investieren muss zur Einarbeitung und gleichzeitig ein Stack zu finden, den ich auch für andere Zwecke wie die Analyse von Software Daten verwenden kann. Also eine Alternative wäre natürlich gewesen ich arbeite mich in ein Softwareanalyse Werkzeug ein eines Herstellers oder eines Open Source Produkts. Ja aber, man muss es auch so sehen, man ist ja nicht tagtäglich am Analysieren von irgendwelchen Softwaresystemen, sondern das muss erstmal, ja, wenn den Bedarf gibt, dann macht man das und hat dann wie gesagt keine Zeit da irgendwie auch dann Lizenzen zu organisieren oder sich wieder einarbeiten in das Tool, das man sich mal rausgesucht hat. Und deswegen gehe ich auf einen ganz klassischen Data Science basierten Stack, und zwar einen Python basierten Data Science Werkzeug Stack mit Python, als tragende Programmiersprache, mit Pandas als Datenanalyse Werkzeug, Matplotlib als Visualisierungsbibliothek und eben auch diesen Jupyter Notebook, um diese Analysen letztendlich auch durchzuführen, niederzuschreiben und anderen auch zu kommunizieren. Das ist jetzt, ich sage mal der eine Teil, wenn es darum geht vor allem so tabellenartige Datenstrukturen auszuwerten. Ich würde sagen ist ungefähr so 70–80% der Fall, dass man immer so in tabellenartigen Strukturen arbeitet. Aber dann gibt es für die Analysen im Software Bereich doch noch ein paar Spezialfälle, wo man auch noch ein anderes Werkzeug braucht oder auch noch eine andere Art von Werkzeugen braucht. Und da habe ich noch einen kleinen Werkzeugkasten aus dem Graph Datenbank Bereich mit JQAssistant, das ist so eine Art struktureller Scanner für, ja, vernetzte Daten aus dem Software Bereich, Neo4j als Datenbank, als Graph-orientierte Datenbank zum Ablegen von stark vernetzten Daten und auch eine Abfragesprache namens Cypher, so ähnlich wie SQL eben für Graph-Datenbanken, wo man dann auch entsprechende Analysen fahren kann eben für sehr stark vernetzte Daten, wie beispielsweise Java Code oder irgendwelche Call Graphen, die man hat von einen Performance Messwerkzeug.

Lucas Dohmen:

Okay, cool! Dann haben wir jetzt glaube ich schon eine ganz gute Vorstellung davon was das so tut. Lass uns doch mal in ein Beispiel reingehen. Was… Kannst du, hast du ein Beispiel was man zum Beispiel mit diesen Tools und diesen Ideen analysieren könnte?

Markus Harrer:

Ja, da würde ich einfach mal so einen Rundumschlag machen. Ein bisschen so einen Eindruck dafür zu geben, ja, welche Varianten es alles so gibt auch, welche Verwendungsszenarien es da so gibt. Wo ich Software Analytics immer gerne einsetze, ich habe es vorhin schon gesagt, das sind so richtige Schlamassel. Meistens sind das so Themen wie, ja, meine Anwendung performt überhaupt nicht mehr beispielsweise. Und ja, da habe ich mal eine etwas größere Analyse gemacht, wo es verschiedene Aspekte auch von Software Analytics zum Tragen kamen. Und zwar das war so eine Anwendung, ich sage mal zur Verwaltung von Verträgen und ja, die hatte eben sehr krasse Performance Probleme. Wir hatten aber initial angefangen mit einer Messung, mit einem klassischen Profiling Werkzeug, da sind wir so auf Zahlen gekommen wie, pro Klick in der Anwendung verursachen wir so 250 Datenbankcalls und 50 Service Aufrufe zu externen Systemen. Und ja, das war natürlich ein bisschen unbefriedigend bezüglich der Performance mit so einem System zu arbeiten, das war vielleicht mal skaliert für 10 Nutzer. Das war so eine Webanwendung, die man dafür gebaut hatte. Und ja, wo fängt man jetzt da an zu verbessern? Da habe ich dann eine Analyse geschnitten, die dann wirklich auch transparent macht, wie komme ich denn zu diesen Messergebnissen? Da kommen wir wieder zu diesen, was von den Data Science rüber spielt, dieses saubere Arbeiten oder dieses saubere Erarbeiten von Analyseergebnissen. Da muss man sehr stark drauf achten das transparent zu machen, welche Eingangsdaten man da hatte, wie das Testsystem denn selbst auch gestaltet war, welche Umgebungen denn auch irgendwie noch bei den Durchführungen von den Tests für die Performance eine Rolle gespielt hatten. Das muss alles erstmal so sauber strukturiert werden, um dann möglichst wenig angreifbar zu sein bei der letztendlichen Analyse, ja diesen letztendlichen Ergebnis, was man da fabriziert hatte. Und das ging, indem man, ich sage auch wieder diesen Computational Notebook Ansatz, Schritt für Schritt Performancemessdaten eingelesen hatte und auf einer sehr, ich sage mal detaillierten Detailstufe, also man hat wirklich gesehen: Ja okay, es gibt verschiedene Methoden Calls, die fabrizieren letztendlich total viele Datenbankstatements in den gewissen Bereich der Anwendung. Und dann erstmal versucht hat eine neue Sicht draufzuwerfen, also dass irgendwie diese Daten so umzugestalten, dass man das fachlich auch einschätzen kann, ob jetzt diese Datenbankcalls so sinnvoll sind oder ob die… ob es da nicht doch einen Fehler gibt bei den ganzen Zugriffszahlen auf die Datenbank. Als Beispiel, das herausgekommen ist: Man hat vielleicht so eine Anzeige von den Versicherungsnehmer und hat dann darunterliegend, ich sage mal 300 Datenbank Calls gesehen nur um die Anzeige einer Person darzustellen und selbst das konnten jetzt, ich sage mal auch Fachler einschätzen, dass da irgendwas im argen liegt. Und wurden dann mehr, ich sage mal für sensibilisiert, dass man da doch mal Hand anlegen sollte. So dann steht man eben da mit der ersten Auswertung, man hat das sauber herausgearbeitet aus den Rohdaten, aus den Performance Messungen, inklusive der Schilderung wie man das ganze von vollzogen hat, unter welchen Bedingungen diese Analyse entstanden ist. So das ist jetzt ungefähr auf der Ebene eines SonarQubes, wir haben immer total viele Probleme irgendwo quer durch die Landschaft schonmal aufgeführt, haben aber das so ein bisschen gesagt mit Fachwissen so angehaucht. Wir wissen, es gibt etwas zu tun und ja, das ist schonmal ein erster Schritt oder eine erste Art von Analysen, die ich da durchführen kann mit Software Analytics. Da geht es natürlich auch weiter, also wenn ich nur Probleme jetzt auf dem Tisch liegen habe, habe ich ja noch nichts gewonnen. Ich muss die ja noch irgendwie wegbekommen. Da gibt es noch so einen zweiten, also so eine zweite Variante von Software Analytics, man kann auch ziemlich gut so Impact-Analysen machen oder Auswirkungsanalysen. Und im Endeffekt Analysen machen, wo muss ich denn jetzt genau hin greifen in meiner Software, um diese Performance Probleme wegzubekommen? Das funktioniert eigentlich auch ziemlich gut und man kann auch, sagen wir mal, einfach starten. Was ich da oft mache oder gerne mach ist, erstmal in meine IDE nachgucken, wo kommen denn diese ganzen Probleme her? Dann nehme ich mir einen einzigen Anwendungsfall und navigiere durch die Softwarestrukturen durch, um dann das beispielsweise an gewissen Klassenbeziehungen oder Namensschemata festzumachen, wo denn diese ungerechtfertigten Calls zu einer Datenbank stattfinden. Das mache ich, wie gesagt, einmal manuell und dann kann ich da drauf aufbauen, wieder eine automatisierte Analyse bauen, um dann alle weiteren Stellen, die diese ähnliche Strukturen, diese ähnlichen Muster folgen, auch automatisiert herauszubekommen und das eben aus meiner kompletten Software Basis, für die ganze Software. Das kann man sich so vorstellen, das ergibt dann so Listen, beispielsweise Listen mit Klassennamen und Quellcodezeilen Nummern, wo ich dann Hand anfassen muss, um etwas umzustellen und dann kann ich dann auch parallel so kleine Rezepte noch mit dazugeben, um dann an diesen Stellen, die herausgefallen sind aus der Analyse, zu sagen, was man alles genau umstellen muss in diesem Fall von diesem Performance Problem. Ja, vielleicht nochmal so eine Zwischenklasse einfügen, wo man dann weniger Daten aus der Datenbank lädt, das kann so ein Rezept sein und im Zusammenhang mit so einer Liste, wo man hin fassen muss gibt es so eine ziemlich klare Anweisung, wie man dieses Problem auch letztendlich wegbekommt. Das ist so dieser zweite Aspekt. Diese Auswirkungsanalyse, aber auch so eine Liste, wie gesagt, von Problemstellen und die Rezepte, wie man das ganze noch wegbekommt. Dann kann es aber noch mal passieren, dass diese Reparatur, die man da durchführen muss, sehr lange dauert. Da können wir noch so einen dritten Aspekt mit reinnehmen von Software Analytics, und zwar dieses Tracking über längere Zeit hinweg, wo ich versuche kontinuierlich nachzuverfolgen, ob die Probleme, die ich herausbaue aus der Software auch wirklich rausgehen. Kann ich auch beispielsweise über ein paar Sprints an Basis meiner Versionskontrollsystem Daten mal nachverfolgen: Was habe ich denn jetzt schon geschafft an den Umstellungen, die ich mir vorgenommen habe? Und damit auch wieder Transparenz schaffen gegenüber meinen Auftraggebern und zu zeigen, dass ich da wirklich an diesem Problem immer noch kontinuierlich dran bin, dass sich da was tut. Ja, das dauert vielleicht länger, aber ich habe eben auf Basis von so einer Software Datenanalyse zumindest mal Transparenz geschaffen, dass ich da wie gesagt dran bin. Das ist so ein dritter Aspekt, so eine kontinuierliche Verfolgung von Refactoring-Tätigkeiten, die man da auch sehr gut abdecken kann mit diesem Software Analytics Ansatz.

Lucas Dohmen:

Finde ich ein sehr gutes Beispiel, weil es irgendwie direkt ganz breite Daten abdeckt. Also sowohl historische Daten als auch irgendwie den Code selbst. Ist das dann halt auch so, dass man aus dieser Analyse dann Rückschlüsse aufs Team oder auf die Teamzusammensetzung machen kann? Oder vielleicht auch herausfinden kann welche Auswirkungen das Wegfallen von bestimmten Entwicklern oder Entwicklerinnen, also wenn die krank sind oder sowas, haben würde? Oder stelle ich mir das falsch vor?

Markus Harrer:

Ja, das kannst du auch machen. Also da musst du halt immer aufpassen, ob man das auch darf im eigenen Unternehmen. Also Stichwort Leistungs- und Verhaltenskontrolle oder Datenschutz. Aber das kann man durchaus tun und ja, indem man, ich sage mal, ich gehe da soweit mit, wenn man das teambasiert analysiert, also nicht auf einzelne Personen hinunterbricht, dann kann man das schon auch anhand von Versionskontrollsystem Daten tun. Und zwar mal gucken: Habe ich irgendwo in irgendwelchen Bereichen meiner Software Wissensinseln, wo ich vielleicht sehe: Es haben sehr wenige Personen in diesem Modul immer gearbeitet und vielleicht haben die jetzt im letzten halben Jahr da gar nichts mehr getan. Vielleicht habe ich sogar verloren das Wissen in gewissen Modulen. Sowas kann ich auch in einer sehr einfachen Analyse machen mit Versionskontrollsystem Daten beispielsweise aus dem Versionskontrollsystem git. Das wäre durchaus auch ein sehr schnell machbarer Fall auch, den man da durchführen kann.

Lucas Dohmen:

Okay, also dein Beispiel war jetzt so ein System was irgendwie ein System ist. Kann ich sowas auch auf verteile Systeme anwenden oder ist das nur möglich, wenn ich wirklich einen Monolithen, ein monolithisches System habe?

Markus Harrer:

Ja, da würde ich sagen kommt es erstmal auf deine Fragestellung an, die du hast. Also wenn du beispielsweise das Kommunikationsverhalten zwischen den verschiedenen verteilten Systemen analysierten möchtest, da kannst du das ganz einfach auch machen, indem du diese distributed tracing mit analysierst und anzapfst, und dann auswertest. Das wäre dahingehend kein Problem. Wenn du dann ein bisschen weiter runtergehen möchtest auf die Code Ebene oder ja, analysieren möchtest, ob da so ungewollte Abhängigkeiten mit drin sind, das kannst du auch versuchen über so Laufzeitanalyse zu machen über dein verteiltes System. Aber es gibt auch durchgeführte Analysen, die ich kenne, wo auch mit Hilfe von Graph-Datenbanken eine, ja, Micro Services Landschaft analysiert wurde. Da muss man natürlich ein bisschen speziellere Verfahren nochmal mit reinbringen. Mir ist jetzt eins bekannt, wo man so eine Art Schnittstellen-Matching gemacht hatte zwischen Clients und Service Providern. Und in diesen Schnittstellen-Matching sozusagen noch so Abhängigkeiten zwischen verschiedenen Modulen reverse-Engineered hat, um da auch zu sehen, wie da die Abhängigkeiten sind zwischen den verschiedenen Micro Services. Da gibt es einen schönen Talk, der nennt sich „fixing your micro service architecture using graph analysis“ von Nicholas Mervaillie, den können wir gerne auch mal verlinken. Also da gibt es auf jeden Fall auch etwas, für ich sage mal modernere Software Architekturen oder Architektur Stile, die auch datenorientierter analysiert werden können.

Lucas Dohmen:

Cool! Wenn ich jetzt als Zuhörerin oder Zuhörer Lust bekommen habe mich mit dem Thema zu beschäftigen, wie würde ich denn da einsteigen? Was kann mir da mal anschauen, um loszulegen?

Markus Harrer:

Ja, da gibt es verschiedene Möglichkeiten. Also ich hätte zwei Buchtipps an dieser Stelle, die kann ich glaube ich gleich nennen. Das eine ist eher so schon fast so ein Klassiker von Adam Tornhill, das Buch „Software Design X-Rays“. Der gibt auch so einen Rundumschlag und eine supergute Motivation weshalb man sich mit diesen Analysen von Softwaredaten überhaupt so beschäftigen soll. Wer es so ein bisschen von der akademischen Seite haben möchte, da gibt es auch ein schönes Buch von Thomas Zimmermann und Tim Menzies, das nennt sich „perspectives on data science for software engineering“. Da haben, ich sage mal ja, diese ganze Community rund um dieses Thema Software Analytics ein schönes Buch zusammengestellt mit ganz vielen unterschiedlichen Artikeln, die sehr viele Facetten von Software Analytics nochmal aufzeigen. Da kann man sicherlich sich schön damit beschäftigen und einsteigen, um nochmal zu gucken, ob das Thema auch was für einen ist. Und ja, auch von mir gibt es etwas. Ich habe einen Blog. Mein Blog ist festelltaste.de, da schreibe ich ab und zu mal über Analysen, die ich selbst durchgeführt habe und da gebe ich auch immer was zurück. Ich habe beispielsweise auch sowas, wie eine Awesome-List gebaut für Software Analytics, wo ich verschiedene Ressourcen aus dem Internet zusammensammele, um Leuten dieses Thema Software Analytics auch nahe zu bringen. Das ist eine Sammlung an Talks, wichtigen Papers, hands-ons Workshops, wenn es das was gibt. Das sammele ich auf dieser Webseite, da kann sicher auch das ein oder andere finden, womit man diesen Einstieg machen kann. Ich habe auch ein paar Repositories auf GitHub.com. Das Repository Software Analytics, da sind ganz viele Notebooks, die ich mal angefertigt habe zum Einsehen. Und da gibt es auch ein GitHub Repository zum Mini-Tutorial, wo man auch direkt mal loslegen kann mit so geführten Software Datenanalysen. Da gibt es ein paar Aufgabenstellungen, die man abarbeiten kann, wo man so ein bisschen herangeführt wird an die Syntax von Pandas, Python und co. Und ja, ich habe auch einen Workshop, den ich anbiete, ein Training. Es geht über zwei Tage oder vier Halbtage, da kann man auch gerne mal den Einstieg in Software Analytics wagen.

Lucas Dohmen:

Ja, sehr cool! Dann packen wir in die Shownotes einmal den Link zu deinem Training und auch zu allem anderen, was du uns heute so erzählt hast: Zu deinem GitHub und so weiter. Und dann danke ich dir für diesen tollen Überblick. Und den Zuhörerinnen und Zuhörern, den sage ich mal: Bis zum nächsten Mal! Tschüss!

Markus Harrer:

Ciao!