it-swarm-eu.dev

Wie kann ich Cowboy-Programmierer davon überzeugen, die Quellcodeverwaltung zu verwenden?

[~ # ~] Update [~ # ~]
Ich arbeite in einem kleinen Team von Entwicklern, 4 Jungs. Sie haben alle die Quellcodeverwaltung verwendet. Die meisten von ihnen können die Quellcodeverwaltung nicht aushalten und entscheiden sich stattdessen dafür, sie nicht zu verwenden. Ich bin der festen Überzeugung, dass die Quellcodeverwaltung ein notwendiger Bestandteil der beruflichen Entwicklung ist. Mehrere Probleme machen es sehr schwierig, sie davon zu überzeugen, die Quellcodeverwaltung zu verwenden:

  • Das Team ist es nicht gewohnt, TFS zu verwenden. Ich hatte 2 Trainingseinheiten, aber nur 1 Stunde, was nicht ausreicht.
  • Teammitglieder ändern den Code direkt auf dem Server. Dies hält den Code nicht synchron. Vergleich erforderlich, nur um sicherzugehen, dass Sie mit dem neuesten Code arbeiten. Und es entstehen komplexe Zusammenführungsprobleme
  • Von Entwicklern angebotene Zeitschätzungen schließen die Zeit aus, die zur Behebung eines dieser Probleme erforderlich ist. Wenn ich also nono sage, dauert es 10x länger ... Ich muss diese Probleme ständig erklären und mich selbst riskieren, da mich das Management jetzt möglicherweise als "langsam" wahrnimmt.
  • Die physischen Dateien auf dem Server unterscheiden sich in unbekannter Weise über ~ 100 Dateien. Das Zusammenführen erfordert Kenntnisse über das jeweilige Projekt und daher eine Entwicklerzusammenarbeit, die ich nicht erhalten kann.
  • Andere Projekte sind nicht mehr synchron. Entwickler haben weiterhin ein Misstrauen gegenüber der Quellcodeverwaltung und verschärfen das Problem, indem sie keine Quellcodeverwaltung verwenden.
  • Entwickler argumentieren, dass die Verwendung der Quellcodeverwaltung verschwenderisch ist, da das Zusammenführen fehleranfällig und schwierig ist. Dies ist ein schwieriger Punkt, denn wenn die Quellcodeverwaltung so stark missbraucht und die Quellcodeverwaltung ständig umgangen wird, ist sie in der Tat fehleranfällig. Daher sprechen die Beweise aus ihrer Sicht für sich.
  • Entwickler argumentieren, dass das direkte Ändern des Servercodes durch Umgehen von TFS Zeit spart. Dies ist auch schwer zu argumentieren. Weil die Zusammenführung, die erforderlich ist, um den Code zu synchronisieren, um mit zu beginnen, zeitaufwändig ist. Multiplizieren Sie dies mit den über 10 Projekten, die wir verwalten.
  • Permanente Dateien werden häufig im selben Verzeichnis wie das Webprojekt gespeichert. Durch das Veröffentlichen (vollständige Veröffentlichung) werden diese Dateien gelöscht, die sich nicht in der Quellcodeverwaltung befinden. Dies führt auch zu Misstrauen gegenüber der Quellcodeverwaltung. Weil "Veröffentlichung das Projekt bricht". Das Beheben dieses Problems (Verschieben gespeicherter Dateien aus den Unterordnern der Lösung) erfordert viel Zeit und Debugging, da diese Speicherorte nicht in web.config festgelegt sind und häufig über mehrere Codepunkte hinweg vorhanden sind.

Die Kultur bleibt also bestehen. Schlechte Praxis erzeugt mehr schlechte Praxis. Schlechte Lösungen führen zu neuen Hacks, um viel tiefere und zeitaufwändigere Probleme zu "beheben". Server, Festplattenspeicher sind extrem schwer zu bekommen. Die Erwartungen der Benutzer steigen jedoch.

Was kann in dieser Situation getan werden?

62
P.Brian.Mackey

Es ist kein Trainingsproblem, es ist ein Problem mit menschlichen Faktoren. Sie wollen nicht und schaffen Straßensperren. Beschäftige dich mit der gebrochenen Gruppendynamik, was die Hauptursache für ihren Einwand ist - normalerweise Angst, ist es nur Angst vor Veränderung oder ist es finsterer.

Kein professioneller Entwickler hat sich heute oder in den letzten 20 Jahren der Quellcodeverwaltung widersetzt. Einmal, vor ungefähr 30 oder 40 Jahren, als Computer langsam waren, die Quellcodeverwaltung noch langsamer und Programme aus einer Datei mit 500 Zeilen bestanden, war dies ein Schmerz und es gab triftige Gründe, sie nicht zu verwenden. Diese Einwände können nur von den schlimmsten Cowboys kommen, die ich mir vorstellen kann.

Ist das System ihnen aufgezwungen, ihr Leben in irgendeiner Weise zu erschweren? Finden Sie heraus, was es ist, und ändern Sie das System, um den Einwand ungültig zu machen. Wiederholen, bis fertig.

Ich schlage vor, sich GIT oder Mercurial anzuschauen. Sie können in jedem Quellcodebaum ein Repository erstellen, das sie nicht einmal bemerken und das sie weiterhin so hacken können, wie sie es jetzt tun. Sie können die Änderungen verfolgen, die sie in die Codebasis gehackt haben, Commits vornehmen, sie in andere Quellbäume zusammenführen usw. Wenn sie sehen, dass Sie in Sekunden einen Aufwand von mehreren Wochen in einem anderen Produkt zusammenführen, können sie ihre Ideen ändern. Wenn Sie einen ihrer Fehler mit einem Befehl zurückdrehen und ihren Arsch retten, können sie sich sogar bei Ihnen bedanken (rechnen Sie nicht damit). Im schlimmsten Fall siehst du vor dem Boss gut aus und lässt sie als Bonus wie die Cowboys aussehen, die sie sind.

Das Zusammenführen würde nicht nur ein großes Wissen über das Projekt erfordern

In diesem Fall befürchte ich, dass Sie ohne Paddel den sprichwörtlichen Bach hinauf sind. Wenn das Zusammenführen keine Option ist und auch nicht implementiert wird, können Sie keine Funktionen mehr hinzufügen, die Sie bereits in einem Zweig haben (Begriff wird lose verwendet).

Wenn ich Sie wäre, würde ich meine Karrierechancen überdenken ...

91
mattnz

Manchmal machen es Probleme der realen Welt unpraktisch, sie zu verwenden.

Falsch.

Wenn das Team nicht an die Quellcodeverwaltung gewöhnt ist, können Schulungsprobleme auftreten

Das hat nichts mit Quellcodeverwaltung und alles mit Training zu tun. Das Training ist einfach, günstig, effizient und in wenigen Stunden erledigt. Die Nichtverwendung der Quellcodeverwaltung ist kostspielig, riskant, ineffizient und die Probleme bleiben für immer bestehen .

Wenn ein Teammitglied den Code auf dem Server direkt ändert, können verschiedene Probleme auftreten.

Das ist das Trainingsproblem. Nochmal. Nichts mit Quellcodeverwaltung und alles mit Training zu tun.

Entwickler haben weiterhin ein Misstrauen gegenüber der Quellcodeverwaltung und verschärfen das Problem, indem sie keine Quellcodeverwaltung verwenden

Sie müssen in der Verwendung der Quellcodeverwaltung geschult sein. Es reduziert Kosten, reduziert Risiken, vereinfacht Dinge und ist effizienter. Es ist eine einmalige Investition, die sich jeden Moment auszahlt.

Was kann in einer solchen Situation möglicherweise getan werden?

Beginnen Sie mit der Schulung aller Benutzer in der Verwendung der Quellcodeverwaltung.

Aktualisieren

Entwickler argumentieren, dass das direkte Ändern der Quellcodeverwaltung Zeit spart.

Da sie falsch sind, ist es wichtig, Daten zu sammeln, um genau zu zeigen, wie falsch dies ist.

Leider scheint das Management eine sofortige Antwort zu belohnen, die auf lange Sicht kostspielig ist.

Der einzige Weg, um dieses Belohnungssystem zu überwinden, ist zu

A) Stellen Sie fest, dass die langfristigen Kosten höher sind als der scheinbare kurzfristige Wert.

