Ich arbeite als iOS-Entwickler in einem kleinen Outsourcing-Unternehmen in einem Team von 4 Personen. Wir arbeiten an einem Projekt, das einige Jahre vor meinem Einstieg und zwei weiteren Entwicklern begonnen hat. Vorher wurde das Projekt hauptsächlich von einer Person durchgeführt.

Als ich anfing, an dem Projekt zu arbeiten, war es ein komplettes Durcheinander. Es wurde viel Code wiederholt. Ich sah die gleichen 500 Code in 20 verschiedenen Dateien mit geringfügigen Abweichungen kopiert. Außerdem war es nicht gerade gut organisiert: Der gesamte Code für die Erstellung der Benutzeroberfläche wurde in den Ansichtscontrollern zusammen mit der Logik gemischt.

Ich habe mein Bestes getan, um die Dinge hier und da umzugestalten, überflüssigen Code zu entfernen, die Dateistruktur des Projekts zu verbessern und so weiter. Es fühlte sich so an, als würde sich der vorherige Entwickler nicht wirklich um all diese Dinge kümmern oder hätte nicht die Erfahrung. Es gab eine Zeit, in der ich ein paar Monate allein an einem ziemlich großen Feature gearbeitet habe. Aufgrund der Art dieser Funktion musste ich eine Menge Code in der gesamten App berühren, also habe ich versucht, einige Verbesserungen vorzunehmen.

Als andere Entwickler dem Projekt beitraten, stellte ich fest, dass sie einen anderen Codierungsstil (manchmal einen völlig anderen Stil) verwenden und häufig keine modernen Sprachfunktionen wie Property Accessors verwenden (dies ist in Objective-C relativ neu). Manchmal erfanden sie ihre eigenen Fahrräder, anstatt ähnliche Features des Frameworks zu verwenden, oder transferierten Konzepte aus anderen Programmiersprachen oder Mustern, die sie in unsere Codebasis gelernt hatten. Oft können sie Methoden oder Variablen wegen schlechten Englisch nicht richtig benennen (Objective-C ist eine Sprache, in der Sie lange Namen machen).

Manchmal denke ich, wenn die IDE nicht wäre, würden sie den gesamten Code ohne Einrückung oder Formatierung schreiben.

Grundsätzlich hasse ich den Code, den sie schreiben. Es ist schlecht formatiert / organisiert und unterscheidet sich manchmal radikal vom Rest des Projekts. Ich bin sehr verärgert, wenn sie ihre Spaghetti zu meinem Kunstwerk hinzufügen, und das beeinflusst meine Arbeitsstimmung und meine Produktivität.

Es fühlt sich immer mehr so ​​an, als ob sie sich nicht die Mühe machen zu lernen oder es ihnen egal ist: Sie tun nur das, was von ihnen verlangt wird und gehen nach Hause. Ich habe versucht, ihnen ein paar Tipps zu geben, wenn ich Gelegenheit hatte (z. B. ihre PR kommentiert oder auf GitHub festgeschrieben). Ich habe einmal freundlich gebeten, den Codierungsstil und die Formatierung des Großteils des vorhandenen Codes zu befolgen (leider haben wir kein offizielles Codierungsstil-Dokument). Aber es hat nicht funktioniert ...

Wie kann ich diese Situation angehen, ohne mich nur auf „schlechte Unternehmenskultur“, „unerfahrene Absolventen“ usw. zu konzentrieren und die Situation tatsächlich zu verbessern?

Lehren und üben Sie, was Sie predigen.

Sie wissen, dass dieses Zeug wichtig ist. Sie kennen den Nachteil, wenn es nicht richtig gemacht wird.

Jetzt besteht die Herausforderung darin, andere zu überzeugen. Dies wird nicht durch eine einzelne Konversation, eine Besprechung, Gespräche auf dem Flur, Tipps oder innerhalb einer Pull-Anfrage durchgeführt.

Das braucht:

• Öffentliche Anerkennung durch das Management, dass diese Punkte wichtig sind
• Linters, damit die Leute zusammenkommen, sich auf Stil einigen und dann Computer die Polizeiarbeit machen lassen können
• Führende Entwickler, die sich voll einkaufen und bereit sind, andere zu unterrichten
• Meetings, Demos, Mittagessen und Lernen, etc., um diese Ansätze zu lehren
• Menschen, die an den von Ihnen in ihren Bewertungen erwähnten Qualitätsmerkmalen gemessen werden
• Dokumentierte und veröffentlichte Normen
• Pull-Anfragen mit vielen Überprüfern
• Pull-Anforderungen werden erst zusammengeführt, wenn die Codequalität hoch ist
• Häufige Code-Paarung
• Gruppencode-Überprüfungen für komplexe PRs

