Methodik: Komponententests für einen anderen Entwickler schreiben

28

Ich dachte über Softwareentwicklung nach und schrieb Unit-Tests. Ich habe folgende Idee:

Nehmen wir an, wir haben Entwicklerpaare. Jedes Paar ist für einen Teil des Codes verantwortlich. Einer aus dem Paar implementiert eine Funktion (Schreiben von Code) und der zweite schreibt einen Komponententest dafür. Tests werden nach Code geschrieben. In meiner Vorstellung helfen sie sich gegenseitig, arbeiten aber eher getrennt. Im Idealfall würden sie an zwei Features ähnlicher Größe arbeiten und diese dann zur Testvorbereitung austauschen.

Ich denke, dass diese Idee einige Vorteile hat:

  • Tests werden von jemandem geschrieben, der mehr über die Implementierung sehen kann,
  • Die Arbeit sollte etwas schneller als die Paarprogrammierung erfolgen (zwei Funktionen gleichzeitig).
  • Beide Tests und der Code haben die verantwortliche Person dafür.
  • Code wird von mindestens zwei Personen getestet
  • Vielleicht würde die Suche nach Fehlern in Code, der von einer Person geschrieben wurde, die Ihren Code testet, eine besondere Motivation für das Schreiben von besserem Code und das Vermeiden von Schnitten geben.

Vielleicht ist es auch eine gute Idee, einen anderen Entwickler für die Codeüberprüfung zwischen Code- und Testentwicklung hinzuzufügen.

Was sind die Nachteile dieser Idee? Wird es bereits als unbekannte Methode beschrieben und in der Softwareentwicklung verwendet?

PS. Ich bin kein professioneller Projektmanager, aber ich kenne mich mit Projektentwicklungsprozessen aus und kenne die wenigen gängigen Methoden - aber diese Idee kommt mir nicht bekannt vor.

franiis
quelle
17
Sie beschreiben lediglich die nachgelagerte Qualitätssicherung auf Einheitenebene. Haben Sie versucht, mit TDD tatsächlich Paare zu programmieren, wenn zwei Personen an etwas arbeiten?
Jonrsharpe
9
Dies würde besser funktionieren, wenn der Testschreiber zuerst die Tests durchführen würde (Skelettcode schreiben) und der andere die Funktionalität implementieren würde. Der erste würde die Kontrolle über das Design haben und der andere würde das schwere Heben übernehmen. Das könnte gut funktionieren, wenn der erste weiß, was er tut, und der zweite nichts dagegen hat, die ganze Zeit seinem Beispiel zu folgen. Ich kenne keinen Namen für diese Art der Zusammenarbeit. Ich würde sagen, behaupten Sie es! Nennen Sie diese Franiis-Entwicklung.
Martin Maat,
14
Diese Kritik macht keinen Sinn und Ihr Vorschlag löst dieses Problem nicht.
Jonrsharpe
5
@franiis Ich habe gesehen, assert truewie Kollegen als Tests geschrieben haben und es einen Tag genannt haben, weil jeder Test bestanden hat. Ein wichtiger Schritt fehlte: Die Tests sollten zuerst fehlschlagen und durch Ändern des Codes und nicht der Tests bestanden werden.
Eric Duminil
6
@franiis TDD basiert auf Iteration. Test nicht bestanden. Schreiben Sie Code, der den Test grün macht. Refactor. Schreiben Sie einen nicht bestandenen Test. Schreiben Sie Code, der den Test grün macht. Refactor. Es scheint, dass Ihnen der Teil "Wiederholen, bis Sie Tests haben, die alle Ihre Anforderungen abdecken" fehlt. Aber das größte Problem, das Sie zu haben scheinen, ist, dass "Tests" als etwas angesehen werden, das Sie haben müssen, weil es jemand gesagt hat, anstatt dass Tests ein nützliches Werkzeug für die Entwickler sind . Wenn Sie die Leute nicht dazu bringen können, sich um die Qualität (und Korrektheit) ihres Codes zu kümmern, ist das Ihr Problem, und an dieser Stelle sollten Sie beginnen.
Luaan

