Selbstverständlich werde ich nicht über die Wahl schlechter Werkzeuge, die mir beruflich begegnet im Detail schreiben: Vertraulichkeit von Anfragen ist selbstverständlich. Überhaupt: Wir sind alle mal angefangen und — Hand auf Herz — da hat die Eine oder der Andere auch schon mal eine Frage auf DAU-Niveau (oder nahe dran) gestellt. Das hier zu bloggen wäre weder lehrreich noch lustig.
Andererseits … andererseits erstaunt immer wieder wie schlecht akademische Arbeitsgruppen planen. Da ich im HPC-Bereich arbeite, kommen mir natürlich immer wieder AnwenderInnen unter, deren ChefInnen sie ins kalte Wasser werfen oder völlig unzureichende Software für diese auswählen. Diese Liste könnte(!) laaaaang werden. Wenn man das so recht überlegt: Ein Trauerspiel, denn so kostet die Forschung mehr Zeit, werden Studierende frustriert, im Zweifel scheitert gleich das ganze Projekt und der Lerneffekt ist mies. Im Grunde genommen ist es hierbei gleichgültig, ob es um die Planung von Datenauswertung oder Laborexperimente oder irgendetwas Anderes geht.
Und so werde ich meine Serie über die Auswahl von (Software)-Werkzeugen sicher fortsetzen, hier im Blog aber auch über bestimmte gute und schlechte Software schreiben. In meinem Fokus steht die Bioinformatik und so kann ich hoffentlich einen Blick darauf werfen, was im Zentrum der Forschung steht und wie es um den Stand der Softwareentwicklung dort steht.
Wie wissenschaftliche AnwenderInnen Ihre Software auswählen? Natürlich aus Veröffentlichungen! Schauen wir uns eine an, die mir vor ein paar Tagen beruflich untergekommen ist:
Heute: PRAP
“PRAP” steht für Pan Resistome analysis pipeline und die Veröffentlichung hierzu erschien in BMC Bioinformatics am 15. Januar 2020.
Worum geht es?
Die Software zielt darauf die Muster von Antibiotika-Resistenz Genen in bakteriellen Populationen zu erkennen. Da zwischen Bakterien horizontaler Gentransfer geschehen kann, also die Übertragung von Genen zwischen Arten, können pathogene Bakterien Resistenzen von anderen Arten erhalten. Die Software beabsichtigt diese Gene zu erkennen, zu annotieren und die Verteilung der Allele mittels random-forest Klassifikation zu gliedern.
Wer hat es geschrieben?
Die Autoren geben folgende Verbindungen an:
Mit anderen Worten: Keine Gruppen aus der Informatik oder Bioinformatik. An und für sich kein Problem, schließlich können auch nicht-IT Gruppen IT-affine Mitglieder und gute ProgrammiererInnen aufweisen. Allerdings bin ich der Auffassung, dass u. U. die Betreuung darunter leiden kann, wenn sich die BetreuerInnen nicht auskennen.
Ist die Software gewartet?
Das Software-Repository von PRAP weist zum heutigen Zeitpunkt (7. Feb. 2020) 22 Einspielungen (commits) auf, der Letzte war am 19. November 2020, also etwa zwei Monate vor der Veröffentlichung, insg. gibt es das Label “Add files via upload” 9 Mal. Am häufigsten wurde die Datei “README.md” verändert. Es gibt kein Release, nur einen Entwicklungszweig, einen Entwickler.
Wie installiert man die Software?
Zur Installation möge man das Repository “klonen”, Pythonpakete, sowie eine Drittsoftware (Blast) installieren. Es gibt kein Installationsprogram oder eine Unterstützung für Softwaremanagement jedweder Art.
Code-Metrik?
Der Download umfasst einige Megabyte, davon entfallen 1,6MB auf die Anleitung (ein PDF) und 7,5 MB auf die mitgelieferte Beispieldatenbank. Ich verwende ein einfaches Werkzeug, um einen Überblick über die Sprachen und die Modularisierung (wieviele Quellcodedateien) zu schaffen: Insgesamt gibt es 13 Pythondateien mit 3079 Zeilen Code. Ein anderes Mal gebe ich an dieser Stelle vielleicht weitere Metriken an, hier lohnt das wenig (s.u.).
Wie steht es um die Qualität des Codes?
- Das “Masterskript” versucht sich in Selbstbau-Argumentparsing, obwohl die Programmiersprache (Python) in ihrer Standardbibliothek hierzu eine Lösung anbietet.
- Es gibt ein Eigenbau “FileHandle.py”, um den Umgang mit Dateien zu erleichtern, obwohl die Programmiersprache in ihrer Standardbibliothek hierzu eine Lösung anbietet.
- Es gibt keinen Shebang, somit kann der Code nicht einfach installiert und in den ”PATH” des (Linux)-System bekannt gemacht und “einfach so” gestartet werden; der explizite Aufruf des Pythoninterpreters ist notwendig.
- Aufruf von Drittprogrammen geschieht über die
os.system()-Funktion, d. h. es Besteht keine Kontrolle über die Rückgabewerte des aufgerufenen Programms und keine Möglichkeit der Fehlerbehandlung. Hierzu bietet die Standardbibliothek der Programmiersprache ebenso eine Lösung an. Die Dokumentation merkt sogar an, dass die verlinkte Bibliothek den Ersatz für den veralteten Ansatzos.systemdarstellt. - Mitten im Verlauf des Programms wird Eingabe der NutzerInnen erwartet, z. B.:
choose = input("update blast result for "+each_name+" (Y/N)?:").upper() - Die Software weist enorm viele Verletzung der Stilempfehlungen zu Python (der verwendeten Programmiersprache) auf. Ins Gewicht fallen
- rel. vielen verschachtelte Funktionsdefinitionen
- viele unnötige Listenzugriffe in Schleifen
- unzählige schlecht lesbare String-Manipulationen
Dies ist der Punkt an dem ich aufgebe: Die Liste ließe sicher fortsetzen, vielleicht habe ich auch einen größeren Klops übersehen?
Das Fazit:
Die Autoren befinden, dass die Software gut funktioniert und prima Resultate liefert. Das mag sein, jedenfalls enthält der Artikel Rechtschreibfehler. Das kann vorkommen (hier im Blog bestimmt auch wieder), aber bei einem peer-reviewtem Artikel, an dem viele Autoren gearbeitet haben?
Softwarereleases sind für AnwenderInnen der einzige Weg eine (wissenschaftliche) Software zitierbar zu machen und das A&O des reproduzierbaren Arbeitens mit Software. Wenn diese fehlen, kann ich als Administrator sie auch nicht als Modulfile installieren – schließlich brauchen wir auch Versionsnummern, auf die man sich berufen kann bei Fehlermeldungen. Hier schließt sich der Kreis – die Software ist ja nicht gewartet. Ein Fall von publish and forget.
Zum gegenwärtigen Zeitpunkt würde ich eher in einer studentischen Arbeit die Anforderung nachbauen lassen, als diese Software zu “installieren”.
Kommentare (2)