Müssen Ihre besten Programmierer den Code aller anderen in die Versionsverwaltung einchecken?

Einer der Unterschiede zwischen svn und git ist die Möglichkeit, den Zugriff auf das Repository zu steuern. Es ist schwierig, die beiden zu vergleichen, da es unterschiedliche Perspektiven gibt, wer überhaupt Änderungen vornehmen darf!

Bei dieser Frage geht es darum, git als zentrales Repository für ein Team in einem Unternehmen zu verwenden. Angenommen, die Mitglieder des Teams sind unterschiedlich qualifiziert, so wie es in den meisten Unternehmen der Fall ist.

Git scheint davon auszugehen, dass nur Ihren besten (produktivsten, erfahrensten) Programmierern vertraut wird, dass sie Code einchecken. In diesem Fall nehmen Sie sich die Zeit, Code zu schreiben, um den Code anderer Personen zu überprüfen und einzuchecken. Lohnt sich das? Ich möchte diese Frage wirklich darauf konzentrieren, wie die Zeit Ihres besten Programmierers am besten genutzt wird , und nicht auf die besten Methoden zur Versionskontrolle im Allgemeinen . Eine Konsequenz könnte sein, dass gute Programmierer aufhören, wenn ein wesentlicher Teil ihrer Aufgabe darin besteht, den Code anderer Leute zu überprüfen? Ich denke, beide Fragen beschränken sich auf Folgendes: Lohnt sich die Überprüfung für die Produktivität?

Da es aus Ihrer Frage nicht klar hervorgeht, möchte ich nur darauf hinweisen, dass ein Gatekeeper-Workflow mit git keineswegs erforderlich ist. Es ist beliebt bei Open Source-Projekten, da es eine große Anzahl nicht vertrauenswürdiger Mitwirkender gibt, aber innerhalb einer Organisation nicht so sinnvoll ist. Sie haben die Möglichkeit, jedem Push-Zugriff zu gewähren, wenn Sie möchten.

Was die Leute in dieser Analyse vernachlässigen, ist, dass gute Programmierer ohnehin viel Zeit damit verbringen, sich mit dem kaputten Code anderer Programmierer auseinanderzusetzen. Wenn jeder Push - Zugriff hat, dann ist die Build wird gebrochen werden, und die besten Programmierer neigen dazu , diejenigen zu sein , häufig zu integrieren und die Schuldigen aufzuspüren , wenn die Dinge zu brechen.

Die Sache bei jedem, der Push-Zugriff hat, ist, dass wenn etwas kaputt geht, jeder, der zieht, einen kaputten Build erhält, bis das beleidigende Commit rückgängig gemacht oder behoben wird. Bei einem Gatekeeper-Workflow ist nur der Gatekeeper betroffen. Mit anderen Worten, Sie haben nur mit einem Ihrer besten Programmierer zu tun, anstatt mit allen.

Es könnte sich herausstellen, dass Ihre Codequalität ziemlich hoch ist und sich das Kosten-Nutzen-Verhältnis eines Gatekeepers immer noch nicht lohnt, vernachlässigen Sie jedoch nicht die bekannten Kosten. Nur weil Sie an diesen Produktivitätsverlust gewöhnt sind, bedeutet dies nicht, dass er nicht auftritt.

Vergessen Sie auch nicht, Hybridoptionen zu erkunden. Mit git ist es sehr einfach, ein Repository einzurichten, zu dem jeder pushen kann. Dann kann ein Gatekeeper wie ein leitender Entwickler, Tester oder sogar ein automatisierter Continuous Integration Server entscheiden, ob und wann eine Änderung es zu einem zweiten, stabileren Repository macht. Auf diese Weise können Sie das Beste aus beiden Welten erhalten.