Antworten:

30

Der allgemeine Ansatz, Paare zu verwenden, um den Aufwand für das Schreiben von Produktionscode und die damit verbundenen Komponententests aufzuteilen, ist nicht ungewöhnlich. Ich habe mich auf diese Weise schon einmal persönlich mit anständigem Erfolg gepaart. Eine strenge Linie zwischen der Person, die den Produktionscode schreibt, und der Person, die den Testcode schreibt, muss jedoch nicht unbedingt zu Ergebnissen führen.

Wenn ich einen ähnlichen Ansatz gewählt habe, fängt das Paar damit an, zu sprechen und sich ein gemeinsames Verständnis des Problems zu verschaffen. Wenn Sie TDD verwenden, können Sie zunächst mit einigen grundlegenden Tests beginnen. Wenn Sie TDD nicht verwenden, beginnen Sie möglicherweise mit der Methodendefinition. Von hier aus arbeiten beide Mitglieder des Paares sowohl am Produktionscode als auch am Testcode, wobei sich eine Person auf jeden Aspekt konzentriert und Möglichkeiten zur Verbesserung des Produktionscodes sowie des dahinter stehenden Testcodes bespricht.

Ich sehe keinen Vorteil darin, jedem Paar zwei Merkmale zu geben. Was Sie am Ende haben würden, ist etwas, das TDD für einige Funktionen ähnelt, und etwas, das TDD für andere Funktionen nicht entspricht. Sie verlieren den Fokus. Sie profitieren nicht von Peer Review in Echtzeit. Sie erhalten keine der wichtigsten Vorteile der Kopplung.

Bei der Paarprogrammierung geht es nicht um Geschwindigkeit, sondern um Qualität. Der Versuch, eine modifizierte Technik zu verwenden, bei der es darum geht, schneller zu werden, widerspricht also der Natur. Indem Sie durch parallele Codeüberprüfung und Testentwicklung qualitativ hochwertigere Software entwickeln, sparen Sie Zeit, da mindestens zwei Personen über jede Änderung Bescheid wissen und Sie Wartezyklen für Peer Review und Test vermeiden (oder verkürzen).

Thomas Owens
quelle
Vielen Dank, meine Idee geht davon aus, dass beide Funktionen auf die gleiche Weise entwickelt werden (aber die Entwickler die Rollen tauschen) - nur um zu verdeutlichen, nicht um den Sinn dieses Konzepts zu verteidigen. Ich mag Ihre Antwort und Ihren Fokus auf Geschwindigkeit gegen Qualität.
Franiis
Nach meiner Erfahrung überwiegen die Nacharbeitskosten die Vorteile dieses Ansatzes. Ich möchte lieber, dass ein Paar diese Pflichten mit "Ping-Pong" oder einer anderen Methode gegeneinander austauscht.
Neontapir
3
Bei der Paarprogrammierung geht es nicht um Geschwindigkeit, sondern um Qualität. Bei Pair TDD geht es um Qualität, die die Fertigstellung beschleunigt und die Entwicklungskosten senkt. Unsere Branche lernt nur, was Maurer seit Jahrtausenden wissen: Ihre Mauer wird in kürzerer Zeit, mit geringerem Aufwand und geringeren Kosten besser gebaut, wenn Sie einige Zeit damit verschwenden, zuerst eine Schnur und eine Maurerregel einzurichten und dann Ihre Ziegel zu legen, als wenn du legst deinen Ziegelstein und versuchst danach mit Wasserwaage und Hammer nachzustellen. Und holen Sie sich Hilfe.
Laurent LA RIZZA
@LaurentLARIZZA Das scheint richtig zu sein. Ich nehme an, eine bessere Art zu sagen wäre: "Bei der Paarprogrammierung geht es nicht um Geschwindigkeit im Jetzt, sondern um Qualität und Geschwindigkeit in der Zukunft." Es ist auf jeden Fall eine vorausschauende Praxis, Probleme früher zu finden, die Robustheit der Arbeit zu verbessern und Wissen auszutauschen, um Silos abzureißen. All dies hat jetzt Kosten, die sich in Zukunft oft auszahlen werden.
Thomas Owens
@ThomasOwens: Nun, die Qualitätskosten werden nur wahrgenommen, nicht wirklich. Sobald Ihr Test bestanden ist (und Sie Ihren Code aufgeräumt haben), ist das von Ihrem Test beschriebene Szenario abgeschlossen und gesichert, und Sie können sicher sein, dass es wie erwartet funktioniert. Es ist geschafft und Sie können weitermachen. Wenn Sie ohne die Gewissheit weitermachen, dass der Code funktioniert, haben Sie nur eine Schuld akzeptiert, die Sie später überprüfen müssen. Schulden kosten, nicht das Fehlen von Schulden. Ich meine, die "Zukunft", von der Sie sprechen, ist, sobald Ihr erster Test bestanden ist.
Laurent LA RIZZA
37