B) Identifizieren Sie die tatsächlich vorhandenen Belohnungen, die kurzfristige Korruption (d. H. Direkte Änderungen) wertvoller erscheinen lassen als eine langfristig korrekte Quellcode-Kontrolle. Wer bekommt einen Klaps auf den Kopf, weil er das Falsche getan hat? Was für einen Klaps auf den Kopf bekommen sie? Wer gibt es? Um Probleme zu beheben, müssen Sie die Dinge benennen, die falsch sind, und die spezifischen Manager, die die Leute tatsächlich ermutigen.

C) Empfehlen Sie ein überarbeitetes Belohnungssystem, das den langfristigen Wert anstelle der kurzfristigen schnellen Reaktion bewertet. Verschiedene Streicheleinheiten auf dem Kopf aus verschiedenen Gründen.

D) Bilden Sie die Leute in den Belohnungen aus, die Sie für einen langfristigen Wert gefunden haben. Wert, der deutlich größer ist als die kurzfristige schnelle Reaktion.

31
S.Lott

Entwickler, die sich weigern, die Quellcode-/Versionskontrolle zu verwenden, sollten einfach entlassen werden. Wie Sie bereits ausgeführt haben, überwiegen die mit der NICHT-Nutzung verbundenen Risiken und Kosten den damit verbundenen Aufwand um viele, viele Größenordnungen. Jeder, der versucht, dagegen zu argumentieren, sollte einfach nicht an der Softwareentwicklung beteiligt sein, und ich würde mich mit aller Kraft weigern, mit solchen Menschen zusammenzuarbeiten.

