Weniger schlecht programmieren

Kathrin Passig, Johannes Jander

• Publisher: O'Reilly
• Year: 2013
• ISBN:
  9783955615680
• Edition: 1
• Topic: Ciencia de la computación
• Subtopic: Programación

Kathrin Passig gilt als Meisterin des unorthodoxen Blickwinkels, und wenn sie sich zusammen tut mit einem gestandenen Entwickler, um ein Programmierbuch zu schreiben, darf man gespannt sein. Mit Sachverstand und Witz widmen sich die beiden den Holzwegen, Fehleinschätzungen und Irrtümern, die insbesondere Programmier-Neulingen und Hobby-Entwicklern das Leben schwer machen. Ein Buch für alle, die ahnen, dass ein besserer Programmierer in ihnen steckt. Hätte ich das früher gewusst! Auch wenn es nicht unbedingt auf der Hand liegt: Programmieren hat viel mit Kommunikation zu tun. Programmierstil, Namensgebung, Umgang mit Kommentaren oder mit Fremdcode - oftmals haben sich gerade dort Konventionen etabliert, wo eine Sprache keine strengen Vorgaben macht. Lernen Sie die unterschiedlichen Traditionen der verschiedenen Sprachen kennen und erfahren Sie, wie Sie sich auf diesem unsicheren Terrain halbwegs unfallfrei bewegen. Vom Umgang mit Fehlern - Wer hat nicht schon Stunden damit verbracht, nach einem Fehler im Programm zu suchen, um herauszufinden, warum etwas nicht so funktioniert, wie eigentlich geplant? Es gibt eine Menge Anzeichen, die darauf schließen lassen, wo genau etwas im Code nicht stimmt. Lernen Sie, wie Sie solche Roststellen erkennen, wie Sie mit systematischem Debugging Fehler finden und durch Tests dauerhaft bändigen. Die Qual der Wahl - Nicht jede Programmiersprache eignet sich gleich gut für jede Aufgabe, Daten lassen sich auf unterschiedliche Weise vorhalten, Entwicklungsumgebungen und Versionskontrollsysteme gibt es viele - auf technischer Ebene gilt es jede Menge Entscheidungen zu treffen, deren Konsequenzen schwer zu überreißen sind. Universell gültige Empfehlungen kann niemand abgeben, aber mit den Erfahrungswerten und Entscheidungshilfen der Autoren fahren Sie für den Anfang nicht schlecht.

Teil IV. Wahl der Mittel

• Kapitel 19
• Kapitel 20
• Kapitel 21
• Kapitel 22
• Kapitel 23
• Kapitel 24
• Kapitel 25
• Kapitel 26
• Kapitel 27

Kapitel 19. Mach es nicht selbst

»In Polen lebte einmal ein armer Jude, der hatte kein Geld, zu studieren, aber die Mathematik brannte ihm im Gehirn. Er las, was er bekommen konnte, die paar spärlichen Bücher, und er studierte und dachte, dachte für sich weiter. Und erfand eines Tages etwas, er entdeckte es, ein ganz neues System, und er fühlte: ich habe etwas gefunden. Und als er seine kleine Stadt verließ und in die Welt hinauskam, da sah er neue Bücher, und das, was er für sich entdeckt hatte, das gab es bereits: es war die Differentialrechnung. Und da starb er. Die Leute sagen: an der Schwindsucht. Aber er ist nicht an der Schwindsucht gestorben.«

—Kurt Tucholsky, »Es gibt keinen Neuschnee«

Unerfahrene Programmierer bringen viel Zeit damit zu, Funktionen neu zu erfinden, die es in ihrer Sprache oder deren Standardbibliotheken bereits gibt. Natürlich ist es kaum möglich, von Anfang an einen Überblick über alle Funktionen zu haben, die die Programmiersprache mitbringt. Niemand liest sich als Erstes die alphabetische Auflistung sämtlicher Befehle einer Sprache.^[56] Wie können Sie trotzdem ohne großen Aufwand feststellen, wo sich eigene Nachdenk- und Programmierarbeit lohnt und wo Sie nur das Rad neu erfinden (in Form von aneinandergenagelten Dreiecken)?

»Unvollständige Liste der PHP-Befehle, die ich aus Unwissenheit selbst nachgebaut habe: array_rand, disk_free_space, file_get_contents, file_put_contents, filter_var, htmlspecialchars, import_request_variables, localeconv, number_format, parse_url, strip_tags, wordwrap.«

—Kathrin

Es sind nicht nur Unerfahrenheit und Unwissenheit, die nicht so gute Programmierer von der Verwendung bestehender Lösungen abhalten. Selbst wenn eine Aufgabe im Programmierer den vagen Verdacht erweckt, dieses Problem könnte eventuell schon einmal ein anderer Mensch gehabt und gelöst haben, folgt daraus nicht unbedingt der naheliegende Schritt, nach der Lösung zu suchen. Viele Menschen empfinden Programmieren als die angenehmere und spannendere Tätigkeit und verbringen folglich ihre Zeit lieber mit dem Schreiben von Code als mit der Suche nach bereits geschriebenem. Auch überschätzt man gern die eigenen Fähigkeiten und unterschätzt die Komplexität des Problems. Gerade Aufgaben, die überschaubar wirken, bringen dabei Probleme mit sich, weil auch unerfahrene Programmierer bei ihrer Betrachtung sofort einen Lösungsweg erkennen oder zu erkennen glauben.

