Am Ende meines Seils [geschlossen]

Ich bin ein Auftragnehmer einer großen Firma. Derzeit sind drei Entwickler an dem Projekt beteiligt, ich selbst eingeschlossen.

Das Problem ist, dass die anderen 2 Entwickler es nicht wirklich verstehen. Mit "es" meine ich Folgendes:

• Sie verstehen die Best Practices für die von uns verwendete Technologie nicht. Nach 6 Monaten, in denen ich und andere ihnen Beispiele geben, werden schreckliche Anti-Muster verwendet.
• Sie sind "Copy and Paste" -Programmierer, die hauptsächlich Spaghetti-Code produzieren.
• Sie brechen ständig Dinge, nehmen Änderungen vor, führen aber keinen grundlegenden Rauchentest durch, um zu prüfen, ob alles in Ordnung ist
• Sie weigern sich / fragen selten nach Code-Reviews.
• Sie lehnen sogar grundlegende Dinge wie das Formatieren von Code ab.
• Keine Dokumentation zu Klassen (jsdocs)
• Angst, Code zu löschen, der nichts tut
• Hinterlassen Sie überall kommentierte Codeblöcke, obwohl wir die Versionskontrolle haben.

Ich bin immer frustrierter, wenn ich anderen Code formatiere, Fehler behebe, defekte Funktionen entdecke und Abstraktionen zum Entfernen der Spaghetti erstelle.

Ich weiß wirklich nicht, was ich tun soll. Ich versuche nicht zu frustriert zu werden, aber es ist nur ein Chaos. Ich mag diese Leute als Menschen, aber ich denke, die Codierungssituation ist so schlecht, dass ich mich schneller bewegen könnte, wenn sie einfach den ganzen Tag im Internet surfen würden.

Wäre es nicht angebracht, unseren Manager zu bitten, die anderen SVN-Commit-Zugriffe zu überprüfen? Commits können nur nach einer Überprüfung durch jemanden durchgeführt werden, der mit unseren Tätigkeiten vertraut ist. Als Auftragnehmer bin ich mir nicht sicher, ob dies der beste Schritt ist.

Gibt es eine subtile / nicht so subtile Methode, um deutlich zu machen, wie viele Dinge ich behebe?

Ich habe so etwas in meinem Team. Ich habe mich sehr bemüht, die Leute dazu zu bringen, das Richtige zu tun, und es hat nicht wie erwartet funktioniert, also bin ich zu einer anderen Lösung übergegangen.

Zuerst ging ich zu meinem Manager und wir arbeiteten einen Deal aus, bei dem kein Code in die Quellcodeverwaltung gelangt, es sei denn, er wird durch Unit-Tests abgedeckt. Wenn der Code ohne Komponententests eingeht, kann ich das Commit sofort rückgängig machen und den Verantwortlichen anpingen, um die Tests zu bearbeiten und dann den Code weiterzuleiten.

Mit dieser Regel führe ich regelmäßig Code-Coverage-Tools aus (in diesem Fall jacoco in unserem sbt- Build), um sicherzustellen, dass Teile korrekt abgedeckt werden. Außerdem führe ich ständig Refactorings und Code-Überprüfungen in jedem von ihnen gepushten Code durch. Da es sich um ein Java- und Scala- Projekt handelt, habe ich viele Tools, die mir dabei helfen, Dinge zu finden, die nicht vorhanden sein sollten oder die unserer Meinung nach nicht so funktionieren, nicht sicher, wie Sie dasselbe mit JavaScript tun können, aber vielleicht gibt es sie eine Lösung.

Die Hauptsache, von der ich glaube, dass sie mir dabei hilft, mitzuhalten, ist, dass ich eine klare Vorstellung davon habe, was ich von dem Projekt und seiner Hauptarchitektur erwarte. Wenn ich also etwas sehe, das diese Ansicht nicht widerspiegelt, kann ich dorthin gehen und repariere es. Sie sollten das Gleiche tun, Ihre Ansicht definieren, die zu verwendenden Muster sowie die Art und Weise, wie Code geschrieben werden soll, und sich selbst über diese Informationen informieren, damit sie (und Ihr Management) immer wissen, was passiert und was das Projekt davon abhält, weiterzumachen schneller.

Es wird sicher einen Moment geben, in dem sie entweder aufgeben und das Richtige tun oder das Management die Nachricht erhält und sie aus dem Projekt entfernt.