18
pap

Wir haben das Problem gelöst, indem wir zuerst einen Continuous Integration Server eingerichtet haben, um unsere Quellcodeverwaltung in dev zu integrieren. Zweitens: Sperren Sie den Ordnerzugriff schreibgeschützt, um zu verhindern, dass Benutzer die Quellcodeverwaltung umgehen und Dateien direkt ändern.

Es ist eine PITA an Tagen, an denen Sie den Fehler nicht lokal reproduzieren können, aber ansonsten ist es besser, arbeiten, einchecken und weitermachen zu können, da Sie wissen, dass er vom CI-Server automatisch an dev gesendet wird.

10
CaffGeek

Ich höre deinen Schmerz. Ich habe einige Arbeitsplätze betreten, um herauszufinden, dass es sich bei der Quellcodeverwaltung um einen freigegebenen Ordner auf einem Netzlaufwerk handelt. Das Problem liegt im Allgemeinen nicht darin, dass sie glauben, dass der Ansatz allen anderen überlegen ist. Er funktioniert einfach und sie wurden noch nie in einen Workflow eingeführt, der die Quellcodeverwaltung erfolgreich integriert.

Mit der Teamstruktur von Flat Earth, die Sie erklärt haben, ist es möglicherweise nicht der beste Weg, sich der Situation zu nähern, wenn die Änderung von oben nach unten verschoben wird. Eine Methode, die es wert ist, ausprobiert zu werden, besteht darin, sich direkt von einem oder zwei der anderen Entwickler einzukaufen, damit das Konzept an Dynamik gewinnt. Sobald Sie auch nur einen anderen Entwickler an Bord haben, ist es viel einfacher, ihn auf den Rest des Teams zu übertragen. Führen Sie sie langsam in das Konzept ein, sagen Sie, beginnen Sie mit der Arbeit an einem kleinen Nebenprojekt, rufen Sie es auf und gehen Sie in Git oder verzweigen Sie sogar etwas, das auf GitHub gehostet wird.