In Wort erfordert es

Führung

Die gute Nachricht ist, dass all diese Aktivitäten allgemein als bewährte Praktiken anerkannt werden. Wenn Sie also für sie werben oder sich vom Management einschreiben lassen, sollten Sie gute Erfolgschancen haben und in der Lage sein, das Richtige zu tun. Das Management könnte sich jedoch immer noch nicht einkaufen, das ist ein anderes Thema und eine andere Frage.

Ich habe in der Vergangenheit viel zu diesem Thema auf SoftwareEngineering.SE geschrieben und war selbst in ähnlichen Situationen. Daher werde ich versuchen, einige Hinweise zu geben und einige Probleme hervorzuheben, die ich beim Lesen Ihrer Frage festgestellt habe.

Aber zuerst sprechen wir über einen wichtigen Aspekt: ​​Ihre Rolle im Unternehmen.

Deine Rolle

Möglicherweise haben Sie einen ausdrücklichen Auftrag von Ihrem Chef, die Dinge zu verbessern, und einen Platz in der Hierarchie, an dem andere Entwickler auf Ihre Befehle hören müssen . Oder Sie gehören zu Gleichaltrigen, haben dieselbe Rolle und dieselbe Autorität, und Ihre Option ist nur ... nun ja ... eine Meinung .

In beiden Fällen ist weniger Ihr Platz in der Hierarchie von Bedeutung als vielmehr:

• Was andere Entwickler von Ihnen halten. Wenn sie dich als einen nervigen Kerl behandeln, der sie nach dummen Dingen fragt, kommst du nicht weit. Ich habe viele Fälle erlebt, in denen technische Leiter und Projektmanager absolut keinen Einfluss auf das Team hatten, weil das Team wusste (oder dachte), dass diese „Leiter“ keinen technischen Hintergrund hatten, um Entscheidungen zu treffen, die sie trafen. Andererseits habe ich einige Entwickler gesehen, die von ihren Kollegen angehört wurden, weil sie wussten, dass diese Entwickler geschickt und erfahren sind.

• Wie solide ist Ihr Team und was motiviert es? Stellen Sie sich ein Unternehmen vor, in dem jeder Entwickler für KLOC / Monat bezahlt. Würden Sie Ihren Kollegen etwas über Stil sagen? Wahrscheinlich nicht, denn selten sind Personen, die weniger bezahlt werden wollen. Im Allgemeinen können Sie nichts verbessern, wenn es sich nicht um ein Team, sondern nur um eine Gruppe von Personen handelt, die am selben Projekt arbeiten.

Abhängig davon können Sie entscheiden, ob es sich lohnt, Änderungen vorzunehmen. Wenn Sie keine Stimme haben und es keinen Zusammenhalt im Team gibt, suchen Sie einfach einen anderen Job. Wenn Sie als talentierter, angesehener Entwickler bekannt sind und ein starkes Teamgefühl herrscht, können Sie die Dinge relativ einfach verbessern, selbst wenn Sie der Feindseligkeit Ihres Chefs oder anderer Teams ausgesetzt sind.

In jedem Fall ist es wichtig, keinen Druck auf Ihr Team auszuüben. Arbeite mit ihnen, nicht gegen sie. Gib ihnen keine Befehle, sondern führe sie zum Ziel.

Nun die Hinweise.

Stil

Ich habe einmal freundlich gebeten, den Codierungsstil und die Formatierung des Großteils des vorhandenen Codes zu befolgen (leider haben wir kein offizielles Codierungsstil-Dokument). Aber es hat nicht funktioniert ...

Natürlich nicht, denn so sollte es nicht gemacht werden.

• Stil ist langweilig .

• Dem Stil zu folgen ist langweilig .

• Das Schreiben eines Dokuments im Coding-Stil ist langweilig ( und verdammt schwierig ; probieren Sie es erst aus, wenn Sie mehr als zehn Jahre mit der Sprache gearbeitet haben).

• Das Lesen eines Dokuments ist langweilig .

• Das Überprüfen des Codes auf Stilfehler ist langweilig .