Das Hauptproblem bei Ihrer Idee ist, dass Sie nicht einfach Tests für jeden Code schreiben können. Der Code muss testbar sein.

Das heißt, Sie müssen in der Lage sein, Mocks zu injizieren, das zu testende Bit zu trennen, auf den geänderten und zu bestätigenden Status zuzugreifen usw.

Wenn Sie kein Glück haben oder den Test nicht zuerst schreiben, bedeutet das wahrscheinlich, dass Sie den Code ein wenig umschreiben. Wenn Sie nicht derjenige sind, der den Code an erster Stelle schreibt, bedeutet dies Verzögerung, Besprechungen, Umgestaltung usw

Ewan
quelle
Vielen Dank. Aber allgemeine Kritik an TDD ist, dass Code manchmal / oft geschrieben wird, um Tests "grün" zu machen - nein, um gut zu sein. Wenn Tests einen Aspekt des Codes nicht testen, kann er im Code weggelassen werden. Das spätere Schreiben eines Tests könnte hier Abhilfe schaffen (ich akzeptiere, dass nach dem Schreiben von Code einige Änderungen erforderlich sein können, aber Entwickler sollten lernen, in Zukunft mehr testbaren Code zu schreiben).
Franiis
1
@franiist sicher, das Hauptproblem ist nicht, dass Sie die Tests danach schreiben, es ist die Kombination, dass Sie das tun und nicht die gleiche Person sind, die den Code geschrieben hat.
Ewan
Wenn Sie jedoch zB die Paarprogrammierung verwenden, ist dies weniger zeitaufwändig. Wenn zwei Entwickler an einem Terminal arbeiten, können sie in keiner Weise gleichzeitig an zwei Funktionen arbeiten, und meine Idee sollte dies zulassen (auch in begrenztem Umfang). Meetings für 2-Personen-Mikroteams sollten keine wirkliche Belastung sein.
Franiis
25
@franiis: "Wenn Tests einen Aspekt des Codes nicht testen, kann er im Code weggelassen werden." - Das ist der springende Punkt. Die Tests sind eine Kodierung der Anforderungen in Form von ausführbaren Beispielen. Wenn es keinen Test dafür gibt, gibt es keine Anforderung dafür, und es sollte keinen Code dafür geben .
Jörg W Mittag
3
Die andere Seite von @ JörgWMittag wäre: Wenn Ihre Tests "keine wichtigen Code-Tests durchführen", müssen Sie Ihre Tests korrigieren. Dies gilt für Ihr System genauso wie für herkömmliche TDD.
bta
15