Ich bin mir sicher, dass Sie meine Kommentare und meinen anderen Beitrag bereits gesehen haben. Ich werde also nicht so tun, als wüsste ich die Antwort. Das Beste, was ich anbieten kann, ist eine Zusammenfassung dessen, was ich von anderen gehört / gelesen habe und einige meiner eigenen Erfahrungen in die Mischung einfließen zu lassen.

Zunächst möchte ich sagen, dass ich vor einiger Zeit auf einen Blog gestoßen bin, der einem unserer eigenen Programmierer SE-Mitglieder, Martin Blore und IMO, gehört. Dieser eine spezifische Beitrag über die TDD-Selbstaktualisierung ist sehr genau. TDD ist die letzte, höchste Ebene, die alles miteinander verbindet, aber ohne vorherige Ebenen, insbesondere die größte, Prinzipien und Praktiken der Erzeugung von klarem und lesbarem Code, wird es sehr schwierig, wenn nicht unmöglich sein, TDD zum Laufen zu bringen.

In meiner Firma wurden uns sowohl Agile als auch TDD vom Management auferlegt, und zuerst haben wir sie einfach getan, weil uns gesagt wurde (was das Gegenteil von Agile ist). Wir haben TDD zweimal ausprobiert und obwohl ich ein großer Befürworter der Verwendung automatisierter Tests bin, habe ich persönlich alle herausgeschmissen, die das Team in der letzten Version zusammengeschlagen hat. Sie waren zerbrechlich, gigantisch, kopierten / fügten den Wazoo ein und waren gespickt mit Schlafanweisungen, die sie wirklich langsam und unvorhersehbar laufen ließen. Mein Rat an Ihr Team: DO NOT TDD ... yet.

Ich weiß nicht, wie es Ihnen geht, weil Sie erwähnt haben, dass Sie erst seit 6 Monaten im Unternehmen sind und Unternehmer sind. Sind Ihre langfristigen Ziele, bei diesem Unternehmen zu bleiben, oder läuft der Vertrag aus? Ich frage, denn selbst wenn Sie etwas tun, kann es einige Zeit dauern, bis tatsächlich Ergebnisse erzielt werden.

Auch wenn Sie einem Team beitreten, dauert es in der Regel eine Weile, bis Sie genügend Glaubwürdigkeit und Respekt für Ihr Team erhalten, wo sie (Entwickler und Management) sogar alles in Betracht ziehen, was Sie vorschlagen. Nach meiner Erfahrung ist es hilfreich, wenn Sie nur wenige Brände löschen und nachweisen, dass Sie über Fähigkeiten und Kenntnisse verfügen, auf die sich andere verlassen können. Ich bin mir nicht sicher, ob 6 Monate ausreichen. Ziemlich oft trat eine neue, ehrgeizige Person dem Team bei und fragte hier, wie sie die Welt verändern könne. Traurige Realität ist, dass sie einfach nicht können.

Vorausgesetzt, Sie haben den Respekt und die Aufmerksamkeit Ihres Teams. Was jetzt?

Zunächst müssen sich sowohl das Management als auch die Entwickler des Problems bewusst sein. Managementmaßnahmen resultieren in geleisteter Arbeit. Wenn sie mit der aktuellen Menge und Qualität der Features zufrieden sind, dann ist die traurige Realität, dass sie nicht zuhören. Wie andere betont haben, wird es ohne die Unterstützung des Managements äußerst schwierig sein, irgendeine Art von Veränderung einzuführen.

Sobald Sie Managementunterstützung erhalten haben, müssen Sie tiefgreifend nach den Ursachen suchen, warum das Team so arbeitet, wie es funktioniert. Dieses nächste Thema ist seit einiger Zeit eine persönliche Aufgabe von mir. Bisher war dies meine Reise:

