it-swarm.com.de

Überprüfen Sie vor oder nach dem Festschreiben des Codes, was ist besser?

Traditionell haben wir vor dem Festschreiben eine Codeüberprüfung durchgeführt. Ich hatte heute einen Streit mit meinem Kollegen, der die Codeüberprüfung nach dem Festschreiben bevorzugte.

Hier sind zunächst einige Hintergrundinformationen:

  1. Wir haben einige erfahrene Entwickler und wir haben auch neue Mitarbeiter mit fast null Programmiererfahrung.
  2. Wir möchten schnelle und kurze Iterationen durchführen, um unser Produkt freizugeben.
  3. Alle Teammitglieder befinden sich am selben Standort.

Die Vorteile der Codeüberprüfung vor dem Festschreiben habe ich gelernt:

  1. Mentor Neueinstellungen
  2. Versuchen Sie, Fehler, Ausfälle und schlechte Designs zu Beginn des Entwicklungszyklus zu vermeiden
  3. Lerne von anderen
  4. Wissenssicherung, wenn jemand beendet

Aber ich habe auch einige schlechte Erfahrungen gemacht:

  1. Bei geringer Effizienz können einige Änderungen über Tage überprüft werden
  2. Geschwindigkeit und Qualität sind schwer in Einklang zu bringen, besonders für Neulinge
  3. Ein Teammitglied war misstrauisch

Was die Überprüfung nach dem Festschreiben betrifft, weiß ich wenig darüber, aber das, worüber ich mir am meisten Sorgen mache, ist das Risiko, die Kontrolle aufgrund mangelnder Überprüfung zu verlieren. Irgendwelche Meinungen?

PDATE :

  1. Wir verwenden Perforce für VCS
  2. Wir codieren und verpflichten uns in denselben Zweigen (Zweigstellen zur Stamm- oder Fehlerbehebung).
  3. Um die Effizienz zu verbessern, haben wir versucht, Code in kleine Änderungen aufzuteilen. Wir haben auch einige Live-Dialogüberprüfungen versucht, aber nicht jeder hat die Regel befolgt. Dies ist jedoch ein weiteres Problem.
71
fifth

Wie Simon Whitehead erwähnt in seinem Kommentar , hängt es von Ihrer Verzweigungsstrategie ab.

Wenn die Entwickler einen eigenen Zweig für die Entwicklung haben (was ich in den meisten Situationen sowieso empfehlen würde), würde ich die Codeüberprüfung vor dem Zusammenführen mit dem Trunk oder dem Haupt-Repository durchführen. Auf diese Weise können Entwickler während ihres Entwicklungs-/Testzyklus so oft einchecken, wie sie möchten. Jedes Mal, wenn Code in den Zweig gelangt, der den gelieferten Code enthält, wird er überprüft.

Im Allgemeinen klingen Ihre schlechten Erfahrungen mit Codeüberprüfungen eher nach einem Problem mit dem Überprüfungsprozess, für das es Lösungen gibt. Indem Sie den Code in kleineren, einzelnen Abschnitten überprüfen, können Sie sicherstellen, dass er nicht zu lange dauert. Eine gute Zahl ist, dass 150 Codezeilen in einer Stunde überprüft werden können, aber die Rate ist langsamer für Personen, die mit der Programmiersprache, dem in der Entwicklung befindlichen System oder der Kritikalität des Systems nicht vertraut sind (eine Sicherheitskritik erfordert mehr Zeit). Diese Informationen können hilfreich sein, um die Effizienz zu verbessern und zu entscheiden, wer an Codeüberprüfungen teilnimmt.

62
Thomas Owens

Es gibt ein Mantra, das noch niemand zitiert zu haben scheint: Früh und oft einchecken :

Entwickler, die lange Zeit arbeiten - und damit meine ich mehr als einen Tag -, ohne etwas in die Quellcodeverwaltung einzuchecken, bereiten sich auf einige ernsthafte Integrationsprobleme vor. Damon Poole stimmt z :

Entwickler haben das Einchecken oft verschoben. Sie haben es verschoben, weil sie andere Personen nicht zu früh beeinflussen möchten und nicht dafür verantwortlich gemacht werden möchten, dass sie den Build abgebrochen haben. Dies führt jedoch zu anderen Problemen, z. B. zum Verlust der Arbeit oder dazu, dass Sie nicht zu früheren Versionen zurückkehren können.

