Aufbau eines kollaborativeren, effektiveren Engineering-Teams mit TDD und Pairing

Ich habe kürzlich mit einem Softwaretester gesprochen und konnte nicht anders, als ihn nach seiner Meinung zu fragen Testgetriebene Entwicklung (TDD), da dies hier bei Qumulo für unsere Ingenieurteams vorgeschrieben ist.

Um seine Gefühle zu paraphrasieren, sagte er:

Ich denke, Unit-Tests sind wichtig, aber Entwickler denken nicht oft aus der Perspektive eines Benutzers, wenn sie ihre Tests schreiben. Stattdessen denken sie über die Implementierung nach und darüber, wie sie funktionieren soll, was nicht oft so funktioniert.

Seine Vorliebe als Tester ist mir nicht entgangen, aber ich stimme zu, dass jemand, dessen Aufgabe ausschließlich darin besteht, funktionale Tests zu schreiben, eine dringend benötigte Denkweise in den Veröffentlichungszyklus einbringen kann. Ich denke auch, dass es für Feature-Entwickler wichtig ist, diese Breaker-Denkweise zu teilen, denn Software-Ingenieure sind in erster Linie Designer und in zweiter Linie Programmierer. Wir müssen über Anwendungsfälle nachdenken, wie Dinge schief gehen können und wie wir den Schaden mindern können, wenn Dinge unvermeidlich schief gehen.

Bei Qumulo entwickeln wir kontinuierlich einen Einarbeitungs- und Wachstumsprozess für unsere Ingenieure, der diese Fähigkeiten stärkt, einschließlich der Verwendung von TDD, um diesen Wachstumsprozess zu erleichtern.

Ein Ingenieur ist eigentlich nur ein Wissenschaftler, der versucht, Probleme für Kunden zu lösen. Meiner Erfahrung nach besteht der wertvollste Beitrag von TDD darin, wie es die wissenschaftliche Methode für Ingenieure erleichtert, die sie praktizieren. Wenn Sie einen Einheitentest schreiben, stellen Sie die Hypothese auf, dass, wenn und nur wenn, Wenn Sie den Produktionscode ändern, erfüllen Sie die Eigenschaften, die von Ihrem neuesten Test behauptet werden. Dies sind eigentlich zwei Hypothesen, die zusammengesetzt sind:

• Der vorhandene Produktionscode wird die von Ihrem neuen Test behaupteten Eigenschaften nicht erfüllen.
• Der geänderte Produktionscode erfüllt die Eigenschaften, die von Ihrem neuen Test behauptet werden.

Ohne TDD betreiben Sie schlechte Wissenschaft, indem Sie vergessen, Ihr Experiment an einer Kontrollpopulation durchzuführen. Es kann vorkommen, dass Ihr Test ohne Änderung des Produktionscodes bestanden worden wäre, und dies bedeutet, dass Ihr Test entweder einen Fehler aufweist oder keine neuen Eigenschaften des Produktionscodes mitteilt.

Die Codebasis von Qumulo ist wie ein Labornotizbuch; Wir haben mehr als 55,000 Tests, die alle Experimente dokumentieren, die mit dem Produktionscode durchgeführt wurden. Er vermittelt, was wir über den Code wissen, und jeder Test ist nur so wertvoll wie das, was er dem Leser mitteilt. Es kann sein, dass sich unser Verständnis der Kundenbedürfnisse geändert hat, und als solches sollte sich auch der Kodex und unser Wissen darüber ändern. Es liegt an den Ingenieuren zu entscheiden, ob ein Test wertvoll ist, und wenn nicht, wird er gelöscht.

Durch die Erleichterung der wissenschaftlichen Methode ermöglicht TDD den Ingenieuren, sich auf ein beunruhigenderes Problem zu konzentrieren: Welche Tests übersehen wir? Dies ist die zentrale Herausforderung des Designprozesses, denn Ingenieure müssen sich in die Köpfe ihrer Kunden hineinversetzen. Es zwingt sie zum Nachdenken Wer sind unsere Kunden? Wie werden sie unseren Kodex anwenden? (Beachten Sie, dass „Kunden“ auch andere Ingenieure umfassen können, die Ihren Code verwenden.)

Und der Designprozess ist immer kollaborativ, weil es gefährlich ist, alleine zu gehen!

„Was ein Programmierer in einem Monat schaffen kann, schaffen zwei Programmierer in zwei Monaten.“ – Fred Brooks