• Zu behaupten, mein Stil sei besser als deins, ist aufregend , besonders wenn es keinen objektiven Vorteil eines Stils gegenüber einem anderen gibt. Im Ernst, jeder gesunde Mensch weiß, dass der richtige Weg zu schreiben der if (x)ist, wie ich es geschrieben habe, nicht if(x)oder if ( x )!

Deshalb:

• Mach keine Style Reviews. Dies ist die Aufgabe von Stilprüfern. Diese niedlichen Anwendungen haben ein paar Vorteile für Ihr Gehirn: Sie überprüfen das gesamte Projekt in Millisekunden, nicht in Stunden oder Tagen, und sie machen keine Fehler und verpassen keine Stilfehler.

• Schreiben Sie nicht Ihren eigenen Stilstandard. Sie werden es sowieso falsch machen, und Ihre Mitarbeiter werden Sie verärgern, dass Sie schlechte Entscheidungen getroffen haben.

• Zwingen Sie Entwickler nicht, 2 000 Stilfehler zu beheben.

• Stil beim Festschreiben automatisch erzwingen. Code, der Stilfehler aufweist, hat keinen Platz in der Versionskontrolle.

• Mach es von Anfang an. Das Einrichten der Stilsteuerung in einem vorhandenen Projekt ist schwierig bis unmöglich.

Weitere Informationen über das Lesen des ersten Abschnitts von dieser anderen Antwort auf SE.SE .

Ebenfalls:

• Sei nicht zu streng. Zum Beispiel ist das Schreiben von jslintkonformem Code ziemlich ärgerlich, daher sollte dies ausschließlich dann erfolgen, wenn es unbedingt benötigt wird (oder wenn alle Mitglieder Ihres Teams damit zufrieden sind). Gleiches gilt für statische Prüfwerkzeuge. Zum Beispiel kann die .NET-Code-Analyse auf maximaler Ebene sehr bedrückend und deprimierend sein und wenig Nutzen bringen. Das gleiche Toolset auf moderatem Niveau erweist sich dagegen als sehr hilfreich.

Code-Überprüfungen

Jetzt, da Sie sich bei Code-Überprüfungen nicht mehr um den Stil kümmern müssen, können Sie sich auf interessantere Dinge konzentrieren: Verbessern (oder Korrigieren) des Quellcodes.

Verschiedene Personen reagieren unterschiedlich auf Codeüberprüfungen. Einige halten es für eine Chance. Andere hassen es. Einige hören sich alles an, was Sie ihnen sagen, machen sich Notizen und diskutieren nicht, auch wenn sie Recht haben könnten. Andere versuchen, über jeden Punkt zu streiten. Es liegt an Ihnen, einen Weg zu finden, mit jeder Entwicklerin entsprechend ihrer Persönlichkeit umzugehen. Es ist normalerweise hilfreich:

• Führen Sie Code-Überprüfungen privat durch, insbesondere wenn der Entwickler jünger ist und einen wirklich schlechten Code schreibt.

• Zeigen Sie, dass es nichts Persönliches gibt: Sie überprüfen den Code, nicht die Fähigkeiten der Person.

• Zeigen Sie das eigentliche Ziel einer Codeüberprüfung an. Das Ziel ist nicht zu zeigen, wie schlecht ein Entwickler ist. Ziel ist es, Verbesserungsmöglichkeiten zu schaffen.

• Streite niemals. Sie sind nicht hier, um zu überzeugen, sondern um Ihr Fachwissen zur Verfügung zu stellen.

• Gehen Sie niemals davon aus, dass der Rezensent der einzige ist, der aus einer Rezension etwas lernen kann. Sie sind auch hier, um zu lernen, indem Sie den Code lesen und nach Erklärungen zu den Teilen fragen, die Sie nicht verstehen.

Stellen Sie nach Abschluss der Codeüberprüfung sicher, dass die Person ihren Code tatsächlich verbessert. Ich hatte einige Fälle, in denen Entwickler dachten, dass die Codeüberprüfung endet, wenn das eigentliche Meeting endet. Sie verlassen und kehren zu ihren neuen Funktionen zurück und versuchen, das, was Sie mit ihnen geteilt haben, nur für neuen Code anzuwenden. Ein anständiges Tracking-Tool für die Codeüberprüfung hilft.

Beachten Sie, dass unabhängig von Ihrer speziellen Rolle im Unternehmen und Ihrem Fachwissen im Vergleich zu anderen Ihr Code ebenfalls überprüft werden sollte. Sie sollten auch nicht der einzige sein, der den Code anderer überprüft.

