Wie man TCR übt (Test && Commit

InfoQ-Homepage-Artikel Wie das Üben von TCR (Test && Commit || Revert) die Stapelgröße reduziert

20. Februar 2023 13 Minuten Lesezeit

von

Philippe Bourgau

rezensiert von

Matt Campbell

Vor einiger Zeit führten ein Kollege und ich auf einer Konferenz in Paris eine Code-Kata durch. Hier waren die Erkenntnisse, die die Leute am Ende zum Ausdruck brachten:

Ich dachte, ich mache kleine Schritte, aber ich entdeckte, dass ich sie noch kleiner machen könnte!

Ich brauche noch mehr Erfahrung mit dem TDD selbst!

ScyllaDB ist die Datenbank für datenintensive Apps, die einen hohen Durchsatz und eine geringe Latenz erfordern. Erreichen Sie eine extreme Skalierung mit den niedrigsten Gesamtbetriebskosten. Erfahren Sie mehr.

Ich habe mich in endlosem Refactoring verloren.

Mittlerweile sind DevOps und Continuous Delivery in der Branche weit verbreitet. Aber wird die Arbeit in kleinen Abschnitten erledigt, kontinuierlich integriert und mit ihnen gespielt? Viele Teams arbeiten immer noch mit Feature-Branches und integrieren nur vollständige Features!

Wäre es nicht großartig, wenn das Schreiben von Code in kleinen Schritten für Entwickler zur zweiten Natur geworden wäre? Das volle Potenzial von Trunk-basierter Entwicklung, DevOps und Continuous Delivery ausschöpfen!

TCR ist eine Technik, die Sie dazu zwingt, Code in kleinen Schritten zu schreiben! Es ist auch ein harter, aber effektiver Lehrer. Lassen Sie uns mehr darüber erfahren. Wir werden sehen, wie Entwickler es nutzen, um eine kontinuierlichere Bereitstellung durchzuführen und ihre Teamkollegen zu coachen:

TCR steht für Test and Commit oder Revert. Es ersetzt den Testbefehl durch einen Test && Commit || Befehl zurücksetzen. Daher führen Entwickler den TCR-Befehl aus, anstatt den Test zu starten, um zu überprüfen, ob ihr Code funktioniert. Wenn der Code wie erwartet funktioniert, übergibt TCR ihn an das Versionskontrollsystem. Wenn der Code nicht funktioniert, setzt TCR ihn auf den neuesten Arbeitszustand zurück!

TCR begann als verrücktes Experiment von Lars Barlindhaug, Oddmund Strømme, Ole Johannessen und Kent Beck während eines Code Camps in Oslo. Kent Beck verbreitete die Nachricht dann über seinen Blog. Kent Beck meint, wir sollten dumme Ideen ausprobieren, denn manchmal erweisen sie sich als brillant! Ob TCR dumm oder brillant ist, ist noch offen. Doch wer lange genug dabei bleibt, findet es aufschlussreich!

Quelle

Du wirst bestimmt etwas lernen. (Kent Beck über den Versuch mit TCR)

Tatsächlich berichten Entwickler, die TCR ernsthaft ausprobiert haben, von vielen Vorteilen:

Lesen wir aus erster Hand, was sie sagen. Hier sind Interviews mit zwei TCR-Praktikern.

Hallo Guillaume, kannst du uns in ein paar Worten etwas über dich erzählen?

Guillaume Faas : Sicher. Mein Name ist Guillaume und ich bin derzeit .NET Developer Advocate bei Vonage. Ich bin seit fast 15 Jahren in der Softwarebranche tätig und habe die gesamte Zeit über im .NET-Ökosystem gearbeitet. Wenn ich jedoch einen Meilenstein meiner Karriere auswählen müsste, wäre es nicht eine Rolle oder ein Projekt, sondern die Anerkennung des Software-Handwerks. Tatsächlich hat es meine Sicht auf die Softwareentwicklung drastisch verändert, und es gibt ein Vorher und ein Nachher. Seitdem versuche ich konsequent, die Denkweise und ihre Werte zu verbreiten.

Können Sie uns Ihre TCR-Geschichte erzählen: Wie sind Sie zur TCR gekommen? Was waren Ihre ersten Eindrücke?

Faas : Komisch, dass du fragst. Meine erste Begegnung mit TCR hatte ich während eines Ihrer Workshops, insbesondere beim Bowlingspiel beim Software Craftsmanship Luxembourg-Treffen. Ich erinnere mich, dass der Workshop so viel Spaß gemacht und aufschlussreich war. Aber leider waren unsere kleinen Schritte nicht so klein und wir begannen, Angst davor zu haben, unsere Änderungen zu speichern. Dennoch war ich davon begeistert und hatte den Willen, mehr zu üben.

Wofür nutzen Sie TCR heute?

Faas: Um völlig transparent zu sein, wende ich TCR mit dem Tool an, das das technische Coaching-Team von Murex entwickelt hat. Ich nutze es hauptsächlich für Katas im Rahmen von Coaching-Sitzungen. Es ist eine großartige Möglichkeit, TDD zu unterrichten, weil es mehr Ideen bringt und nicht unbedingt schwieriger ist. Ich habe es auch für Produktionscode verwendet, aber ich würde den Leuten raten, vorsichtig zu sein. Wenn Sie sicherstellen, dass jeder Test jedes Mal erfolgreich ist, kann dies Ihre Feedbackschleife drastisch verlangsamen. Schließlich habe ich es auch bei technischen Tests als Kandidat eingesetzt.

Welche Vorteile haben Sie durch den Einsatz von TCR im Schulungskontext festgestellt?

Faas: Die Leute erkennen, dass sie dem Code, den sie schreiben, nicht vertrauen. Wie ich bereits sagte, hatten wir Angst, unsere Änderungen zu speichern. Es besteht ein klarer Zusammenhang mit dem folgenden Zitat von Kent Beck: „Testgetriebene Entwicklung ist eine Möglichkeit, die Angst beim Programmieren zu bewältigen.“ Außerdem denken wir alle, dass wir in kleinen Schritten arbeiten. Spoiler: Wir liegen alle falsch. TCR zwingt Sie dazu, klein und oft zu arbeiten, was viele Vorteile mit sich bringt, darunter ein nachhaltiges Tempo und weniger ermüdende Arbeit.

Wie reagieren Menschen normalerweise, wenn sie während des Trainings mit TCR konfrontiert werden?

Faas: „Oh nein, ich werde meinen Code verlieren.“ Und es könnte richtig sein. Aber die Leute merken schnell, dass sie nur wenig verlieren werden, wenn sie ihre TDD-Zyklen reduzieren. Es macht auch ziemlich süchtig und macht Spaß. Sie werden ermutigt, Ihr Vertrauen in den Code, den Sie gerade geschrieben haben, auf die Probe zu stellen. Ich habe jedes Mal Folgendes beobachtet: Die Leute begannen, auf die Testergebnisse zu wetten, bevor sie die Tests durchführten.

Vor welchen Herausforderungen standen Sie bzw. stehen Sie immer noch vor, als Sie TCR für das Training einsetzen?

Faas: Menschen sind normalerweise eingeschüchtert. Sie glauben, dass sie gleichzeitig etwas anderes lernen müssen, was falsch ist. Außerdem fühlt sich das Zurücksetzen von Code wie eine Verschwendung von Produktivität an. Die Herausforderung besteht also darin, sie dazu zu bringen, es trotzdem zu versuchen.

Haben Sie Empfehlungen für Leser, die TCR zum Üben oder Trainieren anderer nutzen möchten?

Faas: Der Blogbeitrag von Kent Beck zum Thema selbst ist ein hervorragender Einstieg. Auch als regelmäßiger Leser kann ich Ihren Blog nur empfehlen. Es enthält fantastische Artikel wie zum Beispiel den über evolutionäres Design. Ansonsten macht Übung den Meister. Schließen Sie sich also einigen Leuten zum Kata an und experimentieren Sie. Es macht Spaß und man lernt garantiert etwas.

Wo sehen Sie TCR in der Zukunft des Software-Engineerings?

Faas: Das ist eine schwierige Frage. Ich befürworte TDD und TCR so weit ich kann. Obwohl TCR ziemlich neu ist (2018, wenn ich mich recht erinnere), reicht TDD bis in die frühen 90er Jahre zurück und muss noch weit verbreitet werden. Die meisten Entwickler, denen ich begegne, haben noch nie einen Test geschrieben oder, schlimmer noch, sind allergisch gegen Tests! Es kann sein, dass wir mehrere Jahre voller Hektik vor uns haben, bevor TCR zu einer Sache wird. Als Praktiker müssen wir die Botschaft verbreiten und ihre Umsetzung beschleunigen.

Was sollten wir Ihrer Meinung nach tun, um TCR dieser Vision einen Schritt näher zu bringen?

Faas: Ich muss zur vorherigen Frage zurückkehren. Wir alle wissen, dass TDD eine schöne Praxis ist, und die meisten Vordenker sind sich einig. Aber wo ist es gescheitert? Warum wird es angesichts der Vielzahl an Vorträgen, Büchern und Artikeln, die seine Vorteile loben, nicht stärker angenommen? Wie garantieren wir ein anderes Ergebnis? Ich habe keine magische Lösung. Wir müssen eine Gruppe nach der anderen auf die Angelegenheit aufmerksam machen.

Hallo Xavier, kannst du uns in ein paar Worten etwas über dich erzählen?

Xavier Detant : Ich bin derzeit CTO bei Great Place To Work France und werde bald zu Eove wechseln. Ich arbeitete zehn Jahre lang als Auftragnehmer, bevor ich eine Vollzeitstelle bei einem Softwareunternehmen annahm. Ich habe TDD vor 8 oder 9 Jahren entdeckt und übernommen. Ich bin Vater eines sehr süßen Jungen und Ehemann einer lieben Frau.

Können Sie uns Ihre TCR-Geschichte erzählen: Wie sind Sie zur TCR gekommen? Was waren Ihre ersten Eindrücke?

Entspannung : Wie viele andere habe ich TCR durch den Blogbeitrag von Kent Beck entdeckt. Mein erster Gedanke war: „Das klingt nach einer interessanten Einschränkung für eine Kata“, also habe ich es versucht. Zuerst erinnerte es mich an die Einschränkung „Ihr Computer ist defekt“, bei der ein Skript im Hintergrund Ihren Code alle zwei Minuten über Git zurücksetzt und Sie nur dann einen Commit durchführen können, wenn er grün ist. Der Hauptunterschied besteht darin, dass das Skript Ihr Test ist und die Schleife so lang oder so kurz ist, wie Sie möchten. Meine erste Reaktion war: „Ich liebe es für das Refactoring, aber es ist sehr unangenehm, wenn kein Test auf Rot läuft.“ Ich war neugierig, ob das Unbehagen anhalten würde, also machte ich mehr Katas. Dabei hat mir das sehr gut gefallen:

Folgendes hat mir wirklich nicht gefallen:

Aus diesem Grund habe ich den Fluss von TCR angepasst, um ihn näher an TDD anzugleichen, bin aber bei den Dingen geblieben, die mir von TCR gefallen haben. Die Symmetrie von TCR ist TRC: Führen Sie die Tests durch; wenn grün, kehren Sie zurück; Andernfalls verpflichten Sie sich. Das passt sehr gut zur roten Phase von TDD. Deshalb habe ich ein Skript erstellt, um dies zu tun (und einige Komplexitäten zu vereinfachen, z. B. das Vermeiden roter Commits beim Pushen). Mir gefiel das Ergebnis und ich verwende es seitdem.

Wofür verwenden Sie TCR?

Entspannung : Ich verwende es für alles, was ich programmiere. Es vervollständigt meinen TDD-Workflow.

Welche Vorteile haben Sie durch den Einsatz von TCR in Ihrer täglichen Arbeit festgestellt?

Entspannung : Ein individueller Vorteil ist die Rückmeldung über Ihren Ermüdungszustand. Wenn Sie zu müde sind, um einen guten Zug zu machen, bleiben Sie buchstäblich stecken. Und Sie sehen, wie die Größe Ihrer Schritte im Laufe des Tages kleiner wird. So sind Sie sich dessen jederzeit bewusst und fahren trotzdem so schnell, wie Sie tatsächlich können.

Welche Auswirkungen hat der Einsatz von TCR auf den Software-Konstruktionsprozess?

Entspannung : Ein organisatorischer Vorteil ist eine verbesserte kontinuierliche Integration und Bereitstellung. Jeder, der Zugang zur Vorproduktionsplattform hat, kann jederzeit sehen, was ich an meiner Aufgabe gemacht habe, und Feedback geben. Es war ein großer Fortschritt in Sachen Agilität, da wir etwas entwerfen, es gleichzeitig verwenden und uns entsprechend dem ersten Eindruck verbessern können. Das bedeutet auch, keine bösen Gefühle zu haben:

Das ist super bequem, entspannt und konstruktiv.

Vor welchen Herausforderungen standen Sie bzw. stehen Sie immer noch beim Einsatz von TCR in der Produktion?

Entspannung : Die größte Herausforderung besteht darin, nicht zu „schummeln“. In Ihrer IDE sind Sie nur noch STRG+Z davon entfernt, den gerade verlorenen Code wiederherzustellen (Hinweis: kurz nachdem TCR zurückgesetzt wurde). Wenn Sie es verloren haben, gibt es einen Grund. Halten Sie inne und denken Sie darüber nach! Natürlich ist Pragmatismus der Schlüssel. Wenn Ihnen beim Durchführen Ihrer Tests ein Tippfehler aufgefallen ist, lassen Sie zu, dass Sie schummeln. Ja, ich bin immer noch damit konfrontiert, vor allem am Ende des Tages, wenn ich nicht zugeben möchte, dass ich zu müde bin, um gute Arbeit zu leisten, und das, was ich tue, zu Ende bringen möchte. Jedes Mal, wenn ich aus diesem Grund betrogen habe, habe ich es am nächsten Tag bereut.

Haben Sie Empfehlungen für Leser, die mit der Nutzung von TCR beginnen möchten?

Entspannung : Versuchen Sie TCR zunächst nur für die Refactoring-Phase. Entdecken Sie dann Katas und beginnen Sie mit der Verwendung im Produktionscode. Wenn es Ihnen gefällt, finden Sie schließlich eine Möglichkeit, es außerhalb der Refactoring-Schritte zu erweitern.

Wo sehen Sie TCR in der Zukunft des Software-Engineerings?

Entspannung : Ich glaube nicht, dass TCR so weit kommen wird wie TDD (und TDD ist immer noch nicht allgegenwärtig). Ich denke jedoch, dass es ein sehr guter Ausgangspunkt für neue Arbeitsideen sein wird. Was TDD betrifft, müssen wir leider wahrscheinlich 20 Jahre warten, bis sich unterschiedliche Arbeitsweisen zum „Mainstream“ durchsetzen.

Was sollten wir Ihrer Meinung nach tun, um TCR dieser Vision einen Schritt näher zu bringen?

Entspannung : Probieren Sie Ideen aus. Wir werden unsere Arbeitsweise nicht verbessern, wenn wir Dinge nicht ausprobieren – auch die „offensichtlich Dummen“. Wir haben den Luxus, zum Spaß Nebenprojekte erstellen zu können. Wir dürfen aus dummen Gründen an unseren Nebenprojekten scheitern. Lassen Sie uns das nutzen. Verdammt, die meisten Projekte können es sich leisten, aus dummen Gründen zu scheitern, da so viele Projekte immer noch aus „nicht albernen“ Gründen scheitern, wie zum Beispiel:

Wenn ein Produkt nicht lebenswichtig ist, ist der Einsatz neuer, unerprobter Arbeitsweisen eine Option. Risiken eingehen! Unser Fachgebiet ist neu und wir haben viel zu entdecken, zu testen und zu lernen. Seien Sie ein Entdecker und teilen Sie Ihre Abenteuer mit uns!

Meine Kollegen und ich haben auch TCR praktiziert und wir haben weitere Vorteile festgestellt!

TDD, gefolgt vom Buch, führt konstruktionsbedingt zu einer hohen Abdeckung. Durch die Durchsetzung einer strengen TDD bietet TCR eine noch höhere Abdeckung! TCR führt zu einer soliden Filialabdeckung von 90 % oder mehr. Der verbleibende nicht abgedeckte Code besteht aus Konstanten oder Leimcode.

Eine erhöhte Abdeckung ist eine weitere Möglichkeit, mit der TCR die kontinuierliche Integration und den Lieferfluss verbessert. Durch das frühzeitige Erkennen von Fehlern vermeiden Entwicklertests Fehler in der nachgelagerten Pipeline.

Die Git-Übergabe ist eine unkomplizierte, robuste, effektive und kostengünstige Möglichkeit zur Remote-Kopplung. Es funktioniert durch:

Durch kontinuierliches Festschreiben kleiner Codeänderungen sorgt TCR für eine nahtlose Git-Übergabe. Es ist einfach, Ihr TCR-Skript so zu optimieren, dass es beim Commit einen Push durchführt. Wir können auch das Abrufen der neuesten Änderungen automatisieren. Der Rollenwechsel im Mob wird so einfach wie das Starten der Bildschirmfreigabe!

TDD ist schwer zu lehren, da die Anwendung in „haarigem“ Produktionscode für Neulinge schwierig ist. Überraschenderweise ist es für die Leute einfacher, in TCR einzukaufen! TCR scheint verrückt zu sein und die Leute denken nicht einmal daran, es in ihrer täglichen Arbeit einzusetzen. Als Trainer erklären wir, dass es sich um ein Werkzeug handelt, das ihnen hilft, die Programmierung in kleinen Schritten zu üben. Sie geraten in eine konstruktive „Trainings“-Denkweise. Später, zurück an ihren Schreibtischen, können sie ihre Arbeit in kleinere Schritte aufteilen, sogar in alten und ungetesteten Codebasen!

Guillaume und Xavier sagten, dass der beste Einstieg in TCR darin besteht, es an einer Kata auszuprobieren! Führen Sie einfach git init aus und verwenden Sie einen anderen Befehl für Ihre Tests:

&& git commit -am "TCR" || Git-Wiederherstellung.

Wenn Sie etwas mehr Schnickschnack wünschen, gibt es zahlreiche Open-Source-Tools für TCR:

Gewöhnen Sie sich bei ein paar Katas an TCR! Wenn Sie dann erst einmal den Dreh raus haben und Ihren Produktionscode schnell genug testen können, versuchen Sie es mit reinem Refactoring!

Das Schreiben für InfoQ hat viele Türen geöffnet und die Karrierechancen erhöht Für mich. Ich konnte mich intensiv mit Experten und Vordenkern austauschen, um mehr über die von mir behandelten Themen zu erfahren. Und ich kann meine Erkenntnisse auch an die breitere Tech-Community weitergeben und verstehen, wie die Technologien in der realen Welt eingesetzt werden.

Ich habe das Mitwirkendenprogramm von InfoQ Anfang dieses Jahres entdeckt und es seitdem genossen! Das Peer-to-Peer-Review-System von InfoQ bietet mir nicht nur eine Plattform, auf der ich meine Erkenntnisse mit einer globalen Community von Softwareentwicklern teilen kann, sondern hat auch mein Schreiben erheblich verbessert . Wenn Sie nach einem Ort suchen, an dem Sie Ihr Software-Know-how teilen können, beginnen Sie mit der Mitarbeit bei InfoQ.

Ich habe angefangen, Nachrichten für die InfoQ .NET-Warteschlange zu schreiben, um auf dem neuesten Stand der Technik zu bleiben, aber ich habe so viel mehr daraus gemacht. Ich habe sachkundige Leute kennengelernt, weltweite Sichtbarkeit erlangt und meine Schreibfähigkeiten verbessert.

Redakteur für InfoQ zu werden war eine der besten Entscheidungen meiner Karriere . Es hat mich herausgefordert und mir in vielerlei Hinsicht geholfen, zu wachsen . Wir würden uns über mehr Leute freuentrete unserem Team bei.

InfoQ sucht einen Chefredakteur in Vollzeit dem internationalen, stets remote arbeitenden Team von C4Media beizutreten. Entdecken Sie mit uns die innovativsten Technologien unserer Zeit, arbeiten Sie mit den besten Software-Experten der Welt zusammen und helfen Sie mehr als 1,6 Millionen Entwicklerteams bei der Einführung neuer Technologien und Praktiken, die die Grenzen dessen erweitern, was Software und Teams leisten können!

Jeden Dienstag wird eine Zusammenfassung der Inhalte der letzten Woche auf InfoQ verschickt. Treten Sie einer Community von über 250.000 erfahrenen Entwicklern bei. Sehen Sie sich ein Beispiel an

Wir schützen Ihre Privatsphäre.

Sie müssen ein InfoQ-Konto registrieren oder sich anmelden oder anmelden, um Kommentare zu posten. Aber hinter der Registrierung steckt noch viel mehr.

Holen Sie das Beste aus dem InfoQ-Erlebnis heraus.

Zulässiges HTML: a,b,br,blockquote,i,li,pre,u,ul,p

Zulässiges HTML: a,b,br,blockquote,i,li,pre,u,ul,p

Zulässiges HTML: a,b,br,blockquote,i,li,pre,u,ul,p