Ich habe bei einem Job gearbeitet, bei dem das Einchecken nur auf Team-Leads beschränkt war (und Team-Leads ihren eigenen Code nicht einchecken konnten). Dies diente als unser Mechanismus zur Durchsetzung von Codeüberprüfungen, hauptsächlich aufgrund einer Reihe von Vorfällen, bei denen fehlerhafte Commits in die Codebasis gelangten, selbst bei durchsichtigen Eincheckvorgängen und statischen Analysen.

Einerseits hat es seinen Job gemacht. Eine Reihe von schlechten Commits wurden gefunden, bevor sie in die Codebasis gelangten (und sofort für etwa eine Woche vergessen, bis jemand über sie stolperte). Dies verursachte weniger Störungen in der Codebasis. Außerdem konnte ich einige Formatierungs- / Strukturierungselemente zurückschieben, bevor sie zu technischen Schulden wurden. Fange ein paar Käfer, bevor sie zu Käfern werden. Und es gab mir ein großartiges Gefühl dafür, was mein Team tat.

Andererseits hat es mich dazu gebracht, spontan in mörderische Wut zu geraten, als mein 3-Zeilen-Wechsel 4 Stunden in Anspruch nahm, weil ich einen anderen Lead ausfindig machen und sie dazu bringen musste, den Commit auszuführen. Es hat mich dazu gebracht, weit weniger Commits durchzuführen, als es sich für Best Practices gehört, und gelegentlich zu Problemen geführt, bei denen versucht wurde, Änderungen an dem Entwickler, der sie ausgeführt hat, nachzuverfolgen.

Ich würde es im Allgemeinen nur in den dringendsten Umgebungen empfehlen. Die Reviews und Commits zu machen war eigentlich gar nicht so schlecht. Es war jedoch ärgerlich, wenn mein eigener Prozess von den Launen anderer abhängig war. Wenn Sie Ihren Entwicklern beim Einchecken von Code nicht vertrauen können, holen Sie sich bessere Entwickler.

Jeder sollte in der Lage sein, sich zu verpflichten.

Wenn Sie Probleme mit der Behebung von Fehlern haben, ist die Versionsverwaltungsrichtlinie nicht korrekt. Es sind die Entwickler, die nicht sicherstellen, dass das, was sie begehen, funktioniert. Sie müssen also klare Richtlinien definieren, was und wann zu begehen ist.

Eine andere großartige Sache heißt Unit-Tests;)

Es gibt jedoch eine Alternative.

a) Wenn Sie die verteilte Versionskontrolle verwenden, können Sie ein Haupt-Repo erstellen, an das nur Pull-Anforderungen gestellt werden können. Auf diese Weise können alle Entwickler ihren eigenen Code versionieren, während Sie die Kontrolle über den Hauptzweig haben.

b) In Subversion und ähnlichem können Sie Zweige verwenden, in denen jeder Entwickler Patches erstellen muss, um sie in den Hauptzweig zu bringen.

Sie sollten sich Projekte wie Gerrit ansehen, mit denen alle Entwickler ihren Code in den "Review" -Zweig verschieben können, und sobald Sie als Senior / Lead-Entwickler mit diesen Änderungen zufrieden sind, können Sie sie in Master / Release verschieben.

Wenn sie nicht glücklich sind, können sie Kommentare neben einer Codezeile hinterlassen, nach einem aktualisierten Patch fragen usw.

Auf diese Weise kann jeder, dessen Änderung noch aussteht, sie herausholen, sobald sie fertig ist, und nur qualifizierte Mitarbeiter (mit den richtigen +2 Berechtigungen in Gerrit) können diesen Code zum Testen und später zur Produktion senden.

Nein, Ihr bestes Talent wird schlecht eingesetzt. Stellen Sie sich vor, ein Verlag nimmt die erfolgreichsten Autoren und veranlasst sie zum Redigieren. schlechte Idee.

Es sollte Codeüberprüfungen geben, aber das bedeutet nicht, dass es immer ein Sr. ist, der den Code eines jr überprüft. Schließlich sollte von jedem im Team erwartet werden, dass er das Niveau erreicht, auf dem er mit minimaler Anleitung Code beisteuern kann. Sie durchlaufen die drei Vertrauensebenen:

1. Keine - Ich möchte jede Codezeile sehen, bevor Sie sie einchecken.
2. Einige - Lassen Sie mich wissen, was Sie tun, und ich werde Rückmeldung geben
3. Meistens erledigen Sie Ihre Arbeit und bitten Sie nur bei Bedarf um Hilfe.

Vorteile, Ihr Talent freizusetzen:

• Fokus auf Design
• Beteiligung an der Einrichtung von Kodierungsstandards und Durchsetzungsstrategien (ohne alles manuell selbst zu tun)
• Bewältigen Sie die schwierigen Codierungsprobleme
• Mentoring anbieten (ohne jede Codezeile zu genehmigen)

Es gibt Entwickler, die an einem Verwaltungspfad interessiert sind und es vielleicht vorziehen, nicht den ganzen Tag lang zu programmieren. Lass die anderen in Ruhe.

Lohnt sich die Überprüfung für die Produktivität?

Es hängt von der "Balance" des Teams und davon ab, wie Bewertungen erstellt werden. Beides ist eine Frage des Managements und der Teamarbeit. Kein technologischer Zauber der Versionskontrolle (zentralisiert oder verteilt) kann einen wesentlichen Einfluss darauf haben.

Wenn dies falsch gemacht wird, werden alle Vorteile der Überprüfung durch Produktivitätsverluste zunichte gemacht. Die Antwort ist jedoch, nicht die Idee von Bewertungen fallen zu lassen, sondern herauszufinden, wie man es richtig macht .

Ein Ansatz, um herauszufinden, ob Ihre Überprüfungen in Ordnung sind, besteht darin, das Fehlerverfolgungstool zu verwenden , um die für Überprüfungen aufgewendete Zeit zu verfolgen (einige Codeüberprüfungstools ermöglichen dies auch). Wenn Sie feststellen, dass Bewertungen viel Zeit in Anspruch nehmen, investieren Sie einige Mühe, um die Gründe und Möglichkeiten zu finden, die Dinge zu verbessern. Es würde auch nicht schaden, regelmäßig 1: 1 mit Teammitgliedern zu haben, um potenzielle Probleme mit Codeüberprüfungen zu entdecken.

Wenn "beste" Programmierer im Team gezwungen sind, Stunden damit zu verbringen, durch unverständlichen Müll zu graben, der von beschissenen Programmierern produziert wird, besteht die Lösung darin, Scheißmacher zu feuern und nicht die VCS-Technologie in Anspruch zu nehmen.

• ^{In einem der letzten Projekte wurde ich beauftragt, Codeänderungen zu überprüfen, die von einem Teammitglied vorgenommen wurden, das ständig unterdurchschnittlich arbeitet. In einer Komponente dauerte es fast eine Stunde, nur Tests zu erstellen und auszuführen. Ich fing an, die Unterschiede zu lesen, und als ich eine nicht kompilierbare Änderung bemerkte, beendete ich einfach die Überprüfung, veröffentlichte die erforderlichen Kommentare und bat das Management, sicherzustellen, dass weitere Überprüfungsanfragen mit einer schriftlichen Bestätigung versehen werden, dass der Code kompiliert wird. Es gab seitdem keine "Überprüfungsanfragen" mehr und bald ging der Typ.}

Auf der anderen Seite machen Code-Reviews Spaß und sind lehrreich, wenn das Team einigermaßen ausgeglichen ist. In meinem vorherigen Projekt war eine 100% -ige Codeüberprüfung erforderlich, die weder viel Zeit in Anspruch nahm noch ablenkte. Es gab Fehler, die durch Überprüfung entdeckt wurden, und es gab Debatten über Codierungsstil und Designauswahl, aber das fühlte sich einfach ... normal an .