In einem kürzlich durchgeführten Projekt, in dem ich als technischer Leiter gearbeitet habe, fiel es mir schwer, meinen Mitarbeitern zu erklären, dass es ihre Aufgabe ist, den Code des jeweils anderen zu überprüfen, einschließlich meines Codes. Die Angst vor einem Praktikanten, der den Code seines technischen Leiters überprüfen will, verschwindet, sobald er die ersten Probleme im Code findet - und wer von uns schreibt fehlerfreien Code?

Ausbildung

Code Reviews sind eine großartige Gelegenheit, einige Aspekte der Programmierung und des Softwaredesigns zu lehren und zu lernen, andere erfordern jedoch eine Schulung.

Wenn Sie Ihre Mitarbeiter ausbilden können, tun Sie das. Wenn Ihr Management die Idee des Trainings ablehnt, tun Sie dies informell. Ich habe solche Schulungen in Form von informellen Besprechungen oder sogar als einfache Diskussionen durchgeführt, die manchmal vom Management unterbrochen und später fortgesetzt wurden.

Vergewissern Sie sich neben der direkten Schulung, dass Sie die Bücher wie McConnels Code Complete gut genug kennen , und sprechen Sie mit Ihren Kollegen über diese Bücher. Schlagen Sie ihnen vor, den Quellcode von Open-Source-Projekten zu lesen, und geben Sie ihnen spezifische Beispiele für hochwertigen Code. Und natürlich schreiben Sie selbst hochwertigen Code.

Konzentrieren Sie sich auf den Kontext, nicht auf Personen

Wie kann ich diese Situation angehen, ohne mich nur auf "schlechte Unternehmenskultur", "unerfahrene Absolventen" usw. zu konzentrieren?

Diese Absolventen haben ein Ziel: Erfahrungen sammeln, Dinge lernen, geschickter werden. Wenn sie Jahr für Jahr beschissenen Code schreiben und nichts über Programmierung wissen, liegt das wahrscheinlich daran, dass Ihr Team oder Ihr Unternehmen ihnen diese Möglichkeit nicht bietet.

Wenn Sie sich auf die Tatsache konzentrieren, dass Ihr Team unerfahrene Absolventen hat, hilft dies nichts. Konzentrieren Sie sich stattdessen darauf, was Sie für sie und mit ihnen tun können. Codeüberprüfungen und Schulungen sind zwei der Techniken, um die Situation zu verbessern.

Schlechte Unternehmenskultur ist ein anderes Biest. Manchmal kann es geändert werden. Manchmal kann es nicht. In allen Fällen, denken Sie daran , dass Sie sind Teil dieser Gesellschaft, so dass Sie sind Teil der Unternehmenskultur. Wenn du es nicht ändern kannst und es von Natur aus schlecht findest, musst du früher oder später gehen.

Holen Sie sich Ihre Metriken richtig

Wie genau messen Sie gerade den Code? Messen Sie die Anzahl der Commits pro Tag und Entwickler? Oder die KLOC pro Monat pro Programmierer? Oder vielleicht die Code-Abdeckung? Oder die Anzahl der gefundenen und behobenen Fehler? Oder die Anzahl der potenziellen Fehler, die durch Regressionstests entdeckt wurden? Oder die Anzahl der vom Continuous Deployment-Server durchgeführten Zurücksetzungen?

Dinge, die Sie messen, sind wichtig, weil die Teammitglieder ihre Arbeit an die gemessenen Faktoren anpassen. Beispielsweise wurde in einem Unternehmen, in dem ich vor einigen Jahren arbeiten musste, nur die Zeit gemessen, die man im Büro verbringt. Es erübrigt sich zu erwähnen, dass dies nicht dazu ermutigend war, besseren Code zu liefern, intelligenter zu arbeiten oder ... naja, überhaupt zu arbeiten.

Das Herausfinden von positiven und negativen Verstärkungen und das Anpassen der gemessenen Faktoren über die Zeit ist im Wesentlichen die Hebelwirkung, die Sie auf die Teammitglieder ausüben. Wenn es richtig gemacht wird, können Ergebnisse erzielt werden, die mit einer einfachen Hierarchie nicht erreicht werden können.

Die Dinge, die dich stören, machen sie messbar. Messen Sie sie und veröffentlichen Sie die Ergebnisse. Arbeiten Sie dann mit anderen Teammitgliedern zusammen, um die Ergebnisse zu verbessern.