Fangen Sie einfach an und führen Sie die Konzepte langsam und getrennt von ihrem täglichen Arbeitsablauf ein. Menschen sind großartig darin, Dinge zu lernen und sich an Veränderungen anzupassen, insbesondere wenn diese Veränderungen ihnen direkten Nutzen bringen (denken Sie an Evolution). Wenn es jedoch mit einer ganzen Reihe kleiner Änderungen auf einmal präsentiert wird, wird es entfremdend. Sobald sie verstanden haben, wie die Quellcodeverwaltung funktioniert und welche Vorteile sie bietet, versuchen Sie, sie in eines Ihrer internen Projekte zu integrieren (wenn Sie ein neues Projekt starten, ist dies eine schlechte Zeit, um es einzuführen). Lassen Sie die anderen Projekte auch auf die vorhandene Weise funktionieren, wenn Sie möchten. Dies ist besonders effektiv, um die Vorteile einer anständigen Codesteuerung hervorzuheben.

Wenn dies fehlschlägt, führen Sie aus.

8
Kim Burgess

Sie haben offensichtlich die technischen Fähigkeiten, um Ihre Situation zu identifizieren und zu beheben. Ihre Probleme sind menschlich und prozessbezogen.

Die Leute reagieren viel besser auf Beispiele als auf Visionen, daher würde ich vorschlagen, sie selbst zu "reparieren":

Nehmen Sie eine Kopie der neuesten Quelle, strukturieren Sie sie so, dass sie für die Versionskontrolle geeignet ist, und erstellen Sie ein neues Projekt mit einer nützlichen, vorausschauenden Struktur (erarbeiten Sie, wie Sie mit Zweigen umgehen, in die Sie Abhängigkeiten von Drittanbietern einfügen usw.). Sie müssen das wahrscheinlich in Ihrer eigenen Zeit tun.

Ziehen Sie dann Ihre Mitarbeiter und das Management in einen Raum und zeigen ihnen, wie Softwareentwicklung im 21. Jahrhundert aussieht. Veranschaulichen Sie die Fehler mit Ihrem aktuellen System und zeigen Sie, wie sie mit Ihrer neuen Struktur behoben werden.

Sie müssen sich auch als Bewahrer der Quelle etablieren - da Sie der einzige zu sein scheinen, der sich darum kümmert, liegt es an Ihnen, die Menschen (mit allen technischen oder psychologischen Mitteln, die Ihnen zur Verfügung stehen) zu zwingen, sich daran zu halten der Plan. Stellen Sie sicher, dass die nur Sache, die an einen Kunden geht, von einer Build-Maschine stammt, die sich nicht in der Quellcodeverwaltung befindet. Menschen rituell demütigen, die gegen die Regeln verstoßen und Chaos anrichten. Bestechen Sie sie mit Donuts ... was auch immer funktioniert.

Wenn das alles zu viel Aufwand ist, dann (wie in fast jeder anderen Antwort gesagt) - holen Sie sich einen anderen Job. Sie sind deine Zeit nicht wert.

6
MarcE

Wie kann jemand nicht wollen, dass verschiedene Versionen seiner Dateien und die Fähigkeit, die Unterschiede zu sehen? Vergessen Sie die Verzweigung und all die komplexen Dinge. Sie bekommen nicht einmal die Grundlagen. Das direkte Ändern einer Produktionsdatei ohne die rudimentärste Änderung in einer Testumgebung ist verrückt. Ich habe mit einigen Personen gearbeitet und zum Glück haben wir nie an denselben Projekten gearbeitet.

Ihre Mitarbeiter sind zu dumm, um faul zu sein. Das ist Zeitverschwendung. Sie können nur hoffen, Ihren Manager zu schulen. Das Management sollte die Quellcodeverwaltung mögen, weil es alle Formen der Kontrolle mag. Sie fühlen sich wichtig. Scheiß auf die anderen; Den Anführer zu reparieren ist Ihre einzige Hoffnung, da Sie ihn nicht ersetzen können. Beginnen Sie mit anderen kompetenten Entwicklern in Kontakt zu treten und versuchen Sie entweder, sie dazu zu bringen, sich Ihrem Team anzuschließen, wenn Sie eine Eröffnung haben, oder lassen Sie sich von ihnen in ihrem Geschäft einstellen.

4
JeffO

Schritt 1 - Inkompetenten Manager entlassen!

