Die Regeln der Programmierung

Die Geschichte der Regeln

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Die Programmierregeln wurden aus Verzweiflung geboren.

Ich hatte etwa ein Jahrzehnt lang Programmierteams bei Microsoft geleitet und war dann 1997 Mitbegründer der Videospielfirma Sucker Punch. Beide Unternehmen waren erfolgreich - zum großen Teil wegen ihrer Fähigkeit, erstklassige Programmierteams einzustellen und zu entwickeln. Bei Sucker Punch hat das zu einer 25-jährigen Reihe erfolgreicher Spiele geführt. Da waren die drei Sly Cooper-Spiele, die Kinder aller Altersgruppen in das aufregende Leben des Meisterdetektivs Sly Cooper und seiner Kumpels eintauchen ließen. Da waren die fünf inFamous-Spiele, die den Spielern Superkräfte verliehen und ihnen die Wahl ließen, sie für das Gute oder das Böse einzusetzen. Und dann ist da noch unser Meisterwerk Ghost of Tsushima, in dem du einen einsamen Samurai spielst, der sich gegen die Invasion Japans im Jahr 1274 wehrt.¹

Ein großer Teil der Rekrutierungsstrategie sowohl bei Microsoft als auch bei Sucker Punch besteht darin, clevere junge Programmierer/innen einzustellen und sie dann in die Arbeitsweise professioneller Entwickler/innen einzuweisen. Diese Praxis war unbestreitbar erfolgreich, aber sie führt auch zu einer besonderen Art von Frustration.

Ich bin immer wieder auf ein Problem gestoßen. Wir holten einen neuen Programmierer in unser Team, oft jemand, der gerade sein Studium abgeschlossen hatte. Ich überprüfte eine neue Funktion, die sie in den Code einbauen wollten, meist um ein sehr einfaches Problem zu lösen - nur um festzustellen, dass sie einen Code geschrieben hatten, der ein viel größeres Problem lösen sollte, das das sehr einfache und konkrete Problem als kleinen Unterfall enthielt.

Aargh! Wir brauchten dieses größere Problem nicht zu lösen, schon gar nicht jetzt! Die Lösung für das größere Problem war immer eine mittelmäßige Lösung für das einfache Problem, das wir hatten - komplizierter in der Anwendung, komplizierter im Verständnis und in der Lage, viel mehr Fehler zu verstecken. Aber bei der Codeüberprüfung wurde einfach gesagt, dass²-dass wir das größere Problem nicht lösen müssen, dass sie nur versuchen sollten, Probleme zu lösen, die sie verstehen, war wirkungslos. Sie taten es weiter.

Aus Frustration habe ich ein Machtwort gesprochen. "Okay", sagte ich. "Hier ist die neue Regel. Bevor du nicht drei Beispiele für ein Problem hast, darfst du keine allgemeine Lösung schreiben."

Zu meiner Überraschung und Freude hat das tatsächlich funktioniert! Die Umwandlung der allgemeinen Philosophie in eine konkrete Regel mit spezifischen Kriterien war ein effektiver Weg, um die Botschaft zu vermitteln. Sicher, die meisten unserer neuen Programmierer haben den Fehler der verfrühten Verallgemeinerung einmal gemacht, aber die Regel half ihnen, ihn nicht noch einmal zu machen. Sie half ihnen auch zu erkennen, wann es an der Zeit war, zu verallgemeinern. Weniger als drei Beispiele? Nicht verallgemeinern. Drei oder mehr? Beginne nach Möglichkeiten zu suchen.

Die Regel funktionierte, weil sie leicht zu erinnern war und die Situationen, in denen sie galt, leicht zu erkennen waren. Wenn die Programmierer merkten, dass sie die Grenzen des klar definierten Problems überschritten, konnten sie einen Schritt zurücktreten, die konkreten Beispiele für diese Art von Problemen zählen und dann besser entscheiden, ob sie verallgemeinern sollten oder nicht. Sie schrieben besseren Code.

Im Laufe der Zeit haben wir weitere wichtige Teile der Sucker Punch-Philosophie gefunden, die sich in leicht zu merkende Phrasen - genauer gesagt Aphorismen - fassen ließen. Es gibt eine lange Geschichte von Aphorismen - kurze, prägnante Aussagen, die eine wesentliche Wahrheit auf den Punkt bringen. Ich wette, du kannst ein paar davon aus dem Gedächtnis herunterrasseln. Ich könnte dich auf Aphorismen über Vögel beschränken, und dir würden immer noch mindestens zwei einfallen! Ich biete dir ein paar an:

• Zähle deine Hühner nicht, bevor sie geschlüpft sind.³

• Ein Spatz in der Hand ist besser als zwei im Busch.

• Der frühe Vogel fängt den Wurm.

• Setze nicht alles auf eine Karte.

Aphorismen bleiben in Erinnerung, weil sie funktionieren. Sie sind viral, im modernen Sinne - Aphorismen "infizieren" die Menschen schon seit Tausenden von Jahren mit Weisheiten.⁴ Daher ist es nicht verwunderlich, dass sie eine effektive Methode sind, um neue Teammitglieder mit der Sucker Punch Programmierphilosophie zu infizieren.

So wurde aus einer einzelnen Regel nach und nach eine Liste von Regeln: die Programmierregeln, die in diesem Buch beschrieben werden. Sie repräsentieren viele der wichtigsten Aspekte der Sucker Punch-Entwicklungskultur: die Dinge, von denen wir glauben, dass sie zu unserem Erfolg geführt haben, die Ideen, die neue Programmierer im Team verinnerlichen müssen, um effektiv zu sein. Die Dinge, an die selbst erfahrene Programmierer wie ich hin und wieder erinnert werden müssen!

Jedes der folgenden Kapitel beschreibt eine Regel mit vielen Beispielen, um den Gedanken dahinter zu veranschaulichen. Nach der Lektüre eines Kapitels solltest du eine klare Vorstellung von der Programmierpraxis haben, die die Regel fördert, und von den Situationen, in denen sie anwendbar ist.

Sind die Regeln in Buchform genauso ansteckend? Lass es uns herausfinden.

¹ Den Aufmerksamen unter euch ist vielleicht aufgefallen, dass ich Rocket ausgelassen habe: Robot on Wheels, das erste Spiel von Sucker Punch, ausgelassen habe. Das liegt daran, dass nur sehr wenige von euch es gespielt haben; wenn du zu den wenigen gehörst, bin ich dir sehr dankbar.

² Jeder Code, der an das Sucker Punch-Projekt übermittelt wird, wird einer Codeüberprüfung unterzogen. Siehe Regel 6 für weitere Details.

³ In seiner ursprünglichen Form, aus Thomas Howells New Sonnets and Pretty Pamphlets (1570): "Zähle nicht deine Hühner, die noch nicht geschlüpft sind ...." Ein kleiner Beweis für das Durchhaltevermögen eines guten Aphorismus.

⁴ Das Wort Aphorismus selbst wurde von Hippokrates um 400 v. Chr. geprägt. Nun, genau genommen war das Wort, das er prägte, Ἀφορισμός. Das war der Titel seines Buches mit Regeln für die medizinische Diagnose und Behandlung, von denen einige auch noch Jahrtausende später zutreffen, wie der Aphorismus 13 aus Kapitel 6: "Ein Niesanfall heilt einen Schluckauf." Wie wahr.