Meine Faustregel lautet "Früh und häufig einchecken", jedoch mit der Einschränkung, dass Sie Zugriff auf die private Versionierung haben. Wenn ein Check-in für andere Benutzer sofort sichtbar ist, besteht die Gefahr, dass unreife Änderungen vorgenommen und/oder der Build beschädigt wird.

Ich würde lieber kleine Fragmente in regelmäßigen Abständen einchecken lassen, als lange Zeiträume ohne Ahnung zu verbringen, was meine Kollegen schreiben. Soweit es mich betrifft, existiert der Code nicht, wenn er nicht in die Quellcodeverwaltung eingecheckt ist . Ich nehme an, dies ist eine weitere Form von Don't Go Dark ; Der Code ist unsichtbar, bis er in irgendeiner Form im Repository vorhanden ist.

... Wenn Sie lernen, früh und häufig einzuchecken, haben Sie ausreichend Zeit für Feedback, Integration und Überprüfung auf dem Weg ...

Ich habe für ein paar Unternehmen gearbeitet, die unterschiedliche Ansätze hatten. Man erlaubte es, solange es das Kompilieren nicht verhinderte. Der andere würde ausflippen, wenn Sie überhaupt Fehler einchecken würden. Ersteres ist sehr bevorzugt. Sie sollten sich in einer Art Umgebung entwickeln, die es Ihnen ermöglicht, mit anderen Menschen an Dingen zusammenzuarbeiten, die noch in Bearbeitung sind, mit dem Verständnis, dass alles später getestet wird.

Es gibt auch Jeff Atwoods Aussage: Hab keine Angst, Dinge zu zerbrechen :

Der direkteste Weg, sich als Softwareentwickler zu verbessern, besteht darin, absolut furchtlos zu sein, wenn es darum geht, Ihren Code zu ändern. Entwickler, die Angst vor fehlerhaftem Code haben, sind Entwickler, die niemals zu Profis heranreifen werden.

Ich würde auch hinzufügen, dass für Peer Reviews, wenn jemand möchte, dass Sie etwas ändern, die Historie Ihrer Originalversion in der Quelle ein sehr wertvolles Lernwerkzeug ist.

35
lorddev

Ich habe kürzlich begonnen, Pre-Commit-Überprüfungen in einem Projekt durchzuführen, in dem ich mich befinde, und ich muss sagen, dass ich angenehm überrascht bin, wie unproblematisch es ist.

Der größte Nachteil von Überprüfungen nach dem Festschreiben, den ich sehe, ist, dass es sich oft nur um eine Einzelperson handelt: Jemand überprüft den Code auf Richtigkeit, aber der Autor ist normalerweise nicht beteiligt, es sei denn, es liegt ein schwerwiegender Fehler vor. Kleine Probleme, Vorschläge oder Hinweise erreichen den Autor normalerweise überhaupt nicht.

Dies ändert auch das wahrgenommene Ergebnis der Codeüberprüfungen: Es wird als etwas angesehen, das nur zusätzliche Arbeit produziert, im Gegensatz zu etwas, bei dem jeder (der Prüfer und der Autor des Codes) jedes Mal neue Dinge lernen kann.

19
Joachim Sauer

Codeüberprüfungen vor dem Festschreiben scheinen so natürlich zu sein, dass mir nie in den Sinn gekommen ist, dass Überprüfungen nach dem Festschreiben absichtlich durchgeführt werden könnten. Aus Sicht der kontinuierlichen Integration möchten Sie Ihren Code nach Fertigstellung festschreiben, und zwar nicht in einem funktionierenden, aber möglicherweise schlecht geschriebenen Zustand, oder?

Vielleicht liegt es daran, dass wir es in meinen Teams immer in einem Live-Dialog gemacht haben, der vom ursprünglichen Entwickler initiiert wurde, und nicht in asynchronen, steuerungsgesteuerten, dokumentbasierten Überprüfungen.

8
guillaume31

Die meisten Repositorys unterstützen heute ein zweiphasiges Commit oder ein Regalset (privater Zweig, Pull-Anforderung, Patch-Übermittlung oder wie auch immer Sie es nennen möchten), mit dem Sie die Arbeit überprüfen/überprüfen können, bevor Sie sie in die Hauptzeile ziehen. Ich würde sagen, dass Sie durch die Nutzung dieser Tools immer Pre-Commit-Überprüfungen durchführen können.

Sie können auch die Paarkodierung (Senior-Paare mit Junior) als eine weitere Möglichkeit zur Bereitstellung einer integrierten Codeüberprüfung in Betracht ziehen. Betrachten Sie es als Qualitätsprüfung am Fließband anstatt nach dem Abrollen des Autos.

