Entwicklung eines Tools zur Suche und Ansammlung von forschungsrelevanten Open Source Code aus Github
Diese Seite befasst sich mit dem Werdegang der Bachelorabrbeit, welcher sich mit technical debt befasst.1 Motivation der Arbeit
Diese Arbeit bewegt sich im Themenbereich von Technical Debt. Diese sogenannten technischen Schulden entstehen in der Softwareentwicklung. Anstelle von qualitativ hochwertigeren, aber gleichzeitig zeitaufwendigeren Ansätzen, werden dabei provisorische Lösungsansätze implementiert. Der Aufwand, den jene Schulden durch beispielsweise nötige Änderungen im Code erzeugen, kann zu mehr Kosten führen als es die ursprünglich vorgesehene Alternative gerechtfertigt hätte. Um dies entgegen zu steuern, kann Refactoring betrieben werden. Das beschreibt die verbesserte Umstrukturierung des Codes ohne dessen Semantik zu ändern. Für die Forschung dieser Refractoring-Tools oder allgemein des Themengebiets werden qualitative als auch quantitative Datensätze benötigt. Ein Ansatz zur Datensatzbeschaffung ist die Nutzung von Open Source Code auf Entwicklungsplattformen wie GitHub. Die Ansammlung von solchen Datensätzen ist jedoch nicht trivial, da GitHub nicht über die nötigen Filter verfügt, um auf direkten Wege an die gewünschten Datensätze zu kommen. Meine Bachelorarbeit soll sich mit der Überbrückung dieses Konflikts befassen und eine für die Forschung nutzbare Lösung implementieren.2 Zielstellung
Das Ziel dieser Bachelorarbeit wird es sein ein Tool zu implementieren, das die genannte Problematik behebt. Dabei wird es konkret dem Forschungszweck der Arbeitsgruppe und dessen Anforderungen angepasst, um qualitative Datensätze zu liefern. Das Tool wird anschließend für die weitere Forschung und dessen möglicherweise ändernden Anforderungen genutzt, weswegen es eventuell das Hinzufügen von zusätzlichen Funktionalitäten erlauben soll.
2.1 Technische Umsetzung
Für die Realisierung des Tools wird unter anderem die Programmiersprache Python verwendet. Darüber hinaus gewährt die offizielle GitHub API ’REST API v3’ den essentiellen Zugriff auf die gewünschten Repositories. Die gefilterten Repositories werden zudem entweder lokal oder extern in einer Datenbank gespeichert, um langfristig eine Ansammlung an Forschungsrelevanten Datensätzen zu estellen.3 Zeitplan und Struktur der Arbeit
Implementierung des Tools (6 Wochen)- API-Suchanfrage – Das Tool wird über einen indirekten Weg auf die gewünschte Metrik zugreifen können. Dabei wird versucht auf die effizienteste Möglichkeit aufzubauen, da die API-Suchfrage den Grundbaustein jeder einzelenen Iteration darstellt.
- Algorithmus zur Filterung - Die gefundenen Datensätze müssen nun gefiltert werden. Hierbei werden die Repositories auf ihre Relevanz für die Forschung geprüft und aussortiert. Dabei wird nicht nur auf Codemuster geachtet, sondern auch insbesondere auf code-externe Aspekte wie Issues oder auch Code Frequency. Vermutlich werden die Codeabschnitte für die Implemtierung von ’API-Suchanfrage’ und ’Algorithmus zur Filterung’ auch teilweise ineinander verschmolzen sein.
- Datensatzspeicherung – Abschließend werden die relevanten Datensätze abgespeichert. Diese werden entweder lokal oder extern in einer Datenbank oder gar einer simplen Ordnerstruktur gesammelt. Dies ist ein noch recht offener Aspekt, der sich mit genaueren Anforderungen klärt.
- Dokumentation des Tools – Wie jedes Tool soll auch dieses eine Dokumentation erhalten, die auf das Verständnis, die korrekte Nutzung und Wartbarkeit eingeht. Die Wartbarkeit ist dabei ein wichtiger Anhaltspunkt, da sich dieser auf die zukünftige Erweiterbarkeit bezieht.
- manuelle gegen automatisierte Suche – Nachdem das Tool fertig implementiert ist, wird hierbei getestet wie effektiv es funktioniert. Quantitativ kann es trivialerweise um einiges mehr leisten, jedoch muss auch der Fokus auf die Qualität der gefundenen Datensätze gelegt werden, um eine Daseinberechtigung des Tools zu gewährleisten.
- Laufzeit und Effizienz – Beim Arbeiten mit einer API kann es zu schnell zu übereifrigen Anfragen kommen, die die Laufzeit und Effizienz des Programms stark einschränken. In diesem Abschnitt wird auf theoretischer Analyse geprüft wie hochwertig das Tool in den beiden genannten Aspekten ist.
Schreiben der Arbeit (4 Wochen)