Nehmen wir zum Beispiel an, dass Teammitglieder zu viele Rechtschreibfehler in den Namen von Klassen, Klassenmitgliedern und Variablen machen. Das ist nervig. Wie können Sie das messen? Mit einem Parser können Sie alle Wörter aus dem Code extrahieren und mithilfe einer Rechtschreibprüfung das Verhältnis von Wörtern mit Fehlern und Tippfehlern ermitteln, z. B. 16,7%.

Der nächste Schritt besteht darin, mit Ihrem Team das Zielverhältnis zu vereinbaren. Es könnten 15% für den nächsten Sprint sein, 10% für den nächsten, 5% in sechs Wochen und 0% in zwei Monaten. Diese Metriken werden bei jedem Commit automatisch neu berechnet und auf einem großen Bildschirm im Büro angezeigt.

• Wenn Sie das Zielverhältnis nicht erreichen, kann es sein, dass Ihr Team mehr Zeit darauf verwendet, Rechtschreibfehler zu beheben. Oder Ihr Team könnte es für besser halten, das Verhältnis pro Entwickler zu berechnen und diese Informationen auch auf der großen Leinwand anzuzeigen. Oder Ihr Team könnte feststellen, dass das Ziel zu optimistisch war und Sie es überprüfen sollten.

• Wenn Sie das Zielverhältnis erreichen, müssen Sie im nächsten Schritt sicherstellen, dass die Anzahl der Fehler und Tippfehler mit der Zeit nicht zunimmt. Zu diesem Zweck können Sie in Ihrem Build eine zusätzliche Aufgabe erstellen, die Rechtschreibfehler überprüft und den Build fehlschlägt, wenn mindestens ein Fehler gefunden wird. Nachdem Sie dieses Problem behoben haben, wird Ihr großer Bildschirm möglicherweise erneut verwendet, um die neuen relevanten Statistiken anzuzeigen.

Fazit

Ich glaube, dass jeder in Ihrer Frage erwähnte Aspekt durch die Techniken gelöst werden kann, die ich in meiner Antwort angegeben habe:

• Als andere Entwickler dem Projekt beitraten, bemerkte ich, dass sie einen anderen Codierungsstil verwenden (manchmal einen völlig anderen Stil).

  Sie mussten den Stil beim Festschreiben automatisch erzwingen .

• und verwenden häufig keine modernen Sprachfunktionen wie Property Accessors (dies ist in Objective-C relativ neu).

  Sowohl die Codeüberprüfung als auch die Schulung dienen dazu, Ihre Sprachkenntnisse zu übertragen.

• Manchmal erfanden sie ihre eigenen Fahrräder, anstatt ähnliche Merkmale des Frameworks zu verwenden

  Sowohl die Codeüberprüfung als auch die Schulung dienen dazu, Ihr Wissen über das Framework zu übertragen.

• oder übertragen Sie Konzepte aus anderen Programmiersprachen oder Mustern, die sie gelernt haben, in unsere Codebasis.

  Das ist eine hervorragende Sache. Scheint eine Gelegenheit für Sie zu sein, von ihnen zu lernen.

• Oft können sie Methoden oder Variablen wegen schlechten Englisch nicht richtig benennen

  Codeüberprüfungen sollten sich auch auf die richtige Benennung konzentrieren. Einige IDEs verfügen auch über eine Rechtschreibprüfung.

• Manchmal denke ich, wenn die IDE nicht wäre, würden sie den gesamten Code ohne Einrückung oder Formatierung schreiben.

  Natürlich würden sie. Stil ist langweilig und sollte automatisiert werden.

• Grundsätzlich hasse ich den Code, den sie schreiben.

  Denken Sie aus dem Teil mit den Codeüberprüfungen daran: „Das Ziel ist es nicht zu zeigen, wie schlecht ein Entwickler ist. Ziel ist es, Verbesserungsmöglichkeiten zu schaffen. “

• Es ist schlecht formatiert / organisiert und unterscheidet sich manchmal radikal vom Rest des Projekts.

  Automatisierte Stil Prüfung.

• Ich bin sehr verärgert, als sie ihre Spaghetti zu meinem Kunstwerk hinzufügen

  Warte was?! Kunstwerk?! Erraten Sie, was? Einige Personen (einschließlich Ihnen in sechs Monaten) könnten Ihren Code weit davon entfernt finden, ein Kunstwerk zu sein. In der Zwischenzeit sollten Sie sich darüber im Klaren sein, dass es niemandem hilft, Ihre Arbeit als Kunstwerk und ihre Arbeit als Mist zu betrachten. Dich mit einbeziehend.