Wenn Codeänderungen für Tage ... Wochen blockiert werden, bevor Sie "aufgrund von Überprüfungen" zur Qualitätssicherung gelangen, ist es am unwahrscheinlichsten, dieses Problem zu lösen, wenn Sie sich mit VCS-Tricks befassen. Stattdessen sollte man sich besser darauf konzentrieren, Probleme bei der Organisation des Überprüfungsprozesses herauszufinden.

• <sup>- Oh Integration dieser Änderung wurde viel verzögert, weil Rezensent plötzlich krank wurde, was für ein Unglück.
  - Hallo! Hell-lo-oo, haben Sie jemals daran gedacht, Backup- Prüfer zu haben, die sich mit solchen Fällen befassen?</sup>

Ja. Aber nur, wenn es um verteilte Quellcodeverwaltung geht. Mit zentralisiert - es kommt darauf an.

Wenn es nur wenige Programmierer gibt, braucht es wenig Zeit. Sicherlich weniger als die Fixes, die später benötigt werden, um Fehler und technische Schulden zu beseitigen.

Wenn es sehr viele Programmierer gibt, können Sie die Aufgabe der eigentlichen Codeüberprüfung an Leutnants delegieren und den leitenden Entwickler (fast) unbestreitbar dazu bringen, ihre Änderungen zu übernehmen. Es funktioniert für den Linux-Kernel, ich glaube nicht, dass es größere Softwareprojekte gibt ...

Wenn das Projekt klein ist, wird der Lead schnell erkennen, wer guten Code gibt und wer schlechten Code produziert. Er wird schnell feststellen, dass J. Random guten Code schreibt, der nur auf Architekturentscheidungen überprüft werden muss, während der Praktikant schlechten Code schreibt, der vor dem Zusammenführen Zeile für Zeile überprüft werden muss. Das auf diese Weise erzeugte Feedback reduziert den Wartungsaufwand auf der ganzen Linie und gibt Erfahrungen aus erster Hand darüber, was der Praktikant tatsächlich lernt und in Unternehmen behalten sollte. Das Abrufen und Zusammenführen von Zweigen aus anderen gitRepos dauert buchstäblich ein (paar) Dutzend Sekunden. Normalerweise dauert es länger, die Titel von Commit-Nachrichten zu lesen. Nachdem ich also weiß, wem man vertrauen kann, dass er guten Code schreibt, ist das Zusammenführen des Codes anderer Leute kein Problem.

Die Codeüberprüfung erfordert nicht unbedingt die Aufmerksamkeit nur Ihrer besten Programmierer. IMO, es sollte eine informelle Sache sein. Nur eine zweite Meinung oder ein zweites Paar Augen auf ein Stück Code von einem Nicht-Anfänger, bevor es in die Produktion eingecheckt wird. Es hilft dabei, größere Versehen zu mindern und Menschen dabei zu helfen, besser als Handwerk zu programmieren, indem sie anderen Entwicklungsperspektiven ausgesetzt werden.

Eine Art weniger unangenehmes Paar-Programmier-Lite. Mit anderen Worten, es sollte nicht lange dauern und Sie sollten nicht stundenlang auf jemanden warten müssen. Alles in Ihrem Entwicklungsprozess, bei dem Menschen auf Dinge warten, ist Geldverschwendung und beeinträchtigt die Dynamik / Moral, IMO.

Wenn die Codeüberprüfung 99,5% der Fehler stoppen sollte, bevor sie überhaupt in Ihre Codebasis eingedrungen sind, gibt es keinen wirklichen Grund für eine ausgefeilte Versionskontrolle. Das heißt, Git ist anfangs einschüchternd, aber die grundlegende allgemeine Verwendung ist nicht so kompliziert und in hohem Maße konfigurierbar. Jeder verpflichtet sich. Alle, bis auf die unauffälligsten Neulinge, überprüfen, bis sie Fachkenntnisse in etwas beweisen.

