Ich vermute, dass ich mich auf das falsche Problem konzentriere, daher werde ich zunächst beschreiben, was ich für das Problem halte, bevor ich die möglicherweise suboptimale Lösung vorstelle, die ich mir vorstelle.
Gegenwärtige Situation:
Gegenwärtig schreiben meine Mitarbeiter ihre Codeänderungen erst nach sehr langen Zeiträumen in großen Stücken durch, wobei sich die Änderungen über das gesamte Projekt erstrecken. Ich denke, das ist ein Fortschritt, denn vor kurzem haben sie einfach .zip-Archive auf einer Netzwerkfreigabe abgelegt. Dennoch ist das Zusammenführen ein Albtraum - und ehrlich gesagt habe ich genug davon. Und ich habe es auch satt zu reden, zu erklären und zu betteln. Das muss einfach aufhören - ohne dass ich ständig "der Böse" bin.
Meine Lösung:
Da es anscheinend kein Bewusstsein und / oder kein Interesse für die Probleme gibt und ich nicht damit rechnen kann, dass die Bemühungen länger als ein paar Tage dauern ... bitte, Stunden, ich möchte, dass der Subversion-Server das erledigt Gezeter.
Meine Frage:
Bin ich hier weit von der Basis entfernt oder sehe ich das falsche Problem? Es scheint, als würde mir etwas fehlen, und ich glaube, ich frage das Falsche, indem ich mir Werkzeuge anschaue, um mein Problem zu lösen.
Sollte ich nach einem Werkzeug suchen, um dieses Problem zu lösen, oder was sollte ich tun, um dies zu beheben?
quelle
Antworten:
Sie suchen nach einer technischen Lösung für ein menschliches Problem. Das geht selten.
Der Grund dafür ist, dass die Teammitglieder versuchen, die Regeln zu umgehen, wenn sie etwas nicht akzeptieren (noch die Auswirkungen verstehen), anstatt sie zu befolgen. Genau aus diesem Grund sollten Entwickler beispielsweise Stilregeln akzeptieren und verstehen, anstatt lediglich von einem Prüfer zur Einhaltung gezwungen zu werden.
Hier sind ein paar Ansätze, die ich entweder in der Vergangenheit verwendet habe oder im Hinterkopf habe, ohne tatsächlich die Möglichkeit zu haben, sie in der Praxis anzuwenden. Je nachdem, welche Position Sie in einem Team innehaben, treffen einige möglicherweise nicht auf Ihren Fall zu (wenn Sie ein Teamleiter mit ausgezeichnetem Ruf sind, haben Sie wahrscheinlich eine bessere Gelegenheit, Ihre Sichtweise durchzusetzen, als wenn Sie ein Student sind, der einen Abschluss hat) soeben für die Dauer Ihres Praktikums einem Team beigetreten).
Besprechen Sie das Problem mit Ihren Mitarbeitern und erläutern Sie die Konsequenzen großer Commits. Vielleicht verstehen sie einfach nicht, dass komplizierte Zusammenführungen eine direkte Folge seltener Commits sind, und kleine, häufige Commits machen Zusammenführungen (relativ) einfach.
Ich kannte viele Programmierer, die einfach davon überzeugt waren, dass Zusammenführungen immer kompliziert sind. Sie haben höchstens ein Commit pro Tag ausgeführt, es vermieden, leistungsstarke Tools wie das Diff und das automatische Zusammenführen von Visual Studio zu verwenden, und es gab eine schlechte Praxis beim manuellen Zusammenführen (es sei denn, "Take Mine" ohne weitere Diff-Inspektion ist eine gute Praxis). Für sie hatte dies nichts mit ihnen zu tun und war die Natur einer Verschmelzung.
Nennen Sie konkrete Beispiele für das, was in anderen Unternehmen geschieht (insbesondere für die, vor denen Ihre Mitarbeiter großen Respekt haben). Sie sind sich möglicherweise einfach nicht bewusst, dass es sich um ein Problem handelt, und sind davon überzeugt, dass ein Commit pro Tag maximal das ist, was jedes Team tut.
Einige Leute sind sich nicht bewusst, dass es Teams von 5 bis 10 Mitgliedern gibt, die bis zu 50 Pushs für die Produktion ausführen. Dies entspricht durchschnittlich 5 bis 10 Commits pro Tag und Person. Sie verstehen möglicherweise weder, wie es möglich ist, noch warum jemand es tun würde.
Mit gutem Beispiel vorangehen. Tu genug kleine Dinge selbst. Wenn möglich, halten Sie eine kurze Präsentation ab, in der Sie und Ihre Zusammenführungen über eine Woche lang nebeneinander dargestellt werden. Betonen Sie die eventuellen Fehler, die sie während der Zusammenführung gemacht haben, und vergleichen Sie sie mit der Anzahl der von Ihnen gemachten Fehler (die nahe bei Null liegen sollten).
Verwenden Sie gegebenenfalls die Technik „Ich habe es Ihnen gesagt“ . Wenn Sie sehen, dass Ihre Kollegen unter einer schmerzhaften Verschmelzung leiden, kommentieren Sie lautstark, dass kleine, häufige Eingaben Verschmelzungen (relativ) schmerzlos machen könnten.
Erklären Sie, dass es keine Mindestdauer für das Festschreiben gibt. Ein Commit kann sogar einer geringfügigen Änderung entsprechen, die in wenigen Sekunden vorgenommen wurde. Das Umbenennen einer Datei, das Entfernen eines veralteten Kommentars und das Korrigieren eines Tippfehlers sind Aufgaben, die sofort ausgeführt werden können.
Programmierer sollten nicht befürchten, ein kleines Commit auszuführen, sondern viele Änderungen in einem großen Commit zusammenfassen.
Arbeiten Sie gegebenenfalls mit Einzelpersonen statt mit einem Team. Wenn es eine Person gibt, die sich besonders weigert, häufige, kleine Verpflichtungen einzugehen, sprechen Sie mit dieser Person einzeln, um herauszufinden, warum sie dies ablehnt.
Möglicherweise geben sie absolut stichhaltige Gründe an, die Ihnen einen Hinweis darauf geben, was mit einem Team los ist. Einige Gründe, warum ich mich gehört habe:
„Mein Lehrer / Mentor hat mir gesagt , dass die beste Praxis ein pro Tag begehen zu tun ist.“ Es überrascht mich nicht, gegeben , was ich hatte von meinen Lehrern in der Schule zu hören .
"Meine Kollegen sagten mir, ich solle weniger Verpflichtungen eingehen." Das wurde mir auch in einigen Teams gesagt, und ich verstehe ihren Standpunkt. Wir hatten ein Protokoll, das praktisch mit meinen Verpflichtungen gefüllt war (nicht schwer zu tun, wenn vier Teamkollegen nicht einmal eine Verpflichtung pro Tag eingehen), was meine Kollegen frustrierte.
"Ich dachte, kleine Commits machen es schwierig, eine Revision zu finden." Irgendwie ein gültiger Punkt, selbst wenn das Team sich Mühe gibt, beschreibende Protokollnachrichten zu schreiben.
„Ich möchte nicht zu viel Speicherplatz auf unserem Versionskontrollserver verschwenden.“ Die Person versteht offensichtlich nicht, wie Commits gespeichert werden (und wie billig der Speicherplatz ist).
„Ich denke, ein Commit sollte einer bestimmten Aufgabe entsprechen.“ Angesichts der Tatsache, dass eine Aufgabe häufig einer Arbeit entspricht, die an einem Tag erledigt werden muss (z. B. in den Task-Boards von Visual Management), ist dies kein Zufall. Die Person sollte dann lernen, einen Unterschied zwischen einer Aufgabe in einem Rückstand (2 bis 8 Stunden Arbeit) und einer logisch isolierten Änderung zu machen, die durchgeführt werden sollte (einige Sekunden bis einige Stunden Arbeit). Dies hängt auch mit Punkt 5 zusammen.
Suchen Sie nach dem Grund, warum das Team nicht häufiger Commits durchführt. Sie werden von den Ergebnissen überrascht sein.
Kürzlich habe ich in einer anderen Antwort erwähnt, dass die Geschwindigkeit eines Commits von Bedeutung ist und sogar Hunderte von Millisekunden Entwickler dazu zwingen können, weniger häufig ein Commit durchzuführen .
Andere Gründe können sein:
Übermäßig komplizierte Regeln zum Schreiben einer Commit-Nachricht.
Die Regel, die den Entwickler zwingt, das Festschreiben mit einer Aufgabe aus einem Fehlerverfolgungssystem zu verknüpfen.
Die Angst, den Bau zu brechen.
Die Abneigung, mit dem Risiko eines sofortigen Abbruchs des Builds umzugehen: Wenn Sie am Freitagabend kurz vor der Abreise ein Commit ausführen, können Sie die Bearbeitung eines Abbruchs auf Montag verschieben.
Die Angst vor einer Fusion.
Stellen Sie fest, ob Entwickler verstehen, dass es noch weitere Vorteile gibt, die häufig zu nutzen sind . Beispielsweise ist eine Continuous Integration-Plattform ein großer Anreiz, häufige Commits durchzuführen , da damit genau bestimmt werden kann, wo die Regression eingeführt wurde .
Ich würde es vorziehen, wenn die CI-Plattform mir mitteilt, dass ich den Build in der Revision 5023 gebrochen habe, der aus einer Änderung in zwei Methoden in einer Datei besteht, die ich vor fünfzehn Minuten vorgenommen habe, und nicht in der Revision 5023, die aus Änderungen besteht, die vier Dutzend Dateien umfassen und darstellen 13 Stunden Arbeit.
quelle
Eine Organisation, für die ich in der Vergangenheit einen Vertrag abgeschlossen hatte, wollte dasselbe Problem lösen und fand eine ziemlich gute soziale Lösung: Entwickler haben keine eigenen Computer. Das Entwicklungsteam verfügt über Computer. Es kann jedoch von jeder Person verlangt werden, dass sie an einem bestimmten Tag an jedem Entwicklungscomputer arbeitet. Das Einchecken ist also die einzige Möglichkeit, um sicherzustellen, dass Sie weiter daran arbeiten können, was Sie gestern getan haben!
Das Management ging dann herum und setzte Änderungen auf Computern nach Stunden heimlich zurück, so dass alles, was nicht eingecheckt wurde, verloren ging. Diese "simulierten Computerausfälle" mussten nur einige Male auftreten, bevor die Entwickler an Bord kamen.
Natürlich ist es wichtig, das "Warum" von Regeln sowie das "Was" zu erklären. Sofern das "Warum" nicht klargestellt wird, können sie ihre Quelle einfach auf USB-Laufwerken oder Ähnlichem speichern.
quelle