• Es fühlt sich immer mehr so ​​an, als ob sie sich nicht die Mühe machen zu lernen oder es ihnen egal ist: Sie tun nur das, was von ihnen verlangt wird und gehen nach Hause.

  Natürlich werden sie das tun, was von ihnen verlangt wird. Denken Sie daran: Kontext, nicht Personen und machen Sie Ihre Metriken richtig . Wenn der Kontext von ihnen verlangt, dass sie das Beste daraus machen, was sie tun, werden sie es tun. Wenn der Kontext es erfordert, so viele KLOCs pro Monat wie möglich zu produzieren und nicht mehr, werden sie es auch tun.

Implementieren Sie Codierungsstandards und halten Sie sich an diese, Entwurfsmuster, Codeausschnittbibliothek, die Sie als Richtlinien verwenden können usw.

Codierungsstandards können von der Entscheidung reichen, ob Leerzeichen oder Tabulatoren verwendet werden sollen, welche Entwurfsmuster verwendet werden sollen, Benennungskonventionen usw. Dies wird einen langen Weg gehen, auch wenn jeder anders codiert.

Wenn möglich, implementieren Sie Codierungsstandards und Codeüberprüfungen, um mit der Überprüfung jedes einzelnen Eincheckens zu beginnen. Mit einem kleinen Team wird es für Leute, die nicht verstehen, dass Sie 20x oder 30x mehr Entwicklungszeit sparen, wenn Sie 2x oder 3x mehr für Ihren Code im Voraus ausgeben. Aber das ist ein anderes Konzept, das es wert ist, gekauft zu werden -in auf.

Ich würde nicht versuchen, alles auf einmal zu implementieren, und ich würde mein Bestes geben, um sie dazu zu bringen, auch Standards zu entwickeln - nicht nur Einrückungen, sondern sie dazu zu bringen, über Dinge nachzudenken, die ihnen in ihrem Code begegnet sind machten ihr Leben leichter oder schwerer.

Überlegen Sie sich, an einem Tag in der Woche zu besprechen, was in dieser Woche für jede Person richtig oder falsch gelaufen ist. Sie können jeder Person auch die Möglichkeit bieten, zu sagen, was eine andere Person in dieser Woche am hilfreichsten getan hat . Sie können in XP / Agile-Büchern nach weiteren Ideen suchen. Auch dies könnte als kleines Team schwer zu verkaufen sein.

Sie haben Sprachprobleme angesprochen. Wenn diese Mitarbeiter vor Ort sind (entweder Vor-Ort-Vertragspartner oder Vollzeitmitarbeiter), sollte dies kein allzu großes Problem sein, aber wenn es sich um ausländische Vertragspartner handelt, die remote arbeiten - lassen Sie mich nur sagen, dass dies nach meiner persönlichen Erfahrung niemals der Fall ist Fahren Sie es entweder aus, bis das Management feststellt, dass es nicht funktioniert, oder ziehen Sie in Betracht, das Unternehmen zu verlassen. Gehen Sie nicht in eine Situation, in der Sie für ihre Arbeit verantwortlich sind, und verschwenden Sie keine Zeit damit, die Entwicklungspraktiken des Teams zu korrigieren. Höchstwahrscheinlich wird Ihr Job dazu führen, dass Sie 100% Ihrer Zeit damit verbringen, dass der Code funktioniert. Viele ausländische Auftragnehmer sind im Übrigen hervorragende Programmierer, ich beziehe mich nur auf den Fall, in dem die Vertragsfirma Ihnen die Art von Talent geschickt hat, die Sie beschrieben haben.

Die Symptome, die Sie beschreiben, deuten stark auf einen Mangel an Teamzusammenhalt hin .

In einer solchen Situation sind Kodierungsstandards, Schulungen, Verfahren oder Werkzeuge nicht das A und O, das die Qualität erheblich verbessern könnte. Sie müssen zuerst einen Teamgeist, eine offene und konstruktive Kommunikation und eine gemeinsame Verantwortung für das Produkt entwickeln.

Symptome:

• "sie machen einfach was nötig ist und gehen nach hause": sound sie sind demotiviert. Waren sie bei ihrer Ankunft nicht begeisterter?
• "sie" gegen "uns" / "mich" / "ich": mangelndes gegenseitiges Vertrauen?
• "Ich habe ein paar Tipps gegeben: Ich habe PR zu Git kommentiert": Der Ton der schriftlichen Kritik wird manchmal trotz konstruktiver Absicht als aggressiv oder arrogant interpretiert. Warum nicht persönlich darüber diskutieren?

Sie sind ein kleines Team: Nutzen Sie diesen Vorteil! Einige Ideen zum Starten:

• Treffen Sie wichtige Entscheidungen gemeinsam. Diskutiere offen über Meinungsverschiedenheiten. "Diskutieren" heißt nicht, einen Standpunkt aufzuzwingen, sondern zuzuhören und zu versuchen, eine gemeinsame Basis zu finden.
• Sie haben wichtige Teile des Codes überarbeitet, so dass Sie eine wirklich starke Eigentümerschaft haben. Lassen Sie sie einkaufen. Lassen Sie sie ein Wort zu sagen haben.
• Und für sehr heikle, aber sehr subjektive Themen wie die Formatierung von Code lagern Sie die Aufgabe einfach an einen automatisierten, hübschen Drucker aus, der sich nach dem Standard neu formatiert, ohne sich bei jedem Einchecken zu fühlen.

Zitat des Tages:

Wenn du schnell gehen willst, geh alleine. Wenn Sie weit gehen wollen, gehen Sie zusammen

Ihre Frage kann durch "Ändern Sie Ihre Firma oder ändern Sie Ihre Firma" beantwortet werden. Für diejenigen, die es nicht wissen, bedeutet dies, dass Sie bleiben und kämpfen, um die Veränderung herbeizuführen, die Sie in Ihrem Unternehmen sehen möchten, oder das Unternehmen, für das Sie arbeiten (dh verlassen und an einem anderen Ort arbeiten).

Der zweite Teil ist der einfachste. Sie verlassen und finden ein Unternehmen, das dieselben Werte teilt, nach denen Sie arbeiten. Das erste ist nicht so einfach, weil ... Leute.

Was Sie tun müssen, ist, die Menschen zu verändern. Der Gedanke, dass sie kaputt sind und Sie sie reparieren müssen, wird nicht funktionieren. Menschen sind emotionale Wesen. Dies kann in persönlichen Kriegen leicht ausarten. So...

Zunächst müssen Sie herausfinden, warum die Situation so ist, wie sie ist. Sprechen Sie mit allen. Rausfinden. Was Sie jetzt sehen, ist das Ergebnis von Entscheidungen, die im Laufe der Jahre getroffen wurden (oder vielleicht einige wichtige Entscheidungen nicht zum richtigen Zeitpunkt treffen). Beurteile nicht und springe nicht zu Schlussfolgerungen.

Wurde dies von unerfahrenen Entwicklern verursacht? Hat das Management versucht, die Kosten zu senken, indem günstige Absolventen anstelle erfahrenerer und teurerer Entwickler eingestellt wurden? Geht es um Leute, die faul und böse sind, oder um Leute, die von einem kaputten System besiegt wurden? Zwingen Sie Ihre Fristen dazu, das zu tun, was getan werden muss, damit es funktioniert, oder verschwenden die Leute nur ihre Zeit und kümmern sich nicht allzu sehr darum, woran sie arbeiten? etc.

Das Problem in diesem Bereich der Softwareentwicklung ist, dass die Leute im Job lernen. Wenn sie in einer beschissenen Umgebung arbeiten, werden sie schlechte Gewohnheiten erlernen. Und Gewohnheiten neigen dazu zu bleiben und sind schwer zu schütteln. Dann wissen sie es nicht besser, denn das ist alles, was sie wissen. Nicht alle Entwickler sind begeistert von dem, was sie tun, um Zeit in das Verbessern oder Verbessern zu investieren. Einige sind aus verschiedenen anderen Gründen in dieses Geschäft eingestiegen. Finden Sie heraus, warum Menschen so sind, wie sie sind.