Wenn Sie Schritt 1 nicht ausführen können, versuchen Sie, den Manager dazu zu bringen, die Bereitstellung auf nur Skripts zu beschränken, die aus der Quellcodeverwaltung stammen. Wenn Entwickler (die keine Produktionsrechte für Produkte haben sollten, siehe Schritt 1, wenn sie dies tun) möchten, dass ihre Inhalte bereitgestellt werden, muss dies aus der Quellcodeverwaltung stammen. Das löste unser Problem, die Quellcodeverwaltung nicht ganz zu verwenden, als wir sie zum ersten Mal für Datenbank-Inhalte und C # -Code verwendeten.

4
HLGEM

Aus Ihrer Beschreibung geht hervor, dass es ein oder mehrere Probleme mit der Situation gibt - entweder ist das Entwicklerteam außer Kontrolle geraten oder es wurde eine schlechte Quellcodeverwaltungslösung implementiert. In jedem Fall obliegt es dem Entwicklerteam, eine Quellcodeverwaltungslösung zu verwenden. Wenn Sie den Quellcode im Produktionsdienst direkt ändern, müssen nur Probleme auftreten.

Nach meiner Erfahrung besteht der erste Schritt, der sofort erfolgen muss, darin, die Quellcodeverwaltung mit dem Produktionsserver zu synchronisieren. Dieser Schritt kann so einfach sein, wie eine Kopie des Produktionscodes zu erstellen und einzuchecken - der Produktcode ist vermutlich die Basis, die Ihr Team entwickelt. Dieser Schritt muss möglicherweise durch eine Zusammenführung mit Code ergänzt werden, der im vorhandenen Versionsverwaltungssystem herumschwebt. Der Code sollte von dev zu Integration/QA (oder zu beiden) und dann entweder zu Stufe oder Stufe/Produktion fließen.

Als nächstes muss das Management die Verwendung der Quellcodeverwaltung vorschreiben. Ganz einfach, wenn der Build nicht vom Quellcodeverwaltungssystem stammt, sollte Code nicht für die Produktion bereitgestellt werden. Der Produktionszugriff muss nur auf das Support-Team beschränkt werden, wobei Entwickler nur eingeschränkten Zugriff erhalten, um Produktionsprobleme zu beheben. Entwickler sollten im Allgemeinen niemals Hot-Code-Bereitstellungen für die Produktion durchführen - Produktionsprobleme können definitiv auftreten, insbesondere wenn die Entwickler unter Druck stehen.

Das Management muss die Probleme hier definitiv besser in den Griff bekommen - es wird fast unmöglich sein, die Entwicklung aufrechtzuerhalten, wenn Code direkt auf das Produkt angewendet wird (und nicht in die Quellcodeverwaltung gelangt).

3
JW8

Dies ist ein gutes Beispiel für ein Projekt, bei dem schlechte Praktiken so weit verbreitet waren, dass es praktisch unmöglich wird, sie zu beheben. Das Reparieren würde ein Einfrieren erfordern, so dass alles ohne Unterbrechung bereinigt werden kann. Leider sind solche Projekte normalerweise (aus offensichtlichen Gründen) zu fehlerhaft, um für mehrere Monate eingefroren zu werden. Kritische Fehler müssen jeden zweiten Tag behoben werden.

