Peer Reviews oder Pair Programming oder beides?[geschlossen]

Question

• Nehmen Sie an Code-Peer-Reviews teil oder üben Sie Paarprogrammierung oder beides?
• Konnten Sie mit diesen Praktiken eine Steigerung der Softwarequalität nachweisen?
• Welche Vor- und Nachteile haben Sie in der Praxis beobachtet?
• Welche Hürden gab es bei der Umsetzung?

In meinem Fall führte unser Entwicklungsteam Peer-Reviews verschiedener Softwareartefakte durch (Anforderungsanalysen, Testpläne, Code usw.).Peer-Programmierung wurde nicht einmal als Option in Betracht gezogen.

Die Peer-Review-Praxis wurde von oben herabgedrückt, und die Entwickler haben sich nie darauf eingelassen.Wir hatten eine externe SQA-Gruppe, die Kennzahlen zu den Aktivitäten sammelte, aber die Zahlen waren ziemlich wertlos, da der Aufwand halbherzig war.Nachdem dies jahrelang die „offizielle“ Vorgehensweise war, sind die Entwickler dazu übergegangen, die vorgeschriebenen Verfahren kollektiv zu ignorieren.

Jetzt gibt es weniger Einblick, wann Fehler in den Lebenszyklus eingeschleust werden.Und die Nichtdurchführung der Peer-Reviews hat zu einer stärkeren Spezialisierung des Teams geführt, sodass niemand wirklich die Anforderungen/Logik von Komponenten außerhalb seines eigenen Spezialbereichs des Systems kennt.

Es wäre wertvoll, Ihre Erfahrungen mit Peer-Reviews oder Pair-Programming zu kennen, insbesondere Erfolgsgeschichten.

Answer 1

Als ich jung und dumm war, bestand eine meiner ersten Aufgaben darin, einen Parser zu bauen, um bestimmte Felder in einer langen PDF-Datei herauszuziehen, die in unformatierten Text umgewandelt wurde.Ich wusste genug, um irgendeine Form von Regex zu verwenden, aber nicht genug über Regexs, um die Arbeit gut zu machen.Einige Tage später war ich mit der Aufgabe fertig, aber bei der Begutachtung durch Fachkollegen war ich niedergeschlagen, als ich erfuhr, dass ich es besser hätte machen können und dass das, was ich produzierte, Müll war.Ich habe gelernt, wie man lexikalisches Parsen durchführt, nur um zu beweisen, dass ich kein Idiot bin, aber sagen wir einfach, dass der Peer-Review-Prozess scheiße war.Ich brauchte keine leitende Person, die auf meinen Fehlern herumtanzte, ich brauchte einen Mentor, und daran habe ich mich jedes Mal erinnert, wenn ich ein Peer-Review durchgeführt habe.

Ich mag Peer-Reviews, wenn wir die Egos an der Tür überprüfen.(Dazu gehört auch meine!) Die Zeit auf dieser Welt ist begrenzt und man kann nur so viel lernen und tun.Durch ein gutes Peer-Review können Sie Ihr Wissen erweitern und in kürzerer Zeit mehr erledigen.Die Probleme entstehen, wenn die Dinge zu einer übermäßig analen Syntaxprüfung führen.

Aus diesem Grund habe ich ein paar Regeln.Ich bewerte nichts, was wir automatisieren können.Führen Sie eine Rechtschreibprüfung und eine Codeverschönerung durch.Wenn Ihnen so etwas wie FXCop zur Verfügung steht, führen Sie es aus, tun Sie, was es sagt, oder haben Sie einen verdammt guten Grund, warum Sie es nicht haben.Dann können wir uns ansehen, wie der Code zusammengesetzt ist, wie er funktioniert und was wir tun können, um ihn zu verbessern.Auf diese Weise erhalten Sie eine andere Perspektive darauf, wie ein Problem gelöst werden kann und warum jemand so denkt.Manchmal ist der andere Weg nicht wirklich besser, manchmal ist die neue Lösung fantastisch und etwas, das Sie für den Rest Ihres Programmierlebens verwenden werden.Sobald die Überprüfung abgeschlossen ist, ist das alles, ich verwende sie nicht als Beispiel gegen Sie.Es liegt an Ihnen, daraus zu lernen, was Sie wollen.Ich werde nicht durch Angst oder Drohungen zurechtkommen, Sie sind ein kluger Mensch und ich werde zulassen, dass Sie es zeigen.

Answer 2

