„Star Fluxx“ ist eine Science Fiction-Variante von „Fluxx“, einem Kartenspiel, bei dem die Regeln für das Kartenspiel sowie die Bedingungen für das Gewinnen durch die von den Spieler:innen gespielten Karten ständig verändert werden. Als ich die Beschreibung des Spiels in der oben erwähnten Folge von TableTop hörte, erinnerte mich das an Softwareentwicklungsprojekte. Das Ändern von Geschäftsregeln und Anforderungen kommt Ihnen wahrscheinlich auch bekannt vor.
Wenn du ständig neue Funktionen entwickelst und häufig neuen Code in Produktion bringst, darf die Qualität nicht auf der Strecke bleiben. Heutzutage dreht sich beim agilen Stil der Softwareentwicklung alles um kurze und iterative Sprints, aber infolgedessen können wir uns nicht mehr erst am Ende um die Qualität kümmern. Sie muss während des gesamten Softwareentwicklungsprozesses berücksichtigt werden. Zur Qualität gehört unter anderem, dass sichergestellt wird, dass der Code korrekt funktioniert und gleichzeitig gewährleistet ist, dass er problemlos geändert werden kann, wenn sich die Geschäftsregel, die er implementiert, ändert.
Stell dir einen Moment lang vor, du hättest die Aufgabe, „Star Fluxx“ zu implementieren. Was läge näher, als jede der Karten des Spiels in einer eigenen Klasse zu implementieren (die natürlich alle die gleiche Schnittstelle haben)? Die Spielregeln, die in der realen Welt durch spezielle Karten verkörpert werden, sind dann nichts weiter als Objekte. Wenn das Spiel beginnt, erzeugen wir einfach ein Objekt der Klasse, das die Grundregel „eine Karte ziehen, eine Karte spielen“ implementiert. Zu Beginn jeder Runde fragt die Hauptschleife des Spiels nun einfach das aktuelle Regelobjekt, wie viele Karten die aktuelle Spieler:in zu ziehen und wie viele Karten sie zu spielen hat. Sollte eine Spieler:in eine regeländernde Karte ausspielen, zum Beispiel die Karte „zwei Karten ziehen, zwei Karten spielen“, können wir einfach das aktuelle Regelobjekt durch das neue ersetzen.
Stell dir nun vor, wie schwer dies ohne die Vorteile der objektorientierten Programmierung zu implementieren wäre. Wenn die Spielregeln hart kodiert wären – zum Beispiel in der Hauptschleife –, müsste möglicherweise bestehender Code geändert werden, wenn neue Regeln zum Spiel hinzugefügt werden, weil die Regeln nicht in einer isolierten Codeeinheit gekapselt sind.
Eine Klasse ist einfach zu testen, wenn sie eine klare Verantwortung hat (beispielsweise die Implementierung einer Geschäftsregel) und wenn ihre Abhängigkeiten explizit und minimal sind. Abhängigkeiten sind explizit, wenn sie mittels Dependency Injection in ein Objekt hineingeschoben werden und nicht durch das Erstellen neuer Instanzen von Klassen, von denen das Objekt abhängt, in das Objekt hineingezogen werden. Andere Formen von impliziten Abhängigkeiten sind die Interaktion mit dem globalen Zustand und die Verwendung von statischen Methoden. Eine Klasse, die diesen Entwurfsprinzipien folgt, ist lose gekoppelt und hochgradig kohäsiv. Diese Eigenschaften sind nicht nur für die Testbarkeit wichtig, sondern erleichtern auch die Anpassung der Klasse, wenn sich die Anforderungen ändern.
Es gibt jedoch ein Problem mit „Fluxx“ als Analogie für die Softwareentwicklung: „Fluxx“ ist ein kompetitives Spiel, bei dem die Spieler:innen gegeneinander antreten. Die Analogie wäre perfekt, wenn „Fluxx“ stattdessen ein kooperatives Spiel wäre, bei dem alle zusammenarbeiten, um ein gemeinsames Ziel zu erreichen. „Elder Sign“ und „Pandemic“, die in anderen Episoden von TableTop behandelt wurden, sind Beispiele solcher Brettspiele.
Software-Entwicklung im Allgemeinen und Qualitätssicherung im Besonderen müssen kooperative Anstrengungen sein, um erfolgreich zu sein. Ich denke, das ist es, was James Whittaker meint, wenn er schreibt:
Der einzige Weg, wie ein Team Qualitätssoftware schreiben kann, ist, wenn das gesamte Team für die Qualität verantwortlich ist. Das bedeutet Produktmanager, Entwickler, Tester ... jeder.