Dann gibt es Management. Ist sich das Management der Situation nicht bewusst oder ist es ihm einfach egal? Rausfinden. Sie benötigen unbedingt die Unterstützung des Managements, wenn Sie die Dinge verbessern möchten. Wenn etwas, das plötzlich 3 Monate in Anspruch nahm, 4 Monate in Anspruch nahm, weil Sie jetzt Tests schreiben, Codeüberprüfungen durchführen, am Whiteboard mit dem Team diskutieren müssen, um über gute Lösungen, Paarprogramme usw. zu entscheiden, können Sie es sein Stellen Sie sicher, dass das Management den Zeitunterschied bemerkt. Etwas, das sich zwischen 3 und 4 Monaten ändert, ist leicht zu beobachten und zu messen. Eine solide Codebasis, ein wartbares Produkt, eine gute stabile Architektur und Dinge, die zu einer besseren Produktstruktur führen, sind nicht so einfach zu messen. Wie viel Zeit die Best Practices Ihnen langfristig einräumen, lässt sich nicht im Voraus messen, vielleicht auch nicht nachträglich. Auf der anderen Seite, eine Verzögerung von einem Monat ist ein Kinderspiel. Bitten Sie das Management um Unterstützung. Bereite dich auf einen harten Verkauf vor.

Schauen Sie sich auch den Kontext des Geschäfts an. Beeinträchtigt dies Ihre Arbeitsweise? Haben Sie Möglichkeiten, die Sie um jeden Preis einhalten müssen, einschließlich der Beeinträchtigung der Codequalität oder der Best Practices?

Lassen Sie uns für einen Moment die Perspektive wechseln.

Ich bin sehr verärgert, wenn sie ihre Spaghetti zu meinem Kunstwerk hinzufügen, und das beeinflusst meine Arbeitsstimmung und meine Produktivität.

Entschuldigung ... Ihr was? Kunst? Ich weiß, die meisten von uns sind hier, um von Gleichaltrigen anerkannt zu werden, und das bekommen Sie nur, wenn Sie ein guter Entwickler sind. Wird Ihr Code jedoch in einem Museum neben einem Gemälde angezeigt? Muss es bei den Betrachtern Emotionen auslösen? Freudentränen und Glückseligkeit? Ja, ich bin sarkastisch und übertreibe absichtlich, weil ich sagen möchte, dass ich einen Sinn für die Realität habe. Lass dich nicht emotional an deinen Code binden.

Früher habe ich mit einem Mann zusammengearbeitet, der das Team, das Projekt und die Firma gerne unter den Bus geworfen hat, um allen seine "Kunst" aufzuzwingen. Er war der "Wahrheitsträger" und per Definition war jeder nur unerfahren, blind, lernunwillig, egal oder einfach nur dumm. Werde nicht dieser Typ. Als Softwareentwickler besteht Ihre Aufgabe darin, guten Code, getesteten Code, wartbaren Code und Code zu schreiben, der den geschäftlichen Wert erhöht und dies auch in Zukunft unter ständigen Änderungen tun kann. Und das alles unter Budget- und Zeitbeschränkungen. Das bedeutet es, ein professioneller Softwareentwickler zu sein. Kunst ist schlecht fürs Geschäft, es sei denn, Sie sind eine Kunstgalerie. Seien Sie pragmatisch und behalten Sie eine ausgewogene Sicht auf die Dinge. " Wie man schlechten Code, den meine Mitarbeiter schreiben, ignoriert und sich nur auf die Arbeit konzentriert"Ihre Frage wurde geschlossen, weil Sie das Problem so formuliert haben. Treten Sie zurück und schauen Sie sich das Ganze an.

Wie kann ich diese Situation angehen, ohne mich nur auf „schlechte Unternehmenskultur“, „unerfahrene Absolventen“ usw. zu konzentrieren und die Situation tatsächlich zu verbessern?

TL; DR: Sehen Sie sich die Situation genau an, um herauszufinden, warum die Dinge in dieser Situation endeten. Akzeptieren Sie, dass die Situation so ist, und sehen Sie, wie Sie sich von dort aus verbessern können. Finden Sie heraus, was jeder dazu meint. Wähle deine Schlachten. Das Erzwingen von Änderungen funktioniert nicht. Arbeiten Sie zusammen, um die Änderungen vorzunehmen. Sie sollten versuchen zu zeigen, wie Dinge verbessert werden können, ohne darauf hinzuweisen, wie schlimm sie sind. Überzeugen Sie alle, dass Sie auf lange Sicht etwas für das Allgemeinwohl tun wollen. Holen Sie sie an Bord.

Und das in kleinen Schritten.

Wenn Sie zu viel Veränderung auf einmal bringen, fühlen sich die Menschen entmutigt und geben auf. Änderungen brauchen Zeit. Ändern Sie Ihre Firma oder ändern Sie Ihre Firma. Viel Glück!