8
Michael Brown

Tue beides :

  • pre Commit - Führen Sie diese Art von Überprüfungen durch, wenn es sich um etwas sehr Wichtiges handelt, z. B. um ein sehr wiederverwendbares Codeteil oder eine wichtige Entwurfsentscheidung
  • post commit - Führen Sie diese Art von Überprüfungen durch, wenn Sie eine Meinung zu einem Code erhalten möchten, der möglicherweise verbessert wird
7
BЈовић

Jede formelle Überprüfung sollte an Quelldateien durchgeführt werden, die unter Konfigurationskontrolle stehen, und die Überprüfungsaufzeichnungen sollten die Revision der Datei eindeutig angeben.

Dadurch werden Argumente vom Typ "Sie haben nicht die neueste Datei" vermieden und sichergestellt, dass alle Benutzer dieselbe Kopie des Quellcodes überprüfen.

Dies bedeutet auch, dass der Verlauf mit dieser Tatsache versehen werden kann, falls Korrekturen nach der Überprüfung erforderlich sein sollten.

5
Andrew

Für die Codeüberprüfung selbst stimme ich für "während" des Commits.

Ein System wie Gerrit oder Clover (glaube ich) kann eine Änderung inszenieren und dann vom Prüfer an die Quellcodeverwaltung (Push in Git) übergeben lassen, wenn sie gut ist. Das ist das Beste aus beiden Welten.

Wenn das nicht praktikabel ist, denke ich, dass After Commit der beste Kompromiss ist. Wenn das Design gut ist, sollten nur die jüngsten Entwickler die Dinge so schlecht haben, dass Sie nicht möchten, dass sie jemals begangen werden. (Machen Sie eine Pre-Commit-Überprüfung für sie).

Dies führt zu einer Entwurfsprüfung - während Sie dies zur Codeüberprüfungszeit (oder zur Kundenbereitstellungszeit) tun können, sollte das Auffinden von Entwurfsproblemen früher erfolgen - bevor der Code tatsächlich geschrieben wird.

3
ptyx

Bewertungen profitieren sowohl von Pre- als auch von Post-Commits.

Commit vor Überprüfung

  • Gibt den Rezensenten das Vertrauen, dass sie die neueste Revision des Autors überprüfen.
  • Hilft sicherzustellen, dass alle den gleichen Code überprüfen.
  • Gibt eine Referenz zum Vergleich an, sobald die Überarbeitungen der Überprüfungselemente abgeschlossen sind.

Keine laufenden Commits während der Überprüfung

Ich habe Atlassian-Tools verwendet und festgestellt, dass während der Überprüfung Commits ausgeführt werden. Dies ist für Rezensenten verwirrend, daher empfehle ich dagegen.

Revisionen nach Überprüfung

Nachdem die Prüfer ihr Feedback mündlich oder schriftlich ausgefüllt haben, sollte der Moderator sicherstellen, dass der Autor die angeforderten Änderungen vornimmt. Manchmal sind sich Rezensenten oder der Autor nicht einig, ob ein Bewertungselement als Fehler, Vorschlag oder Untersuchung bezeichnet werden soll. Um Meinungsverschiedenheiten zu lösen und sicherzustellen, dass die Untersuchungsgegenstände korrekt gelöscht werden, ist das Überprüfungsteam auf das Urteil des Moderators angewiesen.

Meine Erfahrung mit rund 100 Codeinspektionen hat gezeigt, dass Überprüfungsergebnisse im Allgemeinen eindeutig sind, wenn Prüfer auf einen eindeutigen Codierungsstandard verweisen können und für die meisten Arten von Logik- und anderen Programmierfehlern. Gelegentlich gibt es eine Debatte über Nit-Picking oder ein Stilpunkt kann zu Argumenten ausarten. Durch die Vergabe von Entscheidungsbefugnissen an den Moderator wird jedoch eine Pattsituation vermieden.

Commit nach Überprüfung

  • Gibt dem Moderator und anderen Überprüfern einen Datenpunkt zum Vergleich mit dem Commit vor der Überprüfung.
  • Bietet Metriken zur Beurteilung des Werts und des Erfolgs der Überprüfung bei der Fehlerbeseitigung und Codeverbesserung.
2
DeveloperDon

Bei Peer Review besteht ein minimales Risiko, die Kontrolle zu verlieren. Immer haben zwei Personen Kenntnisse über denselben Code. Sie müssen gelegentlich wechseln, daher müssen sie die ganze Zeit aufmerksam sein, um den Code im Auge zu behalten.

