„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 Spielern 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 Sie ständig neue Funktionen entwickeln und häufig neuen Code in die Produktion einbringen, 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 kann man sich 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.
Stellen Sie sich einen Moment lang vor, Sie hätten 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 der aktuelle Spieler zu ziehen und wie viele Karten er zu spielen hat. Sollte ein Spieler 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.
Stellen Sie sich 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 Spieler gegeneinander antreten. Die Analogie wäre perfekt, wenn „Fluxx“ stattdessen ein kooperatives Spiel wäre, bei dem alle Spieler 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.