Das Hauptproblem, das ich hier sehe: Wenn ich Code schreibe, möchte ich ihn kompilieren und ausführen und die augenfälligsten Fehler sofort entfernen - auch wenn der Code unvollständig ist und ich weiß, dass das Gerät, die Funktion oder das Merkmal vorhanden sind nur teilweise umgesetzt. Und um den Code einer Unit auszuführen, benötige ich ein Programm, das die Implementierung aufruft, normalerweise einen Unit-Test oder zumindest einen Teil-Unit-Test. Dies ist nicht notwendigerweise "TDD-Stil nach dem Buch", ein solcher Test kann nach oder vor dem zu testenden Code geschrieben werden.

Wenn eine Version meines Geräts "funktionsfähig" und frei von allen Fehlern ist, die ich selbst finden kann, ist es sinnvoll, sie einer zweiten Person zu übergeben und sie / ihn zusätzliche Einheitentests schreiben zu lassen oder meinen Code zu überprüfen . Aber für mich macht es keinen Sinn, es abzugeben, sobald der Compiler keine Warnungen anzeigt, das ist definitiv zu früh, wenn ich weiß, dass ich dem Tester im Detail Dinge erklären musste, die "noch" nicht funktionieren oder funktionieren werden anders in zwei Stunden, da ich immer noch an diesem Stück Code arbeite. Der dafür notwendige Kommunikationsaufwand auf dieser Detailebene würde meiner Meinung nach nicht durch die Vorteile ausgeglichen.

Also ja, ein zweites dev Schreiben mit zusätzlichen Sinn macht Unit - Tests, aber nicht zum Schreiben der Unit - Tests ausschließlich .

Doc Brown
quelle
7

Es scheint die Möglichkeit zu geben, dass eine der folgenden Situationen eintritt, die alle unerwünscht sind:

Verwechslung

Wie Ewan ausführte, muss der CUT möglicherweise geändert werden, damit er testbar ist. Der Grund für die Änderung ist für den Entwickler nicht immer offensichtlich (und kann zu Meinungsverschiedenheiten führen), weshalb Tests zuerst geschrieben werden.

Streit

Entwickler A hat möglicherweise seinen Code fertiggestellt und möchte, dass er getestet wird. Entwickler B entwickelt möglicherweise auch und kann daher gezwungen sein, seinen Code zu parken, um an den Komponententests teilzunehmen.

Kontextwechsel

Auch wenn Entwickler B bereit ist, seine Entwicklung zurückzustellen, um den von Entwickler A geschriebenen Code zu testen - die Änderung der Aktivität ist mit Kosten verbunden.


Es ist seit Jahrzehnten anerkannt, dass die Verdoppelung der menschlichen Kraft die Entwicklungszeit nicht halbiert. In Anbetracht der Faktoren, die ich oben skizziert habe, ist es schwer zu sehen, wie diese Anordnung die Dinge verbessern würde.

Robbie Dee
quelle
4

In Verbindung mit Pair Programming und TDD wird dies als Ping Pong Pattern bezeichnet :

  • A schreibt einen neuen Test und stellt fest, dass er fehlschlägt.
  • B implementiert den Code, der zum Bestehen des Tests erforderlich ist.
  • B schreibt den nächsten Test und stellt fest, dass er fehlschlägt.
  • A implementiert den Code, der zum Bestehen des Tests erforderlich ist.

Und so weiter. Refactoring wird immer dann durchgeführt, wenn der Bedarf des Fahrers besteht.

Aber Sie scheinen beiden Programmierern vorzuschlagen, mit unterschiedlichen Computern zu programmieren. Für eine getrennte Ausführung ist eine sehr niedrige Spezifikation erforderlich. Dies widerspricht agilen Metodologien. Jede Änderung müsste koordiniert werden. In TDD machen Sie das Low-Level-Design im Handumdrehen und es ist kein Problem. Ich gehe davon aus, dass für Ihren Ansatz eine Art Skelett bereits codiert sein muss.

