Gibt es Codeüberprüfungen in OpenSource-Projekten? Wenn ja, welche Tools werden dazu verwendet?

Ich weiß, dass es in der kommerziellen Entwicklung einen großen Schub für Codeüberprüfungen gibt. Werden Code-Reviews jedoch in Open Source-Software verwendet oder basieren sie auf Vertrauen? Wenn ja, wie werden sie dann durchgeführt? [Handelt es sich um ein verzögertes Commit, eine "Pre-Commit-Umgebung", gibt es ein Tool, mit dem der Patch an einen anderen Entwickler gesendet werden kann]?

Gibt es Projekte, die Codeüberprüfungen verwenden?

Nach meinem Verständnis basiert der Linux-Kernel hauptsächlich auf dem Vertrauen des Committers. MySQL basierte auf der Zustimmung des Hauptautors und den Auswirkungen auf die Leistung.

Fast alle Open Source-Projekte verwenden eine Art Gatekeeper-Workflow, bei dem eine Person oder eine Gruppe von Personen alle Änderungen abzeichnen muss, um in den offiziellen Build zu gelangen. Einige größere Projekte, wie der Linux-Kernel, verfügen über mehrere Gatekeeper. Sie senden eine Änderung an jemanden, der einen Bereich eines Subsystems verwaltet, er sendet seine Änderungen an jemanden, der ein gesamtes Subsystem verwaltet, und er sendet seine Änderungen an Linus Torvalds, der den Code manchmal selbst überprüft oder manchmal seinen Leutnants vertraut. Diese Bewertungen haben normalerweise keine formale Struktur. Es ist nur jemand, der den Code überprüft, bevor er zusammengeführt wird.

Ein gutes Beispiel für Werkzeuge finden Sie im Pull-Request-Mechanismus auf Github. Sie stellen eine Pull-Anfrage, und auf einer Webseite, die dieser Pull-Anfrage gewidmet ist, geben die Leute Kommentare ab, und der Autor nimmt Änderungen vor, bis sie gut genug sind, um akzeptiert zu werden. Andere Gatekeeper verwenden einfach nur Git, um Patches von Mailinglisten anzuwenden oder Pull-Anfragen aus öffentlichen Repositories zusammenzuführen. Dies ist einer der Hauptgründe, warum DVCSes wie Git erfunden wurden.

Open-Source-Projekte haben häufig (und sollten, wenn nicht) klar veröffentlichte "Community-Richtlinien", die häufig eine Beschreibung des Projektworkflows und der Art und Weise, wie Beiträge akzeptiert werden (und somit wie sie getestet werden), enthalten als der Prozess, um ein Core Committer zu werden.

Was die Codeüberprüfung betrifft, hängt dies wiederum von der Community ab, aber die Richtlinien werden häufig klargestellt. Einige beispielhafte Richtlinien für Beiträge von Nicht-Committern reichen von "Arbeitscode-Gewinnen" bis zu "Beiträgen müssen eine vollständige Testabdeckung und Dokumentation aufweisen, wobei Tests gleichzeitig mit dem Code festgeschrieben werden" und alles dazwischen. Unabhängig von diesen Richtlinien besteht die einzige implizite Richtlinie darin, dass die Hauptverpflichteten alle Beiträge von Nichtverpflichteten überprüfen, bevor sie akzeptiert werden.

Open-Source-Projekte mit Gruppen von Core-Committern haben häufig auch virtuelle Meetings oder spezielle Zeit, um Beiträge zu diskutieren, für die möglicherweise zusätzliche Augen erforderlich sind - ähnlich wie beim SE-Prozess, bei dem Benutzer mit einem bestimmten Ruf mehrere enge Abstimmungen durchführen, bevor eine Frage geschlossen wird. und die Diskussion fragwürdiger Dinge per Meta oder Chat.

Hier sind einige kurze Links zu einigen Beispiel-Community-Dokumenten für Projekte, die ich am besten kenne. Dort finden Sie Antworten auf Ihre Fragen zu diesen Projekten (Sie werden bald ein Thema bemerken):

• Projekt Blacklight Community-Prinzipien
• Richtlinien für den Beitrag zum DSpace-Code
• Technischer Leitfaden für Apache-Mitwirkende

Größere OSS-Projekte werden eine Reihe von Core Committern haben. Ich denke, sie sind de facto die "Code-Reviewer".

Da OSS-Code von Natur aus für alle offen ist, wird der Code, den Sie schreiben, wahrscheinlich viel mehr diskutiert. Dies kann zwar nicht in Form von formalen Codeüberprüfungen erfolgen, Sie werden jedoch mit Sicherheit feststellen, ob Ihr Code für ein bestimmtes OSS-Projekt nicht auf dem neuesten Stand ist.