Boehrsi.de - IT und Gaming Blog

Im Rahmen der Software-Entwicklung nutzt man oft Libraries, Tooling und andere Dinge die man selbst nicht komplett durchdringt. Dies ist zu bestimmten Teilen auch in Ordnung und an der Tagesordnung, doch manchmal ist eine Software-Blackbox ein extremes Problem.
Doch definieren wir erst einmal Blackbox. Für mich ist eine Blackbox im Software-Bereich eine Komponente, die man selbst nicht durchdringt und die nicht mit akzeptablem Zeitaufwand, aus welchen Gründen auch immer, verstanden werden kann. Gründe sind hier, auch wenn es sich um Open Source Software handelt, andere Programmiersprachen, zu komplexe Konzepte, fehlende Dokumentation oder ähnliches. Closed Source Software ist natürlich per-se eine Blackbox.

Wann ist eine Blackbox aber nun ein Problem? Meiner Meinung nach wenn sie grundlegende Konzept abstrahiert oder zu essentielle Abläufe übernimmt und dem Entwickler dabei nicht klar ist was wann passiert und warum. Nimmt man z.B. das Build-Tool Gradle open_in_new, so hätte man vielleicht eine Blackbox vor Augen. Diese funktioniert allerdings sehr gut, es gibt eine sehr umfangreiche Dokumentation und auch weitere Ressourcen sind vorhanden. Hier muss man also Vorsicht walten lassen bei Updates und ähnlichem, falls man nicht durchdringt was dies bedeuten könnte. Doch durch vorhandene Dokumentation kann man sich entsprechend und mit akzeptablem Zeitaufwand schlau machen. Insofern würde ich persönlich nicht von einer Blackbox reden, wenn es um Gradle geht.
Hat man nun aber ein derartig wichtiges Tool (z.B. für die Build-Toolchain) oder eine Library die grundlegende Funktionen der eigenen Software übernimmt (z.B. Netzwerk-Interaktionen oder die Implementierung von Protokollen) und eine derartige Informationsquelle ist nicht gegeben, kann man sich in große Probleme manövrieren.

Ein paar der gravierendsten Punkte für mich sind die folgenden:

• Debugging kann extrem schwer und zeitaufwendig werden
• Durch fehlendes Verständnis für interne Konzepte der Blackbox können Änderungen am eigenen Code schnell zu Problemen führen
• Erweiterungen oder Anpassungen der Blackbox sind nicht möglich
• Neue Versionen der Blackbox können schnell zu Problemen führen, sowohl während des Kompilierens, wie auch zur Laufzeit
• Aufgrund fehlender Dokumentation sind selbst extrem gute Änderungen an der Blackbox ein Problem, da sie nicht ordentlich erfasst und vom Entwickler genutzt werden können. Im schlechtesten Fall sorgen API Änderungen sogar für Probleme bei bereits bestehenden Features

Softwareentwicklung darf nicht auf Annahmen und Hoffnung basieren, denn Coding-Into-The-Dark geht früher oder später schief. Man muss allerdings auch nicht jede Software Zeile für Zeile analysieren und verstehen. Es gilt das richtige Maß an Verständnis zu finden, welches ausreicht um die eigene Software zu entwickeln, zu bauen und zu betreiben. Kann man diese Punkte reproduzierbar und über einen längeren Zeitraum erfüllen, ist man auf einem guten Weg.
Sollte man allerdings immer wieder über Punkte stolpern, die durch fehlendes Verständnis - welches nicht ohne weiteres erarbeitet werden kann - entstehen, dann sollte man Abläufe und vielleicht auch seinen Software-Stack generell überdenken und anpassen. Hier gilt wie ich finde, lieber ein Ende mit Schrecken, als Schrecken ohne Ende. Denn wir alle wissen was grundlegende Änderungen am Software-Stack oder Tooling für Auswirkungen haben und welche Ressourcen teilweise benötigt werden, um derartiges umzusetzen. Doch nur was man versteht und nutzen kann, kann auch qualitativ gute Software hervorbringen.