Solange die eingereichten Änderungen von den "besten Programmierern" überprüft wurden, sollte es jedem gestattet sein, Code einzureichen. Die einzige Person, die in der Lage sein sollte, die Kontrolle über ein Repository zu erzwingen, ist der Release Engineer, sofern diese Person existiert.

Persönlich wäre ich sauer, wenn ich den Code anderer Leute einchecken müsste.

Einige Eingaben zu Ihrer Bearbeitung: Nein, das sollten sie nicht. Reviews sind ein notwendiges Übel, sie tun mehr Gutes als Böses und gute Programmierer werden dies zu schätzen wissen. Vielleicht widerstrebt es ihnen, an Reviews teilzunehmen, weil sie die Idee, dass weniger Programmierer ihren Code kritisieren, nicht mögen. Das ist einfach zu schade. Es ist weitaus wahrscheinlicher, dass sie aufhören, wenn die Codeline ständig fehlerhaft ist, und sie verbringen stattdessen ihre Zeit damit, nach den halbherzigen Einsendungen anderer Leute aufzuräumen.

Ja, eine Bewertung ist es wert. Ich bin nicht sicher, ob ein Produktivitätsverlust vorliegt, wenn der Überprüfungsprozess aus den folgenden Gründen verhältnismäßig ist:

• Es hält Programmierer ehrlich - wenn Sie wissen, dass es überprüft wird, werden die Leute weniger Abkürzungen nehmen
• Es hilft neuen Programmierern, von erfahreneren Programmierern zu lernen
• Es hilft, domänenspezifisches Wissen zu übertragen
• Review ist ein weiteres Tor, in dem Fehler und potenzielle Probleme gefunden und behoben werden können

Wenn nicht alle Programmierer die Quellcodeverwaltung verwenden können, verlieren sie die Möglichkeit, Änderungen nachzuverfolgen, Fehler rückgängig zu machen und einen vernünftigen Änderungsverlauf anzuzeigen. Ich bin mir nicht sicher, ob Sie jemals wollen würden, dass nur Ihre "besten" Programmierer bei git einchecken können.

Trotzdem halte ich es für vernünftig, dass Sie jemanden haben, der für bestimmte Schlüsselbranchen zuständig ist, beispielsweise für eine Veröffentlichungsbranche. In diesem Fall würde ich mir vorstellen, dass jeder das Git-Repository nutzen kann, aber nur bestimmte Personen in den Release-Zweig einsteigen. Ich bin mir nicht sicher, ob es eine Möglichkeit gibt, dies in git durchzusetzen, aber es sollte möglich sein, dies durch einen Prozess zu tun und nur zu überprüfen, dass noch niemand eingecheckt hat.

Das Zusammenführen in den Release-Zweig könnte von den "besten" Programmierern oder eher von kompetenten Leuten durchgeführt werden, nachdem eine ausreichende Überprüfung stattgefunden hat.

geben gute programmierer auf, wenn ein bedeutender teil ihrer aufgabe darin besteht, den code anderer zu überprüfen?

Wenn sie den Job nicht genießen und zu dieser Aktivität gezwungen sind, dann JA. Es ist sehr wahrscheinlich, dass es passiert. Als nächstes eine interessante Arbeit für einen guten Entwickler zu finden, ist heutzutage keine große Herausforderung mehr.

Müssen Ihre besten Programmierer den Code aller anderen in die Versionsverwaltung einchecken?

Definitiv nein. Es ist mit Sicherheit Zeitverschwendung, abgesehen von einer kritischen Logik, die in einem steinharten Zustand sein muss .

Nachwuchsentwickler oder erfahrene Entwickler sollten jedoch wahrscheinlich eine Probezeit für eine Codequalität haben , um auf der sicheren Seite zu sein und um sicherzustellen, dass ihr Code den Richtlinien für die Teamentwicklung folgt, zumindest für einige Wochen, bevor sie das Privileg erhalten, sich zu verpflichten.