Aufmerksame Leser werden in diesen Problemen die Kehrseite von Larry Walls wichtigen Programmierertugenden Faulheit, Ungeduld und Selbstüberschätzung (siehe Kapitel 2) wiedererkennen. Zum Vorteil gereichen diese Eigenschaften Programmierern nämlich nur dann, wenn sie bei den passenden Anlässen zum Einsatz kommen. Wer alle seine Tools ohne vorherige Recherche selber schreibt, dem fehlt schlicht die Zeit, mithilfe seiner Untugenden eines Tages etwas wirklich Nützliches und bisher nicht Dagewesenes hervorzubringen. Denn eine erste funktionierende Version der eigenen Datumsfunktionen, der eigenen Blogsoftware oder des eigenen Zeiterfassungstools ist zwar schnell geschrieben, aber die im weiteren Verlauf überraschend auftauchenden Sonderfälle, Bugs, Erweiterungswünsche und – wenn andere Menschen den Code nutzen – Supportanfragen können eine erstaunliche Menge Lebenszeit verschlingen. Ein erfahrener Softwareentwickler produziert einer gängigen Faustregel zufolge inklusive Nachdenken, Testen, Debugging, Optimierung und Dokumentation ungefähr zehn ausgereifte Zeilen pro Tag. (Bei Buchautoren ist es ähnlich.) Als unerfahrener Entwickler schaffen Sie sicher nicht mehr.

Es gibt für viele immer wiederkehrende Problemfälle inzwischen Standardlösungen, die von mehreren Generationen von Programmierern verfeinert wurden, zum Beispiel Sortieralgorithmen. Dass man an einem Problem arbeitet, das ein spezielles, bisher noch nicht existierendes Sortierverfahren benötigt, ist selbst für mittelgute Programmierer unwahrscheinlich. Nur weil die vom Framework gelieferte Standardlösung nicht absolut passgenau ist, sollte man sich nicht dazu verleiten lassen, etwas Eigenes zu schnitzen, denn man verbringt damit viel Zeit, baut vermutlich Fehler ein und arbeitet gegen das Framework – das heißt, man hat zwar danach einen schönen Sortieralgorithmus für sich, aber die Schwierigkeiten mit der Passgenauigkeit werden an anderer Stelle wieder auftauchen.

Für den Einsatz fertiger Lösungen spricht auch, dass man mit selbstgeschnitzten Werkzeugen zukünftigen Nutzern und Lesern des Codes keine Freude macht. Vielleicht möchten diese hilfsbereiten Leser die Performance der Anwendung verbessern oder nach Fehlern suchen. Wenn dort statt Aufrufen von vertrauten Standardfunktionen eine eigene Lösung auftaucht, erregt der unbekannte Code zu Recht Misstrauen. Die Leser müssen sich nun beispielsweise mit den Details einer Spezial-Sortierfunktion auseinandersetzen, um sich davon zu überzeugen, dass sie fehlerfrei ist und das Problem effizient löst. Hätte der Programmierer hingegen eine Standardfunktion verwendet, könnte sich ein erfahrener Leser diesen Aufwand sparen, denn auf die Implementierung der Standardfunktion haben so viele Augenpaare gesehen, dass sie mit einiger Sicherheit nicht nur viel weniger Fehler enthält, sondern auch effizient ist.

Der Weg zur Lösung

Wenn man feststellt, dass man immer wieder ähnlichen Code für eine relativ überschaubare Aufgabe selbst schreibt, ist das ein Anzeichen dafür, dass wahrscheinlich bereits eine fertige, wenige Zeichen lange Lösung existiert. Es gibt diverse Möglichkeiten, diese Lösung aufzuspüren:

• Man liest in der Dokumentation der Sprache einen verwandten Bereich durch und hofft auf Querverweise zur gesuchten Funktion.
• Man betrachtet eine Liste aller Funktionen oder der Funktionen eines bestimmten Themenfeldes und hofft darauf, dass das gesuchte Ding einen sprechenden Namen trägt: array_rand aus dem oben genannten Beispiel etwa hätte sich in der PHP-Dokumentation unter php.net leicht durch Betrachten des Abschnitts »Array Functions« finden lassen.
• Man konsultiert ein Buch, das Standardlösungen auflistet. Die englischen »Cookbooks« bzw. deutschen »Kochbücher« von O’Reilly eignen sich dafür, denn sie sammeln typische Fragestellungen aus der Programmierpraxis und beantworten sie rezeptartig.
• Man wirft das Problem einer Suchmaschine vor und hofft, zum Beispiel bei stack-overflow.com dazu eine Frage zu finden, bei deren Beantwortung sich mehrere Autoren gegenseitig mit immer eleganteren Lösungen übertreffen. Auf array_rand wäre man zum Beispiel durch eine Suche nach »how to« »random element« array php gestoßen.
• Man sucht zum Beispiel auf github.com oder sourceforge.net in den Beschreibungen von Open Source-Projekten nach einem Projekt in der jeweiligen Sprache, das dieses Problem mit großer Wahrscheinlichkeit auch zu lösen hatte. Dann sieht man nach, wie dessen Autoren die Sache angegangen sind.
• Wenn man etwas mehr Erfahrung gesammelt hat, weiß man auch in einer neuen Sprache, mit welchen Grundfunktionen zu rechnen ist, und braucht dann nur noch deren Namen und die technischen Details herauszufinden. Man muss der Suchmaschine keine mühsame Beschreibung vorlegen wie in unserem Beispiel mit »how to« »random element« array php. Stattdessen kann man einfach nach array_rand in python suchen, um das Python-Äquivalent zum schon bekannten PHP-Befehl zu finden.

Erst wenn wirklich nirgendwo wiederverwendbarer Code zu entdecken ist, lohnt es sich,...