Sollten sich meine Kollegen gegenseitig den Code aus dem Versionsverwaltungssystem überprüfen?

Das ist meine Geschichte: Einer meiner Kollegen überprüft den gesamten Code, der im Revisionssystem gehostet wird. Ich spreche nicht von einer angemessenen Überprüfung von Änderungen an Teilen, zu denen er gehört. Er beobachtet den Code Datei für Datei, Zeile für Zeile. Jede neue Datei und jede geänderte. Ich fühle mich wie ausspioniert!

Ich vermute, wenn Code bereits zur Steuerung des Systems gehostet wurde, sollten Sie ihm zumindest als funktionsfähig vertrauen. Meine Frage ist, vielleicht bin ich einfach zu paranoisch und es ist gut, sich gegenseitig den Code zu überprüfen?

PS: Wir sind ein Team von nur drei Entwicklern, und ich befürchte, wenn mehr von uns sein werden, hat der Kollege einfach keine Zeit, den gesamten Code zu überprüfen, den wir schreiben werden.

Ich würde Ja sagen!

Zwei schnelle Gründe dafür:

1) Wenn Code in Produktion ist, können Sie nicht davon ausgehen, dass er korrekt ist. Jede Änderung an anderer Stelle im System kann zu Fehlern führen. Ich denke, es ist sehr wichtig, dass der Code regelmäßig überprüft wird. Auf diese Weise wird das Refactoring regelmäßig durchgeführt, wobei der Code sauber und "korrekter" bleibt (aktuell ist wahrscheinlich besser).

2) Das Lesen von Code ist eine sehr wichtige Fähigkeit, wenn Sie Programmierer werden möchten. Und eine Fähigkeit, an der Sie arbeiten müssen. Für jeden Programmierer, der mit der Arbeit an einer vorhandenen Codebasis beginnt, gibt es eine steile Lernkurve, wenn er nicht daran gewöhnt ist, den Code anderer zu lesen, um zu versuchen, auf dem neuesten Stand zu bleiben.

Ich denke nicht, dass Sie sich ausspioniert fühlen sollten. Akzeptiere jede Kritik, die dir jemand gibt (wenn sie natürlich gültig ist). Und zögern Sie nicht, anderen Menschen GÜLTIGE Kritik zu geben. So lernen wir. Sobald wir aufhören zu lernen (oder aufhören wollen), gibt es große Probleme.

Wenn dieser Kollege ein gutes und konstruktives Feedback gibt, ist dies eine fantastische Sache und Sie sollten es sehr schätzen.

Diese WILL fangen Fehler , die Sie nicht gedacht , wenn es zu schreiben. Dies WILL führen , dass Sie besseren Code zu schreiben , weil Sie wissen , dass andere es sehen.

Es wäre gesund, wenn das gesamte Team anstelle einer Person Codeüberprüfungen durchführen würde. Im Idealfall lädt jeder jemanden ein, seinen Code nach Fertigstellung zu überprüfen. Es ist hilfreich, es informell zu halten (Manager fernhalten) und sich vom Prüfer über seine Ergebnisse informieren zu lassen. Im Idealfall gibt der Prüfer nur Feedback und nimmt keine Codeänderungen vor. Natürlich können Sie ein wenig darauf koppeln.

Es ist wirklich hilfreich, Codierungsstandards zu haben, um zu vermeiden, dass Überprüfungsdiskussionen ständig über Leerzeichen und Codestil geführt werden. Eine statische Code-Analyse auf einem Build-Computer kann hilfreich sein, um auch einige Diskussionen auszuschließen.

In Bezug auf den Zeitaspekt lautet die Theorie, dass Sie dadurch Zeit sparen. Je später Fehler festgestellt werden, desto teurer werden sie. Peer-Code-Überprüfung kann einige Probleme auffangen.

Ihr Kollege klingt wie ein fleißiger Entwickler, Sie sollten seinem Beispiel folgen.