Wir versuchen sicherzustellen, dass kein Code in Produktion geht, ohne ihn mindestens noch einmal durch ein paar Augen gesehen zu haben.
Normalerweise bedeutet das, dass wir Code überprüfen.Wir versuchen, es im Team zur Gewohnheit zu machen, dass Überprüfungen ein fester Bestandteil des Codeschreibens sind.Sie schreiben es und fragen dann jemanden nach seiner Meinung.
Außerdem versuchen wir bei Projekten, bei denen wir genügend Leute zur Verfügung haben (wenn die Aufgaben die richtige Größe haben), die Programmierung zu paaren.
Ich muss sagen, dass wir hier definitiv einen Vorteil gesehen haben.Erstens ist es eine großartige Möglichkeit, junge Entwickler im Team zu betreuen. Wenn Sie ihren Code überprüfen, können Sie ihnen zeigen, was besser gemacht werden kann, und wenn sie mit ihnen zusammenarbeiten, können sie sehen, wie man Dinge besser macht und erfahrene Leute Denken Sie darüber nach, wie Sie die IDE besser nutzen können.
Außerdem hält es das gesamte Team auf dem Laufenden, wenn es darum geht, zu wissen, wie der Code aussieht.
Und darüber hinaus erhöht es einfach die Freude und die persönliche Entwicklung aller – ein Team, das in der Lage ist, über Code zu sprechen und nachzudenken, ist ein besseres Team, ein Team, das ständig lernt und sich teilt.

Einige Dinge, auf die Sie achten sollten:

• Stellen Sie sicher, dass die Senioren beim Pairing auch die Junioren programmieren lassen
• Lassen Sie nicht zu, dass sich Leute bei kleinen Aufgaben paaren, das ist normalerweise Zeitverschwendung
• Beobachten Sie, wie Paare miteinander auskommen (zwingen Sie ein Paar nicht zusammen)
• Denken Sie daran, die Paare von Zeit zu Zeit neu zu mischen
• Lassen Sie nicht zu, dass Bewertungen mit Ihrem Ego in Konflikt geraten – lassen Sie nicht zu, dass andere andere unterdrücken

Answer 3

Peer-Review sollte sein OBLIGATORISCH.

Sie können zahlreiche Artikel und Bücher lesen und finden, in denen unterschiedliche Herangehensweisen in Teams unterschiedlicher Größe erörtert werden, Sie scheinen jedoch nach Erfahrungen zu fragen.

Ich persönlich bin der Meinung, dass Peer-Reviews Spaß machen sollten.Essen wird bereitgestellt und die Atmosphäre bleibt gemütlich.Es sollte wirklich als eine Zeit betrachtet werden, in der Entwickler/Programmierer voneinander lernen können, und nicht als eine Gelegenheit, zu urteilen (und wir alle wissen, dass jeder Programmierer mit einem angeborenen Urteilsgen geboren zu sein scheint).Ich habe es immer geschätzt oder dabei geholfen, Bewertungen so zu organisieren, dass sie 1/3 oder 1/4 der Zeit offen waren.Damit meine ich, wenn die Gruppe zusammenkommt und eine Person ein Projekt vorstellt, an dem sie arbeitet oder das sie sogar überprüft, das nicht einmal mit dem aktuellen Projekt zusammenhängt (ich weiß, dass das mit Fristen schwierig ist, aber versuchen Sie es).

Kreative kommen in der Regel zusammen, um Gemälde, Designs und Künstler, die sie gerade interessieren, auszustellen und so die Inspiration zu fördern.Realistisch gesehen sollte Inspiration das Leitkonzept sein, das Sie in einer Rezension fördern möchten.Zweitens bemerken die Leute ganz natürlich Dinge, die ihre Entwicklerkollegen tun, die ihnen vorher NICHT aufgefallen sind.„Oh wow, Sie haben das also in einer einzigen Codezeile geschafft?Cool." Die Entwickler inspirieren und motivieren darüber, was sie tun, woran sie arbeiten und wie sie vorgehen, wird sich mehr auszahlen, als die Peer -Review zu verwenden, um die Hackordnung und den Rang aufzubauen.

Abschließend kommt der eigentliche „Rezensions“-Teil, der jedoch eine unvermeidliche Tatsache ist.Ihre besseren Entwickler werden schlechten Code sehen und nach genügend Überprüfungen ist es für den schlechten Programmierer an der Zeit, entweder einen Schritt weiter zu gehen oder ihn zu vergessen.

Wenn man die Dinge positiv und organisiert hält, ist es normalerweise eine tolle Erfahrung.