Sie könnten versucht sein, das Projekt zu verzweigen, um eine saubere Version zu erstellen, während die schmutzige Version mit diesen täglichen Bugfixes behandelt wird. Das wahrscheinlichste Ergebnis ist jedoch, dass nach einigen Monaten, wenn die "saubere" Version fertig ist, niemand mehr sagen kann, welche Bugfixes und Änderungen seit der Abzweigung übernommen wurden (da dieselbe Denkweise, mit der die Leute in solche Praktiken schlüpfen, dies unwahrscheinlich macht Sie führen Aufzeichnungen über die von ihnen vorgenommenen Änderungen. Die saubere Version ist veraltet, die schmutzige Version funktioniert immer noch irgendwie. Was passiert also? Die saubere Version wird abgeladen, die Neinsager haben sich als richtig erwiesen.

3
user281377

Abgesehen von der offensichtlichen Suche nach einem neuen Job denke ich, dass die Antwort eher die oben genannten ist.

Wenden Sie sich zunächst an das Management, um sie mit der Umstellung auf die Quellcodeverwaltung und deren Durchsetzung vertraut zu machen. Dann kommen Sie zu dem, was getan werden muss, um die Dinge am Laufen zu halten, auch wenn dies bedeutet, direkt auf dem Server zu arbeiten. Starten Sie den Prozess, um alles in die Quellcodeverwaltung zu bekommen.

Eine andere Möglichkeit besteht darin, sicherzustellen, dass sich die neueste Version auf dem Server befindet (was Sie unabhängig davon tun müssen) und ein neues Repository insgesamt ab der neuesten Version zu starten. Sie werden die Geschichte verlieren, aber an diesem Punkt sind das kleine Kartoffeln.

2
Jacob Schoen

Aus Gründen Ihrer eigenen Gesundheit würde ich empfehlen, Git oder ein anderes DVCS auf Ihrem eigenen Computer einzurichten, damit Sie Änderungen nachverfolgen können. Importieren Sie die Änderungen Ihrer Mitarbeiter häufig in Ihr Repository. Lösen Sie Konflikte so gut wie möglich. Dies schützt Sie teilweise vor dem Wahnsinn Ihrer Mitarbeiter.

Sie haben erwähnt, dass das Management gesagt hat, dass Entwickler die Quellcodeverwaltung verwenden sollten. Wenn Sie böse sein möchten, können Sie dies erzwingen, indem Sie Änderungen in TFS einchecken und das Repository regelmäßig veröffentlichen, wodurch alle Änderungen, die nicht in TFS enthalten sind, blockiert werden. (Wenn Sie auch Ihr eigenes DVCS warten, sollten Sie die beiden synchronisieren.) Ihre Rechtfertigung dafür ist, dass Sie den Anweisungen des Managements folgen. Wenn Ihre Mitarbeiter es satt haben, ihre Änderungen überschreiben zu lassen, laden Sie sie ein, TFS zu verwenden. Und machen Sie weiter mit Änderungen, die noch nicht eingecheckt wurden. Fahren Sie fort, bis Ihre Mitarbeiter nachgeben oder Sie entlassen werden.

1
Jonathan

Das eigentliche Problem ist nicht, dass die Cowboy-Codierer keine Versionskontrolle verwenden. Das eigentliche Problem ist, dass sie bereits eine Vorgehensweise gewählt haben und Sie versuchen, ihren Prozess zu ändern. Der gewählte Prozess beinhaltet keine Versionskontrolle. Alle Prozessänderungen sind schwierig, es sei denn, die Programmierer selbst bemerken ein Problem. Wenn das Gefühl besteht, dass das vorhandene System gut genug ist, ist es einfach sinnlos, ein anderes System durchzusetzen. Wir sind die Borg, Sie werden assimiliert. Natürlich versuchen sie zu kämpfen, um Borg zu werden.

1
tp1

Sperren Sie alle anderen Server als deren Entwicklung. Verwenden Sie einen Konfigurationsmanager. Führen Sie regelmäßig identifizierbare Builds durch (gegen Tags). Kennzeichnen Sie jeden Änderungssatz (dh 1 Änderungssatz pro Fehler). Wir haben auch jedem Build ein Tag hinzugefügt. Haben Sie ein QS-System zwischen Entwickler und Produktion (mindestens). Erstellen Sie Builds für das QS-System mit dem richtigen Build-Tag. Gib ihnen Kummer, weil sie "den Build gebrochen" haben.

Ich bin noch nie auf eine Situation gestoßen, in der ich ein Problem nicht neu erstellen/beheben konnte (das nur in der Produktion angezeigt wird). Ja, ich habe Stunden damit verbracht, das Problem auf einem Entwicklungssystem neu zu erstellen (und wenn Sie es herausfinden, können Sie es Ihrem Regressionstest hinzufügen).

Wir haben ein Projekt mit einer Reihe von Cowboy-Auftragnehmern durchgeführt, die all diese schlechten Dinge getan haben. Danach verbringe ich 4 Wochen damit, aufzuräumen und dann die oben genannten Praktiken anzuwenden. Das Projekt hatte seitdem keine Probleme mit all diesen Dingen.

0
Paul