Es ist sinnvoll, einen erfahrenen Entwickler und einen Neuling zusammenzuarbeiten. Auf den ersten Blick scheint dies ineffizient zu sein, ist es aber nicht. Tatsächlich gibt es weniger Fehler, und die Behebung dieser Fehler dauert weniger lange. Außerdem lernen die Neulinge viel schneller.

Um schlechtes Design zu verhindern, sollte dies vor dem Codieren erfolgen. Wenn es wesentliche Änderungen/Verbesserungen/neue Konstruktionen gibt, sollte diese vor Beginn der Codierung überprüft werden. Wenn das Design vollständig entwickelt ist, bleibt nicht viel zu tun. Das Überprüfen des Codes ist einfacher und nimmt weniger Zeit in Anspruch.

Ich bin damit einverstanden, dass es nicht unbedingt erforderlich ist, den Code vor dem Festschreiben zu überprüfen, wenn der Code von einem erfahrenen Entwickler erstellt wurde, der seine Fähigkeiten bereits unter Beweis gestellt hat. Wenn es jedoch einen Neuling gibt, sollte der Code vor dem Festschreiben überprüft werden: Der Prüfer sollte sich neben den Entwickler setzen und jede von ihm vorgenommene Änderung oder Verbesserung erklären.

2
superM

Ich und meine Kollegen haben kürzlich einige wissenschaftliche Untersuchungen zu diesem Thema durchgeführt, daher möchte ich einige unserer Erkenntnisse hinzufügen, obwohl dies eine ziemlich alte Frage ist. Wir haben ein Simulationsmodell eines agilen Kanban-Entwicklungsprozesses/-Teams erstellt und die Überprüfung vor und nach dem Festschreiben für eine große Anzahl unterschiedlicher Situationen verglichen (unterschiedliche Anzahl von Teammitgliedern, unterschiedliche Fähigkeiten, ...). Wir haben uns die Ergebnisse nach 3 Jahren (simulierter) Entwicklungszeit angesehen und nach Unterschieden in Bezug auf Effizienz (fertige Story-Punkte), Qualität (von Kunden gefundene Fehler) und Zykluszeit (Zeit vom Start bis zur Auslieferung einer User Story) gesucht. . Unsere Ergebnisse sind wie folgt:

  • Die Unterschiede in Bezug auf Effizienz und Qualität sind in vielen Fällen vernachlässigbar. Wenn dies nicht der Fall ist, hat die Überprüfung nach dem Festschreiben einige Vorteile in Bezug auf die Qualität (andere Entwickler fungieren in gewisser Weise als "Beta-Tester"). Aus Effizienzgründen hat das Post-Commit einige Vorteile in kleinen Teams und das Pre-Commit einige Vorteile in großen oder ungelernten Teams.
  • Die Überprüfung vor dem Festschreiben kann zu längeren Zykluszeiten führen, wenn der Start abhängiger Aufgaben durch die Überprüfung verzögert wird.

Daraus haben wir folgende heuristische Regeln abgeleitet:

  • Wenn Sie einen etablierten Codeüberprüfungsprozess haben, müssen Sie ihn nicht ändern, es ist wahrscheinlich nicht die Mühe wert
    • es sei denn, Sie haben Probleme mit der Zykluszeit => Wechseln Sie zu Post
    • Oder Probleme stören Ihre Entwickler zu oft => Wechseln Sie zu Pre
  • Wenn Sie noch keine Bewertungen abgeben
    • Verwenden Sie Pre Commit, wenn einer dieser Vorteile für Sie gilt
      • Durch die Überprüfung vor dem Festschreiben können Außenstehende ohne Festschreibungsrechte zu Open Source-Projekten beitragen
      • Wenn die Überprüfung vor dem Festschreiben auf Tools basiert, wird eine gewisse Überprüfungsdisziplin in Teams mit ansonsten laxer Prozesseinhaltung erzwungen
      • Die Überprüfung vor dem Festschreiben verhindert auf einfache Weise, dass nicht überprüfte Änderungen übermittelt werden. Dies ist praktisch für eine kontinuierliche Bereitstellung/sehr kurze Release-Zyklen
    • Verwenden Sie Pre Commit, wenn Ihr Team groß ist und Sie mit den Problemen in der Zykluszeit leben oder diese umgehen können
    • Andernfalls (z. B. kleines, qualifiziertes Industrieteam) wird das Post-Commit verwendet
  • Suchen Sie nach Kombinationen, die Ihnen die Vorteile beider Welten bieten (wir haben diese formal nicht untersucht).