Wie auch immer: Sie können viel lernen, indem Sie neue Methoden ausprobieren, auch wenn diese nicht zu 100% effizient sind. Sie können es testen und Ihre realen Erfahrungen teilen

Borjab
quelle
3

Ich komme zu spät zu dieser Party, aber ich glaube, ich muss noch etwas hinzufügen.

Wird es bereits als unbekannte Methode beschrieben und in der Softwareentwicklung verwendet?

Sie beschreiben Peer Testing .

Nehmen wir an, wir haben Entwicklerpaare.

Ah, gute alte Pair-Programmierung .

Jedes Paar ist für einen Teil des Codes verantwortlich. Einer aus dem Paar implementiert eine Funktion (Schreiben von Code) und der zweite schreibt einen Komponententest dafür. Tests werden nach Code geschrieben. In meiner Vorstellung helfen sie sich gegenseitig, arbeiten aber eher getrennt.

Das ist keine Pair-Programmierung.

Im Idealfall würden sie an zwei Features ähnlicher Größe arbeiten und diese dann zur Testvorbereitung austauschen.

Das ist definitiv Peer Testing. Hier ist ein ACM-Artikel darüber . Ich habe das getan. Ich habe dort gearbeitet, wo es ein formaler Bestandteil des Peer Review war Prozesses war. Es ist hilfreich, aber sicherlich nicht als erste Testreihe gedacht, und es ist sicherlich keine klassische Paarprogrammierung.

Ein anderer Name dafür ist Whitebox Testing . Obwohl sich diese Definition nicht darauf bezieht, wer die Tests durchführt, sondern darauf, dass der Tester das Innenleben des zu testenden Objekts sieht, im Gegensatz zu Black-Box-Tests, bei denen nur der Inhalt und die Inhalte angezeigt werden was geht raus Black Box ist in der Regel das, was QA tut.

Die erste Testlinie liegt fest in der Hand des Programmierers. Wenn nicht, bitten Sie mich, meinen Code nicht selbst zu testen, was ich rundweg ablehne. Ich habe meinen Code getestet, seit ich 10 Jahre alt war. Ich habe damals vielleicht nicht mit ausgefallenen Unit-Tests getestet, aber mein Code wurde getestet. Es wurde jedes Mal getestet, wenn ich es laufen ließ.

Was ich von einem Peer-Tester erwarte, sind Tests, die meine Tests ergänzen. Tests, die die Probleme deutlich machen, die der Peer beim Überprüfen des Codes festgestellt hat. Durch das Ausdrücken dieser Probleme mit einem automatisierten Test wird das Verstehen ihrer Bedeutung erheblich erleichtert. Tatsächlich habe ich technische Gespräche mit Kollegen geführt, die meinen Standpunkt einfach nicht erkennen konnten, und dann festgestellt, dass es das beste Mittel ist, ihnen zu zeigen, dass das Problem darin besteht, einen Komponententest zu schreiben. Das ist Peer Testing.

Nun, wenn Sie mir Tests schreiben möchten, bevor ich meinen Code gut schreibe. Nichts ist vergleichbar mit einem Anforderungsdokument, das so formal ist, dass es kompiliert wird.

kandierte_orange
quelle
Vielen Dank für die Antwort und den Hinweis auf Peer Testing (ich werde darüber lesen).
Franiis
1

Ich habe DDT (Development Driven Testing, auch bekannt als Tests After Code), Pair Programming und Red-Green-Refactor TDD für jeweils mehrere Jahre durchgeführt. So antworten Sie Punkt für Punkt auf Ihre Behauptungen:

Tests werden von jemandem geschrieben, der mehr über die Implementierung sehen kann