1. Sobald Sie die Unterstützung des Managements haben. Sie können damit beginnen, viele zentral festgelegte Praktiken / Prozesse einzuführen , die MainMa als Antwort auf meine Frage vorgeschlagen hat . Wir haben eine Menge davon gemacht (mit Ausnahme der gekoppelten Programmierung) und Sie sehen definitiv Vorteile. Code-Reviews halfen insbesondere dabei, das Styling und die Dokumentation zu standardisieren, und ermöglichten es uns, das Wissen und die Techniken im Team zu teilen. Obwohl die Codeüberprüfungen diktiert wurden, gefallen sie dem Team tatsächlich und wir überprüfen jede Funktionalität, die eingecheckt wird. Allerdings ...
2. Sie bemerken, dass der allgemein geschriebene Code immer noch zu gekoppelt ist, das Design schlecht ist oder völlig fehlt. Code Reviews fangen einiges davon auf, aber es gibt nur so viel, was Sie umschreiben können. Warum ist Design überhaupt schlecht? - Viele Entwickler wurden noch nie in bewährte Praktiken eingeführt, und ihnen wurde die OOD nie in erster Linie offiziell beigebracht. Viele Leute "codierten" einfach die Aufgaben, die ihnen übertragen wurden.
3. Mit der Unterstützung des Managements können Sie weitere Prozesse einführen, z. B. die Erörterung des Designs, bevor eine Codierung stattfindet. Aber Sie sind nur eine Person und es sieht so aus, als würde das Team auf das zurückgreifen, was es immer getan hat, sobald Sie nicht darauf geachtet haben. Warum?
4. Können bessere Praktiken oder Gewohnheiten eingeführt und vermittelt werden, so dass Sie nicht ständig überwachen müssen? - Es stellt sich heraus, dass dieser Teil nicht so einfach ist.
5. Warum zögern andere Teammitglieder, neue Praktiken zu erlernen und zu erlernen, und warum sind sie SOLID- oder DRY-resistent, wenn in der Literatur über moderne Softwaremethoden so viel geschrieben wurde? Bei all den positiven Veränderungen in meinem Team hatte ich vor 2 Wochen ein Argument: Ich habe 2 Funktionen überarbeitet, die identische 15 Codezeilen hatten, und der Rezensent nannte es heroisch, unnötiger Aufwand, weil es nichts auszusetzen gibt, wenn nur kopiert / eingefügt wird 15 Zeilen. Ich bin mit solchen Ansichten überhaupt nicht einverstanden, aber im Moment haben wir uns darauf geeinigt, nicht zuzustimmen. - Und jetzt? Jetzt haben wir das Thema meines anderen Beitrags erreicht .
6. Wie maple_shaft und nikie in ihren Antworten betonten (sorry, MainMa , du hast die meisten Stimmen, aber du bist so 5 Schritte zurück :)), hast du ein Stadium erreicht, in dem "process" dir und niemand in diesem Forum mehr helfen kann kann dir sagen was das "fix" ist. Der nächste Schritt besteht darin, sich Einzelpersonen zu nähern, vielleicht als Team, wahrscheinlich beides, und mit ihnen zu sprechen. Fragen Sie sie, was funktioniert und was nicht. Die einzige Möglichkeit, die Hauptursache für das zu identifizieren, was sie antreibt, besteht darin, mit ihnen einzeln zu sprechen und dies herauszufinden. Als Teil dieses Schritts bin ich kürzlich auf ein völlig anderes Teamproblem gestoßen, aber ich denke, Joels Antwort ist hierDas ist sehr detailliert und aufschlussreich und würde auch für diesen Fall gelten. Zusammenfassend gesagt, während Management als "kurze Leine" ein möglicher Ansatz für fast alles ist, müssen wir uns daran erinnern, dass wir uns mit Menschen befassen, um wirklich die Motivationen zu verstehen, die wir mehr in die Psychoanalyse einfließen lassen müssen als reines Management oder technische Führung.
7. Also sprichst du jetzt mit deinen Teamkollegen? Was fragst du sie? Ich bin mir bei diesem nächsten Teil nicht sicher, weil ich noch nie hier war. Hier ist ein mögliches Szenario: F: Wie kommt es, dass kein SOLID vorhanden ist? A: Ich brauche es nicht. F: Es könnte helfen. A: Mir geht es gut so wie es ist. - Irgendwie müssen Sie eine Reihe von Geräuschen erzeugen, die Ihren Mund verlassen und den Zuhörer erkennen lassen, dass die Dinge besser sein könnten, wenn sie dem, was Sie gerade machen, eine Chance geben. Wenn Sie hier scheitern, werden sie nie davon überzeugt sein, dass das, was "der Prozess" von ihnen bewirkt, tatsächlich einen Wert hat. Wenn Sie diesen Punkt jedoch überwinden, werden Sie wahrscheinlich feststellen, dass Sie nicht einmal mehr "den Prozess" benötigen.
8. IMO Ihre Teamkollegen werden von Anfang an nichts lernen, wenn sie nichts mit ihren aktuellen Gewohnheiten / Praktiken zu tun haben. Vielleicht besteht der nächste Schritt darin, einen Weg zu finden, um die Probleme zu veranschaulichen, hervorzuheben und sie offensichtlich zu machen. Schließlich schreiben wir keinen lesbaren Code, verwenden SOLID / DRY-Prinzipien oder pflegen keine Dokumentation, nur weil es uns ein warmes und unscharfes Gefühl gibt. Wir tun es, weil es Code mit besserer Qualität erzeugt und uns ehrlich gesagt Code schneller macht. Kann das gemessen werden? Vielleicht kommen hier Software-Metriken ins Spiel?
9. Hier ist eine verrückte Idee, und ich habe keine Ahnung, ob sie tatsächlich funktionieren würde (es könnte eine branchenübliche Praxis sein oder sie ist völlig ungültig. Ich habe sie in den letzten 24 Stunden erfunden), aber ich bin sehr versucht, sie vorzulegen an den Tisch, sobald das nächste Jahr beginnt:
   • Stellen Sie entgegen den Meinungen vieler anderer die Idee des Autors / Eigentümers für alle Quelldateien vor. Wie The Pragmatic Programmer vorschlägt, vermittelt dies einer einzelnen Person, die für einen Teil des Quellcodes verantwortlich ist, ein Gefühl der Eigenverantwortung und Verantwortung. Das bedeutet nicht, dass andere Personen den Code nicht ändern können. Wir arbeiten alle als Team, aber letztendlich ist die Person, die den Code besitzt, für die Überprüfung der Änderungen verantwortlich.
   • Erstellen Sie einen Quell-Repository-Trigger, der alle Eincheckvorgänge überwacht und speziell nach Bugfixes sucht. Machen Sie es so, dass jede Fehlerbehebung eine Referenz-ID in der Check-in-Beschreibung hat. Schreiben Sie nun ein Skript, das eine Liste der geänderten Dateien analysiert und den "Autor" aus dem Kommentarblock für die Dateikopfzeile entfernt. Erstellen Sie eine SQL-Datenbank, die die Anzahl der eingecheckten Fehler pro Datei / pro Projekt / pro Autor protokolliert.
   • Wenn Sie genug Statistiken haben, werden Sie hoffentlich feststellen, dass Ihr Code weniger Fehler / Änderungen aufweist als einige der anderen Codes. Dies sind harte Daten, die Sie verwenden können. Wenn ein einzelnes Projekt eine deutlich überdurchschnittliche Fehlerquote aufweist, sollten Sie es als Kandidaten für die nächste Bereinigung / Umgestaltung heranziehen, um technische Schulden zurückzuzahlen.
   • Wenn ein Projekt oder eine Datei eine deutlich überdurchschnittliche Fehlerrate aufweist und einen Eigentümer hat, sprechen Sie mit dieser Person im persönlichen Gespräch. Fragen Sie sie sehr höflich und konfliktfrei, was sie tun können, um dies zu beheben. Da sie der Eigentümer sind, sollten sie die Veränderung vorantreiben, aber jegliche Hilfe von Ihrer Seite anbieten. Hoffentlich kann der Besitzer viele Ursachen auf seinen eigenen Spaghetti-Code zurückführen. Sobald er um Hilfe bittet, können Sie sofort loslegen und SOLID auf den Tisch legen.

Ich schlage vor, dass Sie mit Ihrem Manager über das Problem sprechen, aber er wird mit ziemlicher Sicherheit nicht jeden einzelnen Check-in überprüfen wollen.

Stattdessen schlage ich vor, dass Sie eine Reihe von Unit- / Regressionstests vorschlagen, die in SVN eingebunden werden und für jedes Einchecken ausgeführt werden. Das hilft dir zumindest dabei, kaputte Builds zu vermeiden. Sie können schrittweise andere bewährte Methoden vorschlagen.

Wenn er sich als völlig unempfänglich herausstellt, sollten Sie vielleicht über seinen Kopf gehen. Wenn Sie sich dazu entschließen, müssen Sie Ihr bestes Spiel mitbringen. Wenn Sie dies tun, werden Sie sich grundsätzlich an das Management wenden, um auf einer höheren Ebene eingestellt zu werden.