Programmieren will gelernt sein. Das dreckige Dutzend der Softwareentwicklung zeigt Ihnen, wie Coding nicht geht. [...]
Wenn man sich vor Augen hält, wie Developer ihre eigenen Fehler sehen, ist das der Beweis dafür, dass Softwareentwicklung Kunst ist. Denn ganz ähnlich wie die Meinungen zu Malern, Architekten, Schriftstellern und Dichtern divergieren, verhält es sich auch in der Welt der Softwareentwicklung: Developer sind sich regelmäßig lediglich darin einig, dass funktionierender Code die wesentliche Anforderung an ihre Arbeit darstellt. Und selbst diesbezüglich gibt es Abweichler, die mit existenziellen Programmierfehlern gut leben können – solange die Software Bugs den Usern verborgen bleiben.
Die Debatte um die korrekte Art und Weise der Softwareentwicklung fußt im Wesentlichen auf Erfahrungswerten. Wenn ein Entwickler eine bestimmte Verfahrensweise X verdammt, dann meistens deswegen, weil Jemand im Office X angewandt hat und das dann einen Abend, ein Wochenende oder gar einen Urlaub ruiniert hat. Dabei sah X zunächst nach einer guten Idee aus, dann offenbarten sich nur leider ein oder mehrere Denkfehler.
Betroffene möchten die Welt nun vor X warnen. Neue Probleme entstehen dann allerdings, wenn der gegenteiligen Verfahrensweise – Y – ihre ganz eigenen Fallstricke inhärent sind. Softwareentwickler, die auf Y ausweichen um X zu meiden und schließlich in einem ähnlichen Tal der Tränen wie die Kollegen landen, halten dann in der Regel auch nicht mehr viel von Y.
Gibt es Hoffnung, X und Y zusammenzubringen? Innerhalb eines Developer Teams ist das höchst unwahrscheinlich – was allerdings nicht heißt, dass Sie nicht aus den Fehlern von Gruppe X und Y lernen können. Wir zeigen Ihnen anhand des dreckigen Dutzends der Softwareentwicklung, wie Programmieren nicht geht – und starten damit zeitgleich die Beweisführung dafür, dass Coding tatsächlich eine Kunst darstellt. Eine Kunst, die ein reichhaltiges Skillset erfordert, um den goldenen Mittelweg zwischen problembehafteten Extremen zu finden.
1. Zu ASAP für die Coding Basics
Die Grundlagen der Softwareentwicklung außer Acht zu lassen, ist der schnellste und einfachste Weg, seine eigene Programmierarbeit zu sabotieren. Besonders oft wird dabei übersehen, wie sich willkürliches Nutzungsverhalten auf die Software auswirken kann: Fließt die Eingabe einer 0 in eine Teilungsoperation ein? Hat der eingegebene Text die richtige Länge? Wurde das Datumsformat eingehend geprüft? Wird der Username mit einer Datenbank abgeglichen? Jeder kleine Fehler in diesen Bereichen führt dazu, dass die Software zum Fail wird.
Es gibt einige Developer, die diese Fallstricke einfach mit einer „Error Catching“-Funktion kaschieren: Der Fehler wird in einem Log File gespeichert und gibt einen Fehlercode aus – um die Behebung darf sich dann ein anderer kümmern.
2. Der Teufel im Entwicklungsdetail
Auf der anderen Seite kann Software, die mit zu vielen Details überladen wird, zum Klotz am Bein werden. Die Überprüfung einiger Nullstellen wird nicht viel Unterschied machen – problematisch wird es allerdings, wenn die Applikation zu in Code gegossener Paranoia transformiert und alle möglichen „Türen“ immer und wieder überprüft.
Wenn solche zwanghaften Kontrollarien dann auch noch die Netzwerk-Kommunikation mit einer Webseite nötig machen, kann die Software komplett zum Erliegen kommen. Ein Beispiel, das wohl jeder User kennt: Manche Applikationen verlangsamen sich um ein Vielfaches, wenn keine WLAN-Verbindung vorhanden ist, weil sie permanent nach einem Hotspot suchen, der einfach nicht vorhanden ist.
Die Herausforderung für Softwareentwickler besteht darin, die Code Layer so zu gestalten, dass Input-Daten bei der ersten Eingabe überprüft werden. Das ist allerdings wesentlicher leichter geschrieben als getan. Wenn viele Developer an einer Bibliothek arbeiten oder gar nur ein Einzelner für das Programmieren zuständig ist, wird es ziemlich schwierig sich zu erinnern, ob und wann der Pointer geprüft wurde.
3. Softwareentwicklung außer Kontrolle
Allzu oft sorgen Softwareentwickler durch ihr eigenes Handeln dafür, dass das Programmieren im Desaster endet – nämlich indem sie keine Kontrolle über ihren Code haben.
Mike Subelsky ist Mitbegründer von OtherInBox.com und ein Verfechter von „Code-Ordnung“. Soll heißen: Es sollte nur eine Stelle innerhalb des Programmcodes geben, wo jeder einzelne Task abgelegt wird. Gibt es mehrere, stehen die Chancen gut, dass irgendjemand an einer Stelle eine Veränderung durchführt ohne dabei an die andere(n) zu denken: „Nachdem ich über drei Jahre mit einer Code-Basis gearbeitet habe“, plaudert Subelsky aus dem Nähkästchen, „bereue ich am meisten, dass ich den Code nicht modular aufgebaut habe. Deswegen musste ich auf die harte Tour lernen, wie wichtig die Einhaltung des Single-Responsibility-Prinzips ist.“
Wie Sie sich vielleicht schon erschlossen haben, ist Subelsky ein Ruby-on-Rails-Programmierer. Dieses Framework begünstigt die Erstellung eines möglichst schlanken Programmcodes, weil davon ausgegangen wird, dass sich das Gros der Software-Struktur in bekannte Muster einordnen lässt. Diese Philosophie fassen Ruby on Rails Developer häufig zusammen als „Convention over Configuration„.
Ein Beispiel, um das Prinzip zu verdeutlichen: Die Software nimmt an, dass ein erstelltes Objekt vom Typ X mit zwei Feldern „A“ und „B“ in einer Datenbank automatisch als Tabelle X mit zwei Spalten „A“ und „B“ angelegt wird. Die Benennung wird an einem Ort festgehalten, so dass keine Probleme auftreten, wenn ein Einzelner daran scheitert alle Konfigurations-Layer synchron zu halten.
4. „Das Entwicklungs-Framework regelt das“
Manchmal führen Tools, deren per Marketing kolportierte Fähigkeiten bereits an Magie grenzen, aber auch zu allgemeiner Verwirrung. Durch die Abstraktion von Funktionalitäten und die Annahme, bereits vorher zu wissen, was Entwickler wollen, können Frameworks dazu führen, dass Developer ratlos im Regen stehen, wenn es darum geht, zu ermitteln, wo genau der Fehler in ihrem Programmcode liegt.
G. Blake Meike ist freier Softwareentwickler und nur einer von Vielen, die eine Abhängigkeit von Automatisierungs-Tools wie Ruby on Rails eher als Hindernis empfinden, wenn es darum geht, sauber zu programmieren: „Konvention ist etwas, das schon per definitionem nichts mit Code zu tun hat. Wenn Sie beispielsweise bei Ruby on Rails die Regeln nicht genau kennen, bleibt Ihnen die genaue Funktionsweise des Frameworks weitgehend verschlossen. Daraus können immer neue Probleme entstehen.“
Der Einsatz von Entwicklungs-Frameworks sorgt zwar für „schönen“ Code – der ist allerdings oft schwer zu verstehen, zu bearbeiten oder zu erweitern. Oder – wie es Softwareentwickler Mike Morton ausdrückt: „Frameworks hieven Sie bis zu 90 Prozent in einem bequemen Sessel in Richtung Gipfel. Das war es dann aber auch. Um die letzten zehn Prozent des Aufstiegs bezwingen zu können, müssen sie vorausgedacht und sowohl Sauerstoff als auch Steighaken mitgebracht haben.“
5. Vertraue keiner Maschine!
Wenn Softwareentwickler einfach davon ausgehen, dass ihre Endgeräte schon das Richtige „tun“ werden, kann das zu schwerwiegenden Security-Schwachstellen führen. Programmcode, der beispielsweise für einen Browser konzipiert wurde, kann von diesem so umgeschrieben werden, dass jegliche Art von Willkürlichkeiten möglich werden. Wenn der Softwareentwickler nicht alle eingehenden Daten einem Check unterzieht, kann einiges schiefgehen.
Deswegen basieren einige der gängigsten Angriffsmuster krimineller Hacker auf der Annahme, dass nicht wenige Developer Daten ungeprüft in die Datenbanken übernehmen. Das geht solange gut, bis ein Angreifer mit einem simplen Befehl die komplette Datenbank löscht. Und das ist bei weitem nicht der einzige Weg, Server zu überlisten: Online-Umfragen stellen quasi eine Einladung zur Bias-Erzeugung dar und Buffer-Overflow-Attacken sind immer noch der einfachste Weg, um Software nachhaltig zu beschädigen.
Wenn drei oder vier – vermeintlich vernachlässigbare – Sicherheitslücken „in Reihe geschaltet“ werden, können erhebliche Security-Risiken entstehen. Ein Softwareentwickler könnte beispielsweise ein File erstellen in der Annahme, dass die Verzeichnisberechtigungen ausreichen, um Fehler zu verhindern. Ein anderer Developer öffnet inzwischen die Berechtigungen, um einen Bug zu entfernen. Für sich allein stellen beide Vorgänge nicht unbedingt ein Risiko dar – kommen sie zusammen, kann es zu unvorhergesehenen Eigenwilligkeiten des Clients kommen.
6. Kein Vertrauen ist auch keine Option
Paradoxerweise kann auch zu viel Security zu Sicherheitslücken führen. Nämlich dann, wenn das Übermaß an Sicherheitsmaßnahmen zum Sand im Getriebe wird und Softwareentwickler so dazu verführt, die Security-Zügel locker zu lassen – nur damit die Prozesse wie gewohnt weiterlaufen können.
Auch Web Forms sind so ein Ding: Nicht nur dass Security-Maßnahmen, die dem Bankensektor Konkurrenz machen, ellenlange Fragebögen und der Zwang, Kontaktdaten abzugeben enorm abschreckend auf User wirken. Die hierbei gesammelten persönlichen Daten vorzuhalten und abzusichern kann weit mehr Probleme aufwerfen, als die ganze Sache wert ist. Deswegen streben viele Web-Entwickler danach, das Security-Niveau so weit wie möglich abzusenken. Einerseits, um den Usern den Zugang zum Produkt zu erleichtern. Andererseits, um nicht mehr persönliche Daten als nötig speichern und schützen zu müssen.
7. Der Softwareentwickler und die Zauberbox
„Verschlüsselung? Backup? Mehr Security? Drücken Sie einfach den Button – es funktioniert dann ganz von allein“, sagte der Verkäufer, als er eine Wunderlösung anpries, deren Algorithmen im Stande sein sollen, alle Unzulänglichkeiten im Programmcode zu eliminieren. Das Problem bei solchen „magic boxes“: damit können auch komplexe Problemstellungen unter den Tisch fallen – beziehungsweise unabsichtlich übersehen werden – oder schlimmer noch: neue Schwachstellen Einzug halten.
Insbesondere der Aspekt der Datenverschlüsselung kann hierbei problematisch werden: Zu viele Softwareentwickler sind der Überzeugung, sie müssten einfach nur auf die „encryption library“ verlinken, einen Knopf drücken und schon steht das IT-Sicherheits-Bollwerk. Bei genauerem Hinsehen weisen allerdings viele der magischen Algorithmen subtile Schwächen auf, deren Identifikation mehr Hingabe als nur das Lesen des Quick Start Guide erfordert.
8. Developer, die das Rad neu erfinden
Andererseits kann es aber auch eine sehr ungünstige Idee sein, eigene „encryption libraries“ aufzusetzen, wenn das unter der Annahme geschieht: „Ich weiß schließlich am besten, wie man optimal programmiert“. Für kriminelle Hacker kommen solche Vorgänge einem grell erleuchteten Willkommensschild gleich. Schließlich machen auch gewiefte Verschlüsselungs-Experten Fehler, wenn es darum geht, Eindringlinge von ihren Systemen fernzuhalten.
Wem vertrauen Sie also? Sich selbst oder den sogenannten Experten, die ebenfalls Fehler machen? Die Antwort findet sich im Reich des Risikomanagements: Viele Bibliotheken müssen gar nicht perfekt sein – im Regelfall ist der Einsatz einer „magic box“ (siehe vorhergehender Absatz) selbst erstelltem Code vorzuziehen, denn diese Bibliotheken sind im Regelfall von mehreren Experten erstellt – und optimiert – worden.
9. Der Closed-Source-Fehler
Eine der wesentlichen Herausforderungen für Unternehmen ist es, zu ermitteln, wie viele Informationen es mit den Usern, die seine Software nutzen, teilen will.
John Gilmore, Mitbegründer von Cygnus Solutions (eines der ersten Open-Source-Softwareunternehmen) hat dazu eine klare Meinung: „Programmcode nicht zu veröffentlichen steht im Gegensatz zu dessen Integrität, verhindert Innovation und insbesondere die Identifikation von Bugs. Einer der wesentlichen Vorteile von offenem Code ist, dass Menschen, von denen Sie noch nie vorher gehört haben, an dessen Optimierung mitwirken. Selbst wenn das eher amateurhaft abläuft, können ein paar Minuten Reflexion von Seiten eines Developers dafür sorgen, dass entscheidende Verbesserungen in die Software einfließen.“
Des Öfteren tut es dem Programmcode auch gut, wenn unbefangene Dritte sich damit beschäftigen, ihn erweitern oder auf andere Plattformen portieren. Schon wenn Sie quelloffenen Code zur Verfügung stellen, muss dieser zugänglich, verständlich und damit besser aufgebaut sein.
10. Quelloffenheit als Allheilmittel
Quelloffener Code ermöglicht Dritten, Verbesserungen einzubringen. Das wird allerdings nicht geschehen, nur weil Ihre Software Open Source ist. Vielmehr braucht es einen Anreiz, damit Andere sich diese Arbeit machen. Quelloffenheit allein jedenfalls verhindert weder Sicherheitslücken noch Abstürze – und macht einen Haufen unfertigen Programmcodes auch nicht zwingend nützlich.
Quelloffenheit kann auch für neue Erfordernisse in Sachen Kommunikation und Dokumentation führen. Die Dokumentation für die User ist das eine – im Fall von Open Source Software wird allerdings auch eine Dokumentation der APIs sowie eine Roadmap für die künftige Entwicklung nötig. Geht es dabei um größere Softwareprojekte, rechnet sich das im Regelfall. Bei kleineren nicht unbedingt.
Viele Unternehmen im Open-Source-Bereich behalten die Kontrolle über ein oder mehrere proprietäre Features ihrer Software, um die Finanzierung des Kern-Entwicklungsteams sicherzustellen. Bei Projekten, die sich in weiten Teilen auf freiwillige Helfer verlassen, sollte deren Unberechenbarkeit einkalkuliert werden.
11. Trendgetriebene Softwareentwicklung
Oft nehmen Trends ihren Ursprung in einer guten Idee, die ein nerviges Problem lösen soll. Die Software in einer neuen Programmiersprache, mit einem neuen Framework oder neuen Bibliotheken zu überarbeiten, kann Früchte tragen. Allerdings kann ein solcher Paradigmenwechsel auch nach hinten losgehen. Insbesondere, wenn es um substanzielle Änderungen am Programmcode geht.
Schließlich bieten viele der brandneuen Frameworks oft nur die wichtigsten Features – alles andere muss erst noch programmiert werden. Natürlich sparen sich die Softwareentwickler viel Zeit bei den fertigen Funktionalitäten – allerdings geht die oft wieder dafür drauf, die Lücken entsprechend zu füllen. Wer „cutting edge“ sein will, muss also in jedem Fall leiden.
12. Programmieren wie früher
Nicht wenige Developer betrachten neue Coding-Trends und -Ideen mit Argwohn. In einigen Fällen nicht zu Unrecht – in anderen schon. Ist Letzteres der Fall, stehen diese Entwickler vor einem Haufen Code, der hoffnungslos veraltet ist.
Natürlich kann auch veralteter Programmcode problemlos laufen – auch mit Erfolg. Wenn aber der Zeitpunkt gekommen ist, an dem schwerwiegende Probleme auftauchen, sind diese nicht mehr so einfach zu beheben. Das können beispielsweise APIs sein, die nicht mehr existent sind und für die auch keine Weiterleitung besteht. Oder ein Partner, der keine XML-Dateien mehr akzeptiert, was dazu führt, dass YAML- oder GraphQL-Dateien per Crashkurs erzeugt werden müssen.
Fazit: Zahlen Sie jetzt – oder später. Dann aber wesentlich mehr.
Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.
*Peter Wayner schreibt unter anderem für unsere US-Schwesterpublikation InfoWorld.com und ist Autor verschiedener Bücher – unter anderem zu den Themen Open Source Software, autonomes Fahren und digitale Transaktionen.
**Florian Maier beschäftigt sich mit vielen Themen rund um Technologie und Management. Daneben betätigt er sich auch in sozialen Netzen.
Be the first to comment