Ich habe fast vergessen, auf die Paarprogrammierung einzugehen.Dies ist schwieriger einzurichten.Offensichtlich können nicht zwei Ihrer schwächeren Programmierer zusammenarbeiten, sonst können Sie genauso gut eine Million Affen mit einer Million Schreibmaschinen arrangieren.Versuchen Sie, eine stärkere Person mit einer schwächeren Person zusammenzubringen, und bieten Sie beiden privat Anreize.Jemand, der schwächer ist, sollte wissen, dass Verbesserungen belohnt werden könnten (wenn er einen solchen Anreiz benötigt), und der stärkere Programmierer sollte wissen, dass echte Führungskräfte als gute Mentoren beginnen.Stellen Sie jedoch sicher, dass der schwächere Entwickler tippt.Nicht umgekehrt, sonst wird es zu einer Präsentation und „gähnen„Jemand könnte durch die Erfahrung nichts gewinnen.

Answer 4

Ich habe eine Reihe von Agile-Coachings durchgeführt, und um den Menschen dabei zu helfen, das „Stigma“ der Paarprogrammierung zu überwinden, nennen wir es „Echtzeit-Code- und Design-Review“.Die Leute scheinen das Konzept besser zu verstehen, wenn Sie es so ausdrücken.

Answer 5

Die einzige direkt verwandte Erfahrung, die ich mit beiden habe, sind Peer-Design-Reviews (vor langer Zeit).Und sie waren scheiße.Wenn man die Literatur liest, wird deutlich, dass sie gegen mehrere Regeln guter Rezensionen verstoßen haben (Leute angreifen, sich auf die Rechtschreibung konzentrieren, keine klaren Ergebnisse erzielen usw.).usw.), aber das war alles, was wir wussten.

ABER Seitdem war ich an zahlreichen Offline-Codeüberprüfungen beteiligt.

Abhängig vom Projekt wurden sie entweder vor dem Einchecken in die „Live“-Filiale oder zu einem zufälligen Zeitpunkt danach beauftragt.Bei drei von vier Projekten wurden sie angenommen, zunächst zwar als notwendiges Übel, später aber als wertvoller Input.

Der Vorteil einer Arbeitsüberprüfung sollte darin bestehen, dass alle besseren Code schreiben und selbst die besten Programmierer betreut werden (seien Sie ehrlich, schreiben Ihre Top-Programmierer tatsächlich lesbaren Code?). Sobald Sie weniger erfahrene Mitarbeiter davon überzeugen können, zu sagen, dass dies nicht der Fall ist etwas verstehen - du bist weg.Einige der Spitzenreiter werden schnaufen und schnaufen, aber die wirklich Besten werden darüber nachdenken, was sie geschrieben haben, und tatsächlich Variablennamen oder Layout ändern – und vielleicht sogar einen Kommentar hinzufügen.

Das vierte Projekt verwendet ein aufgezwungenes Schema zur Überprüfung „zu einem zufälligen Zeitpunkt“, und die technischen Leiter wurden noch nicht einbezogen (kaputtes Team?)

---

Bei den beiden von Ihnen beschriebenen Praktiken handelt es sich um formale Ansätze.Sie funktionieren nicht bei allen Persönlichkeiten und Gruppen gut.

Probieren Sie etwas aus, von dem Sie glauben, dass Ihr Team es tatsächlich schaffen kann, und prüfen Sie dann, ob es verbessert werden kann.

Sobald Sie Ihren Code erst einmal im Blick haben, werden Sie nicht mehr zurückblicken wollen

Answer 6

• Ja, unser Unternehmen nutzt Peer-Code-Reviews.Wir führen sie als Over-The-Shoulder-Reviews durch und laden die Tester des Teams ein, an der Besprechung teilzunehmen, um ein besseres Verständnis der Änderungen zu erlangen.

• Die Codeüberprüfung bietet eindeutige Vorteile, wie mehrere Studien belegen konnten.Für unser Unternehmen war es offensichtlich, dass die Codequalität zunahm, da die Anzahl der Supportanrufe abnahm und auch die Anzahl der gemeldeten Fehler abnahm.NOTIZ:Einige der hier erzielten Vorteile waren das Ergebnis der Implementierung von Scrum und des Verzichts auf Waterfall.Mehr zu Scrum weiter unten.

• Die Vorteile der Codeüberprüfung können in einem stabileren Produkt und besser wartbarem Code bestehen, da sie auf Struktur- und Codierungsstandards angewendet werden, und es ermöglicht Entwicklern, sich mehr auf neue Funktionen zu konzentrieren, anstatt Fehler und andere Produktionsprobleme zu „bekämpfen“.Es gibt wirklich keine Nachteile, wenn Codeüberprüfungen „richtig“ durchgeführt werden.Mehr zum „richtigen Weg“ weiter unten.