Ich beobachte unser Versionskontrollsystem auf ähnliche Weise. Unsere Codebasis ist zu groß, um jede Zeile zu sehen, aber ich versuche, ein gutes Gefühl für die meisten Änderungen zu bekommen. Ich achte auch auf Checkins, die am wahrscheinlichsten Nebenwirkungen haben, und überprüfe diese Zeile für Zeile. Für die minimale Zeit, die ich damit verbringe, ist die Auszahlung enorm. (Beachten Sie auch: Ich bin nicht der einzige Entwickler in unserem Team mit dieser Angewohnheit.)

Diese Art der Überprüfung neigt dazu, wöchentlich Fehler zu erkennen oder Diskussionen aufzurufen. Das spart Zeit bei der Qualitätssicherung. Die Diskussionen reichen von Best Practices über das Design von Algorithmen bis hin zu mehr. Der Schlüssel an dieser Front ist, dass jeder es als konstruktiv ansieht.

Persönlich gibt es mir auch ein besseres Verständnis dafür, was in anderen Teilen der Codebasis vor sich geht, die ich nicht regelmäßig berühre. Wenn andere Hilfe brauchen, kann ich schneller einspringen. Wenn neue Ideen auftauchen, kann ich sie auch früher nutzen.

Sie fühlen es als ausspioniert (!)? Aber aus der Sicht Ihres Kollegen würde ich sagen, dass er die richtigen Dinge für seine berufliche Entwicklung tut. Lesen Sie den Code anderer und finden Sie heraus, wie sie die Logik entwerfen und implementieren. Dies wird Ihnen viel bringen!

IMHO, wenn jemand auf etwas hinweist, das in Ihrem Code nicht stimmt, müssen Sie es akzeptieren und von ihm lernen, wie man einen guten Code schreibt

Während 6-7 Monaten tat ich das gleiche. Nicht um auszuspionieren, sondern um die Qualität zu kontrollieren. Jede einzelne Codezeile für eine aktiv entwickelte Anwendung, die dem zentralen Repository zugeordnet ist, 2 Hauptsprachen, einige andere Sprachen, riesige Makefiles für 4 Plattformen.

Es ist eine sehr schlechte Praxis . Eines Tages fand ich heraus, dass ich aufgrund der Robustheit nicht alles erfassen kann. Das andere Argument dagegen ist die Subjektivität - jeder kann sich irren.

Es ist besser, wenn Entwickler die Codes des anderen überprüfen und jemand Erfahrung hat, um endgültige Entscheidungen zu treffen und Anweisungen zu definieren.

Codeüberprüfungen innerhalb eines Teams (unter Verwendung von Fischaugen , Tiegel oder anderen Werkzeugen) sind äußerst wichtig und nützlich. Das einzig Bessere ist die direkte Paarprogrammierung, um sicherzustellen, dass der Code, der beim ersten Mal in das System gelangt, gut durchdacht ist und das Gehirn von mehr als einer Person durchlaufen hat.

Das ist einmal in meinem Team passiert. Leider kam es zu einem Schuldspiel. Die Leute warteten ständig darauf, dass andere den Code eincheckten, und versuchten immer, etwas Falsches darin zu finden, und spielten die ganze Zeit das Schuldspiel.

Ich hoffe, Sie haben ein reiferes Publikum.

Dies ist in der Industrie Standard. Die Unternehmen, bei denen ich gearbeitet habe, haben sehr strenge Richtlinien für die Codeüberprüfung. Man würde Sie nicht einmal festschreiben lassen, wenn der Code nicht überprüft worden wäre.

Sei nicht beleidigt oder fühle dich beobachtet. Betrachten Sie es als Sicherheitsnetz und Lernerfahrung.

Bei einem früheren Job hat der leitende Entwickler alle Check-Ins beobachtet und überprüft, und ich habe häufig ein hervorragendes Feedback erhalten, das mir geholfen hat, ein besserer Entwickler zu werden.

Bei meinem aktuellen Job schaue ich mir viele Check-Ins an und vor drei Tagen habe ich einen Fehler gefunden und den Entwickler benachrichtigt.

Diese Praxis wird auf jeden Fall Fehler auffangen und Ihr gesamtes Team verbessern, wenn Sie sie annehmen.