Ich reiße Freds Worte hier aus dem Zusammenhang, aber wenn „was ein Programmierer tun kann“ darin besteht, Bugs zu schreiben, dann bekommt Freds Aussage eine neue Bedeutung: Zwei Programmierer werden in zwei Monaten so viele Bugs schreiben wie ein Programmierer in einem Monat! Aber im Ernst, wenn Sie TDD praktizieren, ist jeder Fehler, den Sie schreiben, eigentlich ein Test, den Sie nicht geschrieben haben, und zwei Ingenieure beim Paarprogrammieren werden an mehr Testfälle denken als ein Ingenieur. Es neigt auch dazu, saubereren Code mit besseren Variablen- und Funktionsnamen zu erzeugen. Im Allgemeinen ist die Disziplin stärker, wenn jede Person die andere zur Rechenschaft zieht.

Also empfehlen wir das Ingenieure koppeln standardmäßig, und das hört nicht beim Codieren auf. Bei Qumulo schreiben wir User Stories, schreiben Aufgaben und lösen Probleme auf einem Whiteboard zu zweit. Pairing reduziert nicht nur die Fehlerrate, es verbreitet Informationen über die Problemdomänen und (als Bonus) macht es Spaß.

Es macht Spaß, wenn man es richtig macht. Wie bringen wir unseren Ingenieuren also bei, effektiv zu testen und zu koppeln?

Wir haben unserem Onboarding-Prozess kürzlich eine Veranstaltung namens TDD and Pairing Workshop hinzugefügt. Wir halten Präsentationen zu TDD und Pairing, diskutieren die Vorteile und Fallstricke und üben alles, was wir durch Pairing gelernt haben, an einer Kata (ein kleines Übungsproblem, das häufig wiederholt werden soll). Wir verwenden die Stile Ping-Pong, Driver/Navigator und Mobbing, um striktes TDD zu üben und eine Bibliothek zum Konvertieren von römischen Zahlen in Dezimalzahlen und umgekehrt zu implementieren.

Die Teilnehmer machen oft die gleichen Beschwerden über Paarung und TDD:

• Ich fühle mich beim Programmieren unwohl, wenn jemand zusieht; es macht es schwer, klar zu denken.
• Ich stecke oft in einer Meinungsverschiedenheit mit meinem Partner fest und verschwende Zeit.
• Ich fühlte mich wie eine Schreibmaschine, die dem Navigator ausgeliefert war; Ich kam mit dem Problem, das wir lösten, nicht hinterher.
• Ich habe das Gefühl, dass mein Partner abgelenkt wird, während ich die ganze Arbeit mache.
• TDD ist ineffizient; Am Ende schreibe ich uneleganten Code und behebe ihn später.

Wir haben diese Aspekte von geübt extremes Programmieren (XP) seit Jahren bei Qumulo, daher haben wir uns mit diesen Problemen befasst und bieten neuen Mitarbeitern die folgenden Lektionen an:

• Setzen Sie klare, erreichbare Ziele und Vorgehensweisen für Ihre Kopplungssitzung Bevor Sie starten.
• Wenn Sie bemerken, dass die Produktivität nachlässt, machen Sie eine Pause.
• Wenn Sie noch nicht viel Erfahrung mit dem Pairing haben, kann es anstrengend sein. Lassen Sie es Ihren Partner wissen, und Sie können den Diskurs auf etwas weniger Intensives verschieben.
• Wenn Sie eine Meinungsverschiedenheit nicht überwinden können, ziehen Sie einen Dritten hinzu, um zu vermitteln.
• Wenn Sie den Überblick verlieren, sagen Sie Ihrem Partner, dass Sie Rollen oder Stile wechseln möchten, um die Dinge zu verlangsamen. Es ist nicht gut, zurückgelassen zu werden.
• Ein Teil von TDD besteht darin, möglichst einfachen Code zu schreiben in diesem MomentSie müssen häufig eine Abstraktion identifizieren und umgestalten (siehe Prämisse der Transformationspriorität).

Zusätzlich zum Workshop werden Pairing und TDD im Allgemeinen von unseren Engineering-Teams gefördert, und jedes Team hat einen technischen Coach, dessen Ziel es ist, Codierungsstandards zu kommunizieren und den Teammitgliedern dabei zu helfen, Designs und Code-Factorings zu finden, die testbar sind.

Es ist leicht, XP gegenüber skeptisch zu sein, wenn Sie es nicht lange genug praktiziert haben, um die Vorteile zu erfahren. Wir stellen fest, dass TDD und Pairing Ingenieuren helfen, sich zu erfahrenen Wissenschaftlern und Designern zu entwickeln, die effektiver kommunizieren und ihr Ego zu Hause lassen. Sie könnten versucht sein, den Ruhm dafür zu beanspruchen, dass Sie selbst eine wunderschöne Schneeflocke aus Code erstellt haben, aber durch die Paarung werden Sie zu der Erkenntnis gezwungen, dass Code für jedermann zu entwerfen, zu lesen und wiederzuverwenden ist, sodass es keinen Sinn ergibt um es an Ihren persönlichen Stolz anzuhängen.