Das vollständige Forschungspapier finden Sie hier: http://dx.doi.org/10.1145/2904354.2904362 oder auf meiner Website: http://tobias-baum.de

1
Tobias B.

Das hängt von Ihrem Team ab. Für ein relativ erfahrenes Team, das sich mit kleinen, häufigen Commits auskennt, ist eine Überprüfung nach dem Commit in Ordnung, nur um ein zweites Paar Augen auf den Code zu bekommen. Bei größeren, komplexeren Commits und/oder weniger erfahrenen Entwicklern erscheint es vorsichtiger, Überprüfungen vorab festzuschreiben, um Probleme zu beheben, bevor sie eintreten.

In diesem Sinne verringert ein guter CI-Prozess und/oder gated Check-Ins die Notwendigkeit von Überprüfungen vor dem Festschreiben (und möglicherweise auch nach dem Festschreiben für viele von ihnen).

1
Telastyn

Meiner Meinung nach funktioniert Code Peer Review am besten, wenn es nach dem Festschreiben durchgeführt wird.

Ich würde empfehlen, Ihre Verzweigungsstrategie anzupassen. Die Verwendung eines Entwickler- oder Feature-Zweigs bietet eine Reihe von Vorteilen, von denen nicht zuletzt die Überprüfung von Code nach dem Festschreiben erleichtert wird.

Ein Tool wie Crucible glättet und automatisiert den Überprüfungsprozess. Sie können einen oder mehrere festgeschriebene Änderungssätze auswählen, die in die Überprüfung einbezogen werden sollen. Im Schmelztiegel wird angezeigt, welche Dateien in den ausgewählten Änderungssätzen berührt wurden, welche Dateien jeder Prüfer bereits gelesen hat (insgesamt% vollständig) und die Prüfer können problemlos Kommentare abgeben.

http://www.atlassian.com/software/crucible/overview

Einige andere Vorteile von Benutzer-/Funktionszweigen:

  • Entwickler erhalten die Vorteile der Versionskontrolle (Sichern von Änderungen, Wiederherstellen aus dem Verlauf, Diff-Änderungen), ohne sich Sorgen machen zu müssen, dass das System für alle anderen beschädigt wird.
  • Änderungen, die Fehler verursachen oder nicht rechtzeitig abgeschlossen werden, können zurückgesetzt, neu priorisiert oder bei Bedarf zurückgestellt werden.

Für unerfahrene Entwickler ist eine regelmäßige Beratung mit einem Mentor und/oder einer Paarprogrammierung eine gute Idee, aber ich würde dies nicht als "Codeüberprüfung" betrachten.

0
RMorrisey

Beide. (So'ne Art.)

Sie sollten Ihren eigenen Code zusammenfassend überprüfen, bevor Sie ihn festschreiben. In Git finde ich den Staging-Bereich großartig. Nachdem ich meine Änderungen vorgenommen habe, starte ich git diff --cached um alles zu sehen, was inszeniert ist. Ich nutze dies als Gelegenheit, um sicherzustellen, dass ich keine Dateien einchecke, die nicht dazu gehören (Build-Artefakte, Protokolle usw.), und um sicherzustellen, dass dort kein Debug-Code oder wichtiger Code kommentiert ist aus. (Wenn ich etwas mache, von dem ich weiß, dass ich nicht einchecken möchte, hinterlasse ich normalerweise einen Kommentar in Großbuchstaben, damit ich ihn während der Inszenierung erkenne.)

Allerdings sollte Ihre Peer-Code-Überprüfung im Allgemeinen nach dem Festschreiben durchgeführt werden, vorausgesetzt, Sie arbeiten an einem Themenzweig. Dies ist der einfachste Weg, um sicherzustellen, dass alle anderen das Richtige überprüfen. Wenn es größere Probleme gibt, ist es keine große Sache, sie in Ihrem Zweig zu beheben oder zu löschen und von vorne zu beginnen. Wenn Sie Codeüberprüfungen asynchron durchführen (d. H. Mit Google Code oder Atlassian Crucible), können Sie problemlos zwischen Zweigen wechseln und an etwas anderem arbeiten, ohne all Ihre verschiedenen Patches/Unterschiede, die derzeit einige Tage lang überprüft werden, separat verfolgen zu müssen.

Wenn Sie nicht an einem Themenzweig arbeiten, sollten Sie. Es reduziert Stress und Ärger und macht die Release-Planung viel stressfreier und komplizierter.

Bearbeiten: Ich sollte auch hinzufügen, dass Sie nach dem Testen eine Codeüberprüfung durchführen sollten, was ein weiteres Argument für das Festschreiben von Code ist. Sie möchten nicht, dass Ihre Testgruppe mit Dutzenden von Patches/Unterschieden aller Programmierer herumfummelt und dann Fehler einreicht, nur weil sie den falschen Patch am falschen Ort angewendet haben.

0
Mark E. Haase

100% gepaarte Programmierung (egal wie hochrangig Sie sind) mit vielen kleinen Commits und einem CI-System, das auf JEDEM Commit aufbaut (mit automatisierten Tests einschließlich Einheiten, Integration und Funktion, wo immer dies möglich ist). Post-Commit-Überprüfungen für große oder riskante Änderungen. Wenn Sie eine Art Gated/Pre-Commit-Überprüfung benötigen, funktioniert Gerrit.

0
Eric Smalling

Der Vorteil der Codeüberprüfung beim Einchecken (Buddy-Check) ist die sofortige Rückmeldung, bevor große Codeteile fertiggestellt wurden.

Der Nachteil der Codeüberprüfung beim Einchecken besteht darin, dass Personen vom Einchecken abgehalten werden können, bis lange Codeabschnitte abgeschlossen sind. In diesem Fall wird der Vorteil vollständig zunichte gemacht.

Was dies schwieriger macht, ist, dass nicht jeder Entwickler gleich ist. Einfache Lösungen funktionieren nicht für alle Programmierer. Einfache Lösungen sind:

  • Vorgeschriebene Paarprogrammierung, die häufiges Einchecken ermöglicht, da der Buddy direkt neben Ihnen ist. Dies ignoriert, dass die Paarprogrammierung nicht immer für alle funktioniert. Richtig gemacht, kann die Paarprogrammierung auch sehr anstrengend sein, so dass es nicht unbedingt den ganzen Tag zu tun ist.

  • Entwicklerzweige, Code wird erst im Hauptzweig überprüft und überprüft, wenn er fertig ist. Einige Entwickler neigen dazu, im Geheimen zu arbeiten, und nach einer Woche entwickeln sie Code, der möglicherweise aufgrund grundlegender Probleme, die früher entdeckt worden sein könnten, die Überprüfung besteht oder nicht.

  • Überprüfung bei jedem Check-in, was häufige Überprüfungen garantiert. Einige Entwickler sind vergesslich und verlassen sich auf sehr häufige Check-Ins, was bedeutet, dass andere alle 15 Minuten Codeüberprüfungen durchführen müssen.

  • Überprüfung zu einem nicht festgelegten Zeitpunkt nach dem Check-in. Bewertungen werden weiter veröffentlicht, wenn es zu einer Terminkrise kommt. Code, der von bereits festgeschriebenem, aber noch nicht überprüftem Code abhängt, wird festgeschrieben. Überprüfungen werden Probleme kennzeichnen und die Probleme werden in den Rückstand aufgenommen, um "später" behoben zu werden. Ok, ich habe gelogen: Dies ist keine einfache Lösung, es ist überhaupt keine Lösung. Die Überprüfung zu einem bestimmten Zeitpunkt nach dem Einchecken funktioniert, ist jedoch weniger einfach, da Sie entscheiden müssen, wie spät dieser Zeitpunkt ist

In der Praxis machen Sie diese Arbeit, indem Sie sie gleichzeitig noch einfacher und komplexer machen. Sie legen einfache Richtlinien fest und lassen jedes Entwicklungsteam als Team herausfinden, was es tun muss, um diese Richtlinien zu befolgen. Ein Beispiel für solche Richtlinien ist:

  • Die Arbeit gliedert sich in Aufgaben, die weniger als einen Tag dauern sollten.
  • Eine Aufgabe wird nicht beendet, wenn der Code (falls vorhanden) nicht eingecheckt wurde.
  • Eine Aufgabe ist nicht abgeschlossen, wenn der Code (falls vorhanden) nicht überprüft wurde.

Viele alternative Formen solcher Richtlinien sind möglich. Konzentrieren Sie sich auf das, was Sie tatsächlich wollen (Peer-Review-Code, beobachtbarer Arbeitsfortschritt, Verantwortlichkeit) und lassen Sie das Team herausfinden, wie es Ihnen das geben kann, was es will.

0
Peter