• Zu den Hürden, die es bei der Implementierung von Codeüberprüfungen zu überwinden gilt, gehören die Vorstellung, dass der „große Bruder“ mich beobachtet, und die Vorstellung, dass kein perfekter Code Folter und Schmerz bedeutet.Manchmal ist es schwierig, Entwickler dazu zu bringen, einander zu vertrauen, insbesondere wenn es darum geht, die „Hackordnung“ oder die „Heiliger als du“-Haltung einzuhalten und deine harte Arbeit unter die Lupe zu nehmen.Vertrauen ist der Schlüssel zur Lösung dieser Probleme.Ein Entwickler muss darauf vertrauen können, dass er nicht von Kollegen oder dem Management für Fehler im Code bestraft wird.Es passiert jedem.Notieren Sie sich das Problem, lösen Sie es und fahren Sie fort.

GedrängeEiner der Vorteile der Scrum-Methodik besteht darin, dass der Entwicklungszyklus („Sprint“) kurz ist.Der Zeitrahmen des „Sprints“ richtet sich danach, was für Ihr Unternehmen am besten funktioniert, und erfordert einige Versuche und Irrtümer, sollte jedoch nicht länger als vierwöchige Iterationen dauern.Der Vorteil besteht darin, dass die Entwickler täglich kommunizieren und Probleme frühzeitig im Projekt kommunizieren müssen.Dies wurde ursprünglich von unserer Entwicklungsabteilung übernommen und hat sich auf alle Bereiche unseres Unternehmens ausgeweitet, da die Vorteile von Scrum weitreichend sind.Weitere Informationen finden Sie unter: http://en.wikipedia.org/wiki/SCRUM oder http://www.scrumalliance.org/ .Da die Entwicklungsiterationen kleiner sind, überprüft der Codeüberprüfungsprozess kleinere Codeteile, wodurch die Wahrscheinlichkeit höher ist, dass bei der Überprüfung Probleme gefunden werden, als bei formellen Überprüfungen über Stunden oder Tage.

"Richtiger Weg"Codeüberprüfungen, die „richtig“ durchgeführt werden, sind völlig subjektiv.Ich persönlich glaube jedoch, dass es sich um informelle, über die Schulter gehende Bewertungen handeln sollte.Alle Teilnehmer einer Überprüfung sollten vermeiden, die Person persönlich anzugreifen, die mit Aussagen wie „Warum haben Sie es so gemacht?“ oder "Was hast du gedacht?" usw.Diese Art von Kommentaren mindert das Vertrauen zwischen Kollegen und führt zu Feindseligkeit und stundenlangem Streiten über die beste/richtige Art und Weise, eine Lösung zu programmieren.Bedenken Sie, dass Entwickler nicht genau gleich denken oder programmieren und es viele Lösungen für ein Problem gibt.
Nur eine kleine Klarstellung zu Over-the-Shoulder-Rezensionen;Diese können per Remote-Desktop-Freigabe (wählen Sie hier die Variante) oder persönlich durchgeführt werden.Sie sollten jedoch nicht nur den Entwicklern vorbehalten sein.Normalerweise laden wir unser gesamtes Scrum-Team ein, das aus zwei Entwicklern pro Team, einem Tester, einer Dokumentationsperson und einem Produktbesitzer besteht.Alle Nicht-Entwickler sind da, um ein besseres Verständnis für die vorgenommenen Änderungen oder neuen Funktionen zu erlangen.Es steht ihnen frei, Fragen zu stellen oder Beiträge zu leisten, sie dürfen jedoch keine Codierungsentscheidungen treffen oder Kommentare abgeben.Dies hat sich als effektiv erwiesen, da bestimmte Fragen gestellt werden, die möglicherweise die Richtung des Projekts ändern, da den anfänglichen Anforderungen möglicherweise ein Szenario entgangen ist, aber genau darum geht es bei Agilität: Veränderung.

AnregungIch würde dringend empfehlen, Scrum- und Code-Reviews zu recherchieren, bevor man sie in Auftrag gibt.Erstellen Sie für jeden die Grundregeln und implementieren Sie sie als Teil Ihrer Kultur, um ein qualitativ besseres Produkt zu erzielen.Es muss Teil Ihrer Kultur werden, damit es Teil eines natürlichen Prozesses ist und auf allen Ebenen integriert wird, da es einen Paradigmenwechsel von schlechter Qualität, verpassten Fristen und Frustration hin zu Produkten mit besserer Qualität, weniger Frustration und pünktlicheren Lieferungen darstellt .

Answer 7

Eine vergleichende Analyse nach dem Wechsel von der Paarprogrammierung zu PR-Bewertungen auf Github.

Der Schwerpunkt liegt darauf, Schritt für Schritt aufzulisten, was unsere Teams jetzt im PR-Überprüfungsprozess verfolgen.

„Codeüberprüfungen vs. Paarprogrammierung“ https://blog.mavenhive.in/pair-programming-vs-code-reviews-79f0f1bf926