Die Person, die Tests schreibt, muss die Implementierung so gut wie möglich kennen, um Tests mit einer guten Abdeckung ohne Überprüfung zu schreiben. Das klassische Beispiel hierfür ist das Testen mit drei Eingängen, wenn zwei beweisen, was Sie testen möchten. Während sie durch das Lesen des Codes eine Vertrautheit mit dem Code auf der Oberfläche erreichen können, können sie nicht genau verstehen, was der ursprüngliche Entwickler durchlaufen hat, um den aktuellen Status zu erreichen. Sie werden also den Code nicht optimal verstehen.

Die Arbeit sollte etwas schneller als die Paarprogrammierung sein (zwei Funktionen gleichzeitig)

Ich verstehe nicht, warum du das sagst. Während jemand Tests schreibt, arbeitet er nicht an neuen Funktionen. Sie können die Arbeitsfähigkeit eines Menschen nicht auf magische Weise verdoppeln, indem Sie ihm zwei verschiedene Arten von Arbeit geben. Nach meiner Erfahrung ist das Schreiben von Tests im Allgemeinen schwieriger als das Schreiben von Produktionscode. Sie könnten also definitiv nicht produktiv und verantwortungsbewusst an Tests für einen Code arbeiten, während Sie eine andere Funktion schreiben.

Sowohl für Tests als auch für Code ist eine verantwortliche Person zuständig

Zuerst Tests sind Code. Für das Unternehmen ist der Testcode fast so wichtig wie der Produktionscode, da er es dem Unternehmen ermöglicht , die Software ohne Angst zu ändern. Zweitens unterscheidet sich dies nicht von einer Person, die die Tests und den Produktionscode schreibt, oder sogar von einem Paar, das beide schreibt.

Code wird von mindestens zwei Personen getestet

Nein, es wird nur von der Person getestet, die den Test schreibt. Wenn Sie nicht noch mehr Zeit für das Testen verwenden möchten, warum sollten Sie dann bei zwei aufhören?

Vielleicht würde die Suche nach Fehlern in Code, der von einer Person geschrieben wurde, die Ihren Code testet, eine besondere Motivation für das Schreiben von besserem Code und das Vermeiden von Schnitten geben.

Entwickler (auch ältere) haben sehr unterschiedliche Vorstellungen, was "guten" Code ausmacht. Der eckpfeiler einer Person ist die absolut gültige Methode einer anderen Person, um so schnell wie möglich zum Arbeitscode zu gelangen. Dies ist ein Rezept für die Schuld und für das Spielen des Systems.

Rot-Grün-refactor TDD ( eigentlich einen einzigen Test zu schreiben , bevor die Produktion Code zu schreiben, es läuft, sieht es nicht, Modifizieren der Produktionscode nur, den Test erneut ausgeführt wird , sieht es gelingen, und dann Refactoring, und nicht das Überspringen oder tauschen alle Diese Schritte) und Codeüberprüfungen funktionieren.

l0b0
quelle
Es wäre (vermutlich) schneller, weil Sie nicht zwei Leute haben, die "die gleiche Arbeit" machen - sie machen jeweils ihr eigenes Ding und tauschen sich dann teilweise durch.
Jacob Raihle
@JacobRaihle Pairing besteht nicht aus zwei Personen, die sich ohne Kommunikation nebeneinander entwickeln. Das wären zwei Leute, die die gleiche Arbeit machen. Paarung ist sehr effizient , weil zwei Menschen zusammen an einem Stück Arbeit. Nach meiner Erfahrung ist die Entwicklung ungefähr so ​​schnell wie für einzelne Programmierer (dh Paare erledigen die Arbeit doppelt so schnell), die daraus resultierende Software hat eine viel höhere Qualität und das Wissen wurde geteilt.
l0b0
Ich versuche zu erklären, warum "etwas schneller gearbeitet werden sollte", was Sie zu verwirren schien. Nach meiner Erfahrung ist das Pairing in der Regel langsamer, obwohl ich immer noch der Meinung bin, dass es sich lohnt (besser als die Übergabe von Einzelarbeiten und OPs). Wenn es für dich schneller ist, umso besser.
Jacob Raihle
1

Ich denke, dass diese Idee einige Vorteile hat:

Sie werden einzeln durchlaufen.

Tests werden von jemandem geschrieben, der mehr über die Implementierung sehen kann,

Sie meinen also, dass der erste Entwickler einige Zeit damit verbracht hat, eine Implementierung zu schreiben, von der er nicht sicher ist, ob sie funktioniert. Dann kommt ein anderer Entwickler und schreibt Tests. Dabei stützt er sich auf den Code, von dem niemand weiß, ob er korrekt ist, und hofft, dass er einen taktischen Vorteil gegenüber dem Schreiben von Tests bietet, wenn es nur darum geht, was der Code tun soll. Wenn die Implementierung fehlerhaft ist, hilft sie meiner Meinung nach beim Schreiben von Tests nicht weiter.

Die Arbeit sollte etwas schneller als die Paarprogrammierung sein (zwei Funktionen gleichzeitig)

Sobald beide Entwickler ihre anfängliche Entwicklung abgeschlossen haben, weiß niemand, ob einer ihrer Codes korrekt ist. Dies muss noch überprüft werden, niemand kann einen Punkt als erledigt abhaken und niemand kann vorhersagen, wann er erledigt sein wird. Vergleichen Sie dies mit TDD: Sie schreiben den Test zuerst, lassen ihn dann fehlschlagen und bestehen ihn mit Code. Das ist Code, der immer mehr Szenarien unterstützt. Das ist Vorwärtsbewegung.

Wenn Sie sie parallel weiterentwickeln, wird Code, der in beiden Features wiederverwendet werden kann, zweimal geschrieben und kostet zweimal mehr.

Beide Tests und der Code haben die verantwortliche Person dafür.

Untersuchen Sie den Besitz von kollektivem Code, wie von XP vorgeschlagen. Sie werden noch mehr Leute haben, die für den Code verantwortlich sind. Wenn es Ihr Ziel ist, Wissen zwischen Entwicklern auszutauschen, warum versuchen Sie dann, diese voneinander zu trennen?

Code wird von mindestens zwei Personen getestet

Mit Paar TDD auch. Beim Pairing müssen beide Personen zustimmen, dass der geschriebene Code angemessen ist oder nicht. Wenn dies zu einem Kampf führt, haben einige Leute im Team ein falsches Ego-Problem.

Vielleicht würde die Suche nach Fehlern in Code, der von einer Person geschrieben wurde, die Ihren Code testet, eine besondere Motivation für das Schreiben von besserem Code und das Vermeiden von Schnitten geben.

Die Suche nach Fehlern impliziert, dass Sie es irgendwann toleriert haben, dass sie hereinkommen. Wenn sie hereinkommen, werden sie nicht bemerkt. Wenn Sie sich weigern, zuerst Tests zu schreiben, erhalten Sie die Lizenz für Fehler, die eingehen müssen.

Schneidecken können unbeabsichtigt sein. Dafür ist Pair Programming gedacht. Jedes Mitglied des Paares sollte angewiesen werden, sich nicht von dem anderen abschneiden zu lassen, denn das machen wir alle. Das erfordert, dass Sie Ihren Stolz im Schrank lassen und ihn zurücknehmen, wenn Sie das Büro verlassen. Wenn Sie erwarten, dass Ihre Leute stets streng sind, denken Sie nicht über die allgemeine Situation nach und machen sich bereit für einen Misserfolg.

XP sagt ausdrücklich, dass alle Praktiken, aus denen XP besteht, sich gegenseitig verstärken, indem sie die Mängel des jeweils anderen abdecken. Sie sollten sich keine Kritik an XP-Übungen anhören, die von den anderen getrennt sind. Keine Übung ist perfekt, TDD ist nicht perfekt, Paarprogrammierung ist nicht perfekt, kollektiver Code-Besitz ist nicht perfekt, aber alle decken sich gegenseitig ab.

Laurent LA RIZZA
quelle