Wie sage ich meinen Kollegen, dass die von ihnen erstellte Codebasis ein totales Durcheinander ist und ihre Praktiken uralt sind?

tl;dr

Das ist kein technisches Problem, sondern ein Menschenproblem. Behandle es als solches.

Ich ändere nichts!

Sie haben einen wirklich schlechten Start hingelegt und es hat nichts mit dem Code zu tun.

Es hört sich so an, als ob Ihre Menschenkenntnis fehlt. Sie stürzen sich nicht in einen neuen Job und sagen dem aktuellen Team, wie schlecht es ist.

Menschen mögen keine Veränderungen. Und sie mögen es wirklich nicht von dem "Neuen".

Ich möchte auf der niedrigen Ebene beginnen (z. B. "dieser Code ist langsam/falsch/ineffizient") und dann langsam zur hohen Ebene übergehen (z. B. Iterationen vs. Wasserfall). Aber ich fürchte, sie denken, ich würde sie angreifen, was nicht der Fall ist.

Ich bin mir nicht sicher, in welcher Kultur Sie leben, aber jemandem zu sagen „dieser Kodex ist falsch, ich bin besser und Sie sollten es so machen“, wird immer ein Angriff sein.

Was zu tun ist?

1. Hören Sie auf, „ich gegen sie“ zu denken. Es sei denn, Sie planen aufzuhören, Sie sind Teil dieses Teams. Es sind nicht diese „schrecklichen Entwickler“ gegen „Ich der Superstar“, und wenn Sie dies Ihrem Team mitteilen, WERDEN Sie Probleme bekommen. Niemand wird jemals Ihre Ideen respektieren. Es spielt keine Rolle, ob das Team als Einzelpersonen arbeitet. Es ist immer noch ein Team und Sie bezeichnen es sogar als solches.
2. Finden Sie heraus, ob die Erwartungen erfüllt werden. Erfüllt das Team die Erwartungen/Wünsche des Managers? Wenn dies der Fall ist, werden Sie bei niemandem viel Motivation finden, sich zu verbessern. "Wenn es nicht kaputt ist, repariere es nicht." Aber wenn das Team Schwierigkeiten hat, die Leistungsziele zu erreichen, haben Sie eine andere Herangehensweise und können alles so präsentieren: „Hey, wir halten keine Fristen ein – wollen Sie versuchen, das zu ändern? Ich denke, X könnte es tun hilf uns dabei."
3. Sie sind nicht der Manager, Ihr Chef ist es. Es hört sich so an, als ob Sie den gesamten Prozess selbst verwalten möchten. Das funktioniert hervorragend – für Manager/Teamleiter. Es ist wichtig, den Input Ihres Chefs einzuholen.
4. Menschen interessieren sich mehr für Ergebnisse als für verschwommene Gefühle. Ihr Vorgesetzter wird sich viel mehr um Ihre Perspektive kümmern, wenn Sie tatsächlich zeigen, warum das, was Sie sagen, besser ist als der aktuelle Stand. Nicht nur, "weil das Internet es so sagt!" sondern eigentlich durch demonstrieren.
5. Bitten Sie die Leute um Hilfe. Finden Sie Wege, um Teamvertrauen aufzubauen. Um Hilfe/Anleitung zu bitten, ist eine super einfache Möglichkeit, dies zu tun. Auch wenn es geringfügig ist, tun Sie dies mit Ihrem Team. Sie werden dich viel mehr respektieren, wenn du tatsächlich zeigst, dass du auf ihre Meinung hörst.
6. Mit gutem Beispiel vorangehen. Menschen, die sich nicht ändern wollen, nehmen normalerweise keine neuen Informationen auf und sagen: „Du weißt, dass du recht hast. Menschen verändern sich, indem sie kleine Dinge langsam und nachhaltig verändern. Das können Sie demonstrieren.
7. Wählen Sie Ihre Schlachten mit Bedacht aus. Ihr Beispiel klingt so, als ob Ihr grundlegendes Problem darin besteht, dass das Team Leute hat, die ihre Arbeit schlecht machen. Ist es wirklich so schlimm , wenn Code ineffizient ist? Beeinflusst es tatsächlich die Endleistung? Oder Sie konzentrieren das nächste Projekt auf Iterationen vs. Wasserfallangelegenheiten (beachten Sie, dass Sie Ihren Chef besser an Bord holen sollten, wenn Sie sich auf agile vs. Wasserfallarten konzentrieren).

Das ist nicht der richtige Ansatz. Alles, was Sie tun werden, ist, Ihre Kollegen zu entfremden. Wie sehr würden Sie es begrüßen, wenn jemand es auf sich nehmen würde, all Ihre Fehler zu analysieren?

Am besten arbeiten Sie mit Ihrem Manager oder Vorgesetzten zusammen, und wie Sie dies tun, ist wichtig. Anstatt all die Dinge aufzuzeigen, die Ihre Mitarbeiter falsch machen, sollten Sie sorgfältig eine Liste mit Möglichkeiten erstellen, von denen Sie glauben, dass Ihre Prozesse verbessert werden könnten und wie Ihr Unternehmen davon profitieren würde. Mit anderen Worten, greifen Sie die Mitarbeiter nicht an – weisen Sie darauf hin, was an Ihren Prozessen kaputt ist und wie das Team sich verbessern könnte, wenn diese Dinge behoben werden.

Wenn der Manager den Wert hinter dem, was Sie sagen, sieht und versteht, wird er/sie wahrscheinlich handeln; Vielleicht nicht genau die Aktion, die Sie möchten, aber die Dinge werden sich wahrscheinlich verbessern. Wenn nicht, können Sie weiterhin versuchen, durch Inspiration zu führen, und hoffentlich werden die Dinge von selbst besser. Wenn Sie jedoch irgendeine Art von Arbeitsbeziehung mit Ihren Kollegen aufrechterhalten möchten, versuchen Sie nicht, ihnen zu sagen, wie sie arbeiten sollen, wenn dies nicht in Ihrer Verantwortung liegt.

Ich würde definitiv nicht auf niedrigem Niveau beginnen - "dieser Code ist ineffizient" oder ähnliches. Das wird nur eine Menge Abwehrhaltung für sehr wenig Gewinn verursachen.

Ein agiles Projekt und ein Wasserfallprojekt zu mischen und aufeinander abzustimmen ist wahnsinnig schwierig. Die Wasserfall-Leute wollen die Schnittstelle zwischen Ihren Projekten (Dateiformat, Tabellenlayout, API, was auch immer) im Voraus festlegen, dann weggehen und an diese Schnittstelle schreiben. Sie möchten einfach mit der einfachstmöglichen Benutzeroberfläche beginnen, den Teilen, von denen Sie sicher wissen, dass Sie sie benötigen, und dann zu ihnen kommen und sagen, dass Sie etwas hinzufügen oder ändern müssen, und sie darauf reagieren lassen. Für Sie ist dies verantwortungsvoll, agil und schnell, weil Sie nicht ewig über Design gestritten haben, als Sie die Antworten unmöglich kennen konnten. Für sie ist das Cowboy, der sie herumreißt und ständig den Boden unter ihnen verändert. Es ist ein Rezept für eine Katastrophe.

Ich schlage vor, Sie zeigen diese Schwierigkeit der nächsten Person, mit der Sie arbeiten müssen. Sprechen Sie es durch und entscheiden Sie gemeinsam, ob Sie Ihre Überlappung/Interaktion zuerst vollständig gemeinsam entwerfen oder einfach beginnen und darauf vorbereitet sind, sie im Laufe der Zeit zu ändern. Hören Sie wirklich zuauf den Widerstand, den Sie von den anderen Entwicklern bekommen. Sie sind nicht automatisch falsch. Agilität ist großartig, wenn Sie alle Ihre Grenzen einhalten, aber es kann zusätzliche Arbeit verursachen, wenn Sie dies nicht tun. Bei einigen Projekten ist diese zusätzliche Arbeit immer noch geringer als die Tage oder Wochen des Spekulierens und Streitens, die zur Erstellung eines suboptimalen Designs geführt haben, an dem Sie festhielten. Aber nicht bei allen Projekten. In diesem Fall kann es sinnvoll sein, die Grenze zwischen Ihnen und dem anderen Entwickler vollständig zu entwerfen, bevor jemand beginnt. Dann machen Sie weiter und seien Sie in Ihrem Silo agil.

Für das größere Problem, dass Sie denken, dass sie (a) beschissenen Code schreiben, (b) agil sein sollten wie Sie, (c) eine konsistente und moderne Toolbase verwenden sollten und (d) mehr Tests durchführen und mehr Code untereinander austauschen sollten Projekte - gehen Sie hier sehr vorsichtig vor. Sie haben versucht, einfach großartig zu sein und zu sehen, ob sie Sie kopieren wollen, und sie tun es nicht. Es ist mir überhaupt nicht klar, dass Sie die Vorteile für sie sehen, wenn sie so bleiben, wie sie bisher waren. Sie werden sie niemals dazu überreden, ihre Verhaltensweisen zu ändern, ohne zu verstehen, warum sie es (über die Trägheit hinaus) nicht tun. Sie werden wahrscheinlich auch die ausdrückliche Unterstützung Ihres Vorgesetzten benötigen, um eine „Best Practices“-Kampagne zu leiten, die bestehenden Code drastisch ändert und diesen Entwicklern beibringt, wie es von nun an zu tun ist. Machst du es alleine? Sie werden dich einfach weiter abwimmeln, weil sie es nicht tun

Ich habe in meiner Vergangenheit versucht, mich an die folgenden Prinzipien zu halten, und es schien gut zu funktionieren:

• Ich habe mich gezwungen, mit einer "ruhigen Lernphase" zu beginnen: Für einen Zeitraum von einigen Monaten oder so,

  Sei ruhig und lerne. Verurteile nichts. Integrieren Sie sich in das Team und das Unternehmen. Seien Sie produktiv. Bauen Sie Vertrauen und Reputation auf. Zeigen Sie Ihre Kompetenz.

  (Ich nehme an, Sie haben auch schon eine ähnliche Einstellung ausprobiert.) Oft sieht man Dinge, die man schlecht findet, aber ein paar Wochen später weiß man, warum sie so sind, wie sie sind.

• Wenn Sie Probleme bemerken oder mit Dingen konfrontiert werden, die Ihrer Meinung nach nicht optimal sind,

  Daten sammeln: Stunden, die für eine einfache Änderung aufgewendet werden, Bugs, die auftauchen, wütende Mails, die herumgeschickt werden, usw.

  Jede Änderung, die Sie jemals vorschlagen möchten, erfordert Fakten, die zeigen, dass sie notwendig und hilfreich ist. Ich mache mir gerne Notizen in meinem persönlichen "Tagebuch" (einem dieser guten alten Blankobücher aus echtem Papier).

  In einem meiner Projekte hatte ich das Gefühl, dass eine Änderung sehr teuer war, insbesondere weil es keine automatisierten Tests gab und manuelles Testen sehr umständlich war. Also verfolgte ich die Stunden, die ich für jede Aufgabe aufgewendet hatte, und trennte die Stunden für die tatsächliche Implementierung von den Teststunden.

• Nach einer Weile werden Ihnen Ihre Beobachtungen (oder Notizen) helfen

  Verschaffen Sie sich ein klares Bild von den Hauptproblemen. Finde sie (nur!)

  Ich kann mir nicht vorstellen, dass Sie das "von unten nach oben" tun können, wie Sie es erwähnt haben. Es ist eher von oben nach unten: Ein Problem taucht auf und Sie versuchen, die Ursache dafür zu finden.

• Gehen Sie immer nur auf ein Problem ein. Verwenden Sie die Daten, die Sie zur Hand haben, und versuchen Sie es

  Erarbeiten Sie einen Vorschlag zur Verbesserung dieses einen Problems,

  Zeigen Sie das Problem und den potenziellen Gewinn anhand Ihrer Daten. Nutze einen guten Moment und wähle den am wenigsten anstößigen Weg. Versuchen Sie auch, eine möglichst kleine Änderung mit der größten positiven Wirkung vorzuschlagen. Kleine Änderungen werden viel eher vom Team akzeptiert/genehmigt als große.

• Zeigen Sie niemals mit dem Finger. Machen Sie sich zu einem wertvollen Freund für jedes Ihrer Teammitglieder.

  Du machst übrigens auch Fehler. Und ich schätze, meistens sind schlechte Dinge, denen Sie begegnen, nicht von einem „Bösen“ „gemacht“. Sie haben sich entwickelt, weil man sich nicht genug darum gekümmert hat, das zu verhindern. Es ist immer ein guter Rat, Menschen nicht für ein Problem verantwortlich zu machen, sondern sich mit den Prozessen, der Art und Weise, wie das Team zusammenarbeitet, usw. zu befassen.

Willkommen in der Geschäftswelt.

Veränderung braucht Zeit. In einem großen Unternehmen kann es Jahrzehnte dauern, bis das, was sie haben, gut genug funktioniert (und vor Jahren, als sie diese Praktiken übernommen haben, vielleicht sogar branchenführend war). Ich arbeite für IBM und verwende immer noch einige Tools, deren Backends aus der "Green Screen"-Ära stammen, weil sie funktionieren , stark in andere Tools integriert sind (und daher schwer einzeln zu ersetzen sind) und weil niemand sie gefunden hat ausreichende Mittel und Zeit, um in eine Umstellung zu investieren, die kein inakzeptables Risiko beinhaltet.

Ähnliche Probleme gelten auch auf der Ebene der Geschäftspraxis. Das Wechseln von Tools ist mit Risiken verbunden ... entweder das Risiko, die Kosten zu unterschätzen und Ihre Verpflichtungen nicht einzuhalten, oder das Risiko, sie zu überschätzen und so auszusehen, als wären Sie nicht aggressiv genug. Das Management möchte in der Lage sein, Vorhersagen zu treffen, daher haben sie möglicherweise Angst, sich so oder so zu binden und bei dem zu bleiben, was sie haben.

Veränderungen können kommen, aber sie müssen klein anfangen und nach außen getragen werden. Sie beginnen damit, ein Beispiel dafür zu geben, wie der neue Ansatz IHNEN über einen längeren Zeitraum hilft. Schließlich haben Sie genügend Beweise, um einen Teamleiter davon zu überzeugen, es in einer kleinen Gruppe zu versuchen (oder Sie werden ein Teamleiter, der dies tun kann), und zwar auf eine Weise, die den Rest des Unternehmens nicht beeinträchtigt. Bauen Sie von dort aus nach außen. Erwarten Sie, dass Veränderungen Zeit brauchen; Schlachtschiffe starten, stoppen oder wenden nicht sehr schnell.

Dito Codequalität und Codierungspraktiken. Denken Sie daran, dass Konsistenz (in der Lage zu sein, den Code des anderen zu lesen und zu pflegen) hübsch ist, und lernen Sie, mit dem von ihnen bevorzugten Codierungsstil zu arbeiten. (Ein guter Programmierer kann fast jeden Stil lesen – obwohl der Typ, der dachte, Semikolons gehörten am Anfang von Anweisungen, vielleicht eine Ausnahme war.) Denken Sie daran, dass Sie das Risiko der Einführung von neuem minimieren müssen, wenn Sie bestehenden Produktcode pflegen Bugs, was bedeutet, dass lokale Patches bevorzugt werden, es sei denn, Sie können STARKE Gründe dafür nachweisen, dass größere Patches einfacher zu erstellen und zu warten sind und Vorteile für die Kunden haben. Um dies ins rechte Licht zu rücken, denken Sie daran, dass viele Kunden Jahre alten Code anstelle der neuesten Version ausführen und nur dann aktualisieren, wenn es unbedingt erforderlich ist, gerade weil sie es sind.

Und ja, minimale Patches summieren sich zu hässlichem Code. Irgendwann wird das behoben, aber nicht vor der nächsten Hauptversion und nicht, es sei denn, es gibt ein tatsächliches Problem mit dem alten Code.

Wenn sich die Gelegenheit ergibt, etwas Neues zu implementieren, DANN können Sie erwägen, die Vorteile eines neuen Ansatzes zu nutzen. Aber Instandhaltung ist per Definition den alten Prozessen verpflichtet und verändert sich nur sehr langsam. Leider dauert es lange, bis wissenschaftliche Best Practices angenommen werden ... und oft ist zu dem Zeitpunkt, an dem sie es sind, etwas anderes das Neueste und Größte.

Nehmen Sie eine kleine Änderung nach der anderen vor, bis Sie in der Lage sind, größere Änderungen umzusetzen. Zeigen, nicht nur erzählen. Seien Sie geduldig und ausdauernd. Denken Sie daran, dass die Dinge so sind, wie sie sind, weil sie funktionieren, und lernen Sie, das aktuelle System so gut zu bedienen, dass Sie genau erklären können, was sowohl die Vorteile als auch die Risiken eines Wechsels wären.

Oder gehen Sie das risikoreiche Ding ein, Ihr eigenes Unternehmen zu gründen und die Dinge auf Ihre eigene Art und Weise zu tun ... was Ihnen schnell zeigen wird, warum alle so nervös sind, was Risiken betrifft, die sie noch nicht wissen, wie sie sie quantifizieren sollen; Irgendein junger Punk wird mit dem trendigen Ansatz dieser Woche hereinkommen und Sie müssen ihm erklären, dass die Firma auf eine saubere Gelegenheit warten muss, um zu kürzen ... und in der Zwischenzeit brauchen Sie ihn, um an dem zu arbeiten, was Sie jetzt haben , und wenn er das nicht kann, hat er keine Zukunft im Unternehmen.

Bisher gute Antworten, besonders von Roger, Enderland♦ und Kate Gregory, aber ich möchte etwas hinzufügen.

TLDR

Beginnen Sie mit den High-Level-Methoden, da sie zu einer höheren Qualität des Low-Level-Teils führen. Machen Sie Ihrem Vorgesetzten und Ihren Kollegen klar, was sie davon profitieren, wenn Sie die High-Level-Methoden hinzufügen, machen Sie ihnen den Wunsch, dass sich etwas ändert . Der einzige Weg für ihre Kultur, sich zu ändern , besteht darin, dass sie es wollen .

Ursprüngliche Antwort

Ich schlage vor, dass Sie, anstatt damit zu beginnen, den ineffizienten Code Ihres Arbeitgebers zu kritisieren, langsam anfangen und mit Ihrem Vorgesetzten zusammenarbeiten, eine nach der anderen, mit neuen Methoden, bei denen der Gewinn jedes Schrittes gründlich erklärt wird. Eine Unternehmenskultur kann sich nur ändern, wenn die Arbeitgeber eine Änderung wollen , verstehen, warum sie sich ändern sollte , und am Ende wollen sie, dass sie sich ändert .

Vorgeschlagene Reihenfolge der Methoden:

Standups - Beginnen sehr langsam

Beginnen Sie mit Stand-Ups . Wenn Sie Ihrem Vorgesetzten und Ihren Mitarbeitern verständlich machen können, dass Informationen darüber , was von wem und in welchem ​​​​Projekt getan wird, migriert werden , ist es weniger wahrscheinlich, dass Ihr Unternehmen auf den Kopf gestellt wird, wenn jemand plötzlich nicht mehr in der Lage ist, seine Arbeit fortzusetzen, was es zu einem Ärgernis macht Esel für den nächsten Arbeitgeber, der seine Arbeit abholen muss. Wenn Ihre Kollegen glauben, dass es für sie einfacher ist, die Arbeit eines anderen zu übernehmen, indem sie Informationen migrieren, indem sie nur fünf Minuten pro Tag dafür aufwenden, dann ist dies ein möglicher Anfang.

TDD - Sie sind immer noch in der Lage, ihre Aufgaben zu erledigen, aber auf strukturiertere Weise

Ich denke, es ist ein guter nächster Schritt. Es ist schwierig und fast sinnlos , Unit-Tests für Legacy-Code durchzuführen (tatsächlich ist die Definition eines Legacy-Codes laut einigen Experten eine Codebasis, die entweder keine oder wenige Unit-Tests hat), aber das Schreiben von Unit-Tests für neue Methoden stellt sicher dass die neuen Methoden tatsächlich das tun, was von ihnen erwartet wird -- was zu weniger Fehlern führt, über die die Entwickler nachdenken müssen, weniger Kosten für das Unternehmen (Ihr Manager sollte dafür gefunden werden), und es formt den Fluss der Systeme statt umgekehrt. Informieren Sie sich über testgetriebene Entwicklung (TDD) und finden Sie heraus, wieTDD wird das Leben Ihrer Kollegen erleichtern, und sie werden es am Ende tun, zumal sie es alleine tun können und nicht mit jemand anderem interagieren müssen, der es tut. Der wichtigste Teil ist, dass ein Komponententest in Sekunden oder Minuten geschrieben werden kann, wenn er vorher gemacht wird, sodass er nicht so langweilig klingt und eigentlich ineffizient und sinnlos ist, wenn er nachträglich geschrieben wird.

Erfinden Sie das Konzept von SOA - Befreien Sie sich von eng gekoppelten Systemen

Die serviceorientierte Architektur (SOA) stellt eine lose gekoppelte Architektur sicher, die es ermöglicht, dass Module von jedermann einfach ausgetauscht und gewartet werden können, ohne dass Kenntnisse über die anderen Teile des Systems erforderlich sind. Fragen Sie Ihre Kollegen, ob sie bereit sind, die super eng gekoppelten Systeme eines anderen nach fünf Jahren Entwicklung und Wartung zu warten, und fragen Sie sie, ob sie mehr daran interessiert sind, jedes einzelne Konzept im System verstehen zu müssen, oder ob sie das lieber möchten Sie müssen nur sehr kleine Teilmengen des Systems verstehen und können sogar diesen sehr spezifischen Teil von Grund auf neu schreiben, wenn sie möchten, da dies nur mit einer super objektorientierten oder SOA-Architektur möglich ist.

Code-Review – Migrieren Sie Wissen, ohne zu viel mit anderen interagieren zu müssen

Sie können Ihre Kollegen fragen, ob sie wertvoller sein möchten. Kenntnisse in den verschiedenen Systemen, die es gibt, machen sie wertvoller. Es verlagert Risiken, die Ihrem Arbeitgeber sehr gefallen werden, und es verschafft Ihren Mitarbeitern einen großen Vorteil, wenn einer von ihnen seine Arbeit nicht fortsetzen kann. 15 Minuten pro Tag würden viel verändern, und Sie würden ihnen erlauben , sich gegenseitig auf die Fehler hinzuweisen, ohne Sie wie den Bösewicht aussehen zu lassen , es sei denn, Sie sind an der Reihe, eine Bewertung abzugeben, dann ist es in Ordnung, denn nun, Sie sollten eine Bewertung abgeben der Code.

Die Liste geht weiter

Der Punkt ist, mit dem High-Level-Zeug zu beginnen; es wird in einer höheren Qualität des Materials auf niedrigerem Niveau enden.

Die Dinge, die ich zu jeder Sache gesagt habe, werden möglicherweise nicht jeden überzeugen, aber der Schlüssel ist, Ihre Mitarbeiter dazu zu bringen, sich ändern zu wollen, sonst werden sie es nicht tun. Lassen Sie sie sehen, warum sie sich ändern sollten, indem Sie die einprägsamen Teile der High-Level-Methoden finden, und die Dinge werden sich verbessern.

Sie haben drei Probleme aufgelistet. Die meisten von ihnen klingen nach akzeptablen Best Practices (daran ist nichts auszusetzen), aber es gibt eine, auf die Sie sich meiner Meinung nach konzentrieren sollten, da dies das Hauptproblem sein könnte, da jeder im Unternehmen es sehen wird: „Der gesamte Entwicklungsprozess ist langsam ..." Sie geben auch den Grund an, ineffizient.

Das Wort „agil“ wird oft herumgeworfen, aber wie all dies ist es relativ. Sie sollten sich auf einige echte Probleme konzentrieren, die jeder hat. Wie lange dauert es für Änderungswünsche? Sind die Änderungen unvollständig, dh "Der neue Fix wurde in Abschnitt A, aber nicht in Abschnitt B angezeigt. Warum nicht?" Dies sind die Dinge, die den Benutzern wichtig sind. Sie erhalten mehr Zustimmung vom Rest des Unternehmens, wenn die Ergebnisse Ihrer vorgeschlagenen Änderungen ihnen zugute kommen. Natürlich kann es für alle besser sein, Dinge schneller umsetzen zu können.

Sie erwähnen doppelten Code. Unter Programmierern ist es ein No-Go, aber für größere Projekte und insbesondere solche mit viel Legacy-Code wird das Refactoring nicht einfach sein. Theoretisch klingt das großartig, bis Sie feststellen, dass niemand dem Team die Zeit dafür auf Kosten aktueller Anfragen gewähren wird. Gegen technische Schulden zu argumentieren ist nicht einfach.

Versuchen Sie als erste Aufgabe, das Team zusammenzubringen und die Entwicklung von Codierungsstandards zu besprechen. Du bist die neue Person, also hast du das sofort erkannt. Sehen Sie, was die Reaktion aller ist. Sie können zurückgewiesen werden, weil sie sich nicht einigen können oder "wir haben es versucht, aber niemand hat sich daran gehalten". Vielleicht ist der aktuelle Schlamassel Motivation genug, um alle dazu zu bringen, etwas dagegen unternehmen zu wollen. Auch hier bekommen Sie möglicherweise nicht die Zeit.

Wenn Sie sehen, dass diese Gruppe Schwierigkeiten hat, miteinander auszukommen, beginnen Sie mit etwas Grundlegendem; zusammen Mittag essen gehen. In diesen informellen Situationen können Sie herausfinden, was die wirklichen Probleme sind. Es könnte ein Mangel an Wissen sein oder vielleicht ist das Umfeld, das in diesem Unternehmen geschaffen wird, mehr darauf bedacht, die täglichen Brände zu löschen.

Geben Sie nicht auf, aber erwarten Sie auch nicht, dass sich das über Nacht ändert. Sie haben eine große Aufgabe vor sich, mein Freund.

Wenn es nicht Ihre Aufgabe ist, ihre Arbeitspraktiken zu ändern UND Sie dies schriftlich haben, tun Sie dies nicht, denn wie andere gesagt haben, wird es nicht funktionieren.

Die Person, die das tun sollte , ist Ihr Vorgesetzter. Er ist der Typ, den Sie überzeugen müssen. Versuchen Sie es mit einem pragmatischen Appell an Effizienz, mit Beispielen.

Wenn er kein Interesse hat? Lernen Sie, damit zu leben (und stellen Sie sicher, dass Ihr Arsch bedeckt ist) oder finden Sie einen anderen Job. Es ist schrecklich, ich weiß. War dort.

(Möglicherweise geht es nicht um Menschen, sondern um Politik – oder jemand hätte sie schon vor langer Zeit auf diese Praktiken aufmerksam gemacht.)

Klingt, als wüssten Sie wirklich, was Sie tun, aber passen Sie auf, dass Sie mit Ihren neuen Kollegen nicht auf dem falschen Fuß ankommen. Wenn Sie so gut sind, sollten Sie in der Lage sein, positive Beiträge zu den Repositories jeder Person zu leisten. Die besseren Programmierer haben wahrscheinlich nichts dagegen, dass Sie ihren Code verbessern. Wenn Sie also mit ihnen arbeiten können, tun Sie dies. Diejenigen, die Ihre Verbesserungen ablehnen, sind wahrscheinlich nicht die Typen, mit denen Sie arbeiten möchten.

Aber ein Wort der Warnung: Seien Sie absolut sicher, dass Ihre Beiträge keine negativen Kompromisse haben. Wenn Ihre Vorschläge Nachteile haben, werden Sie dafür verantwortlich gemacht, wenn etwas schief geht.

Mein persönlicher Standard ist, dass ich darauf bestehe, dass alle Änderungen, die ich an Code vornehme, der von anderen entwickelt wurde, wo ich keine Dinge architektiere, absolut keine Nachteile haben (oder wenn potenziell immaterielle vorhanden sind, dh "ist es besser lesbar?", dass sie es sind minimal.) Wenn ich dies als meinen Standard verwende, kann ich immer noch:

• Code umgestalten, Unittests schreiben und verbessern, spezifischere Ausnahmen auslösen
• Korrigieren Sie Fehler, die aufgrund der Verwendung von veraltetem Code verursacht wurden, und ersetzen Sie Strukturen, die auslaufen, durch die neueren Konstrukte
• Reduzieren Sie Codezeilen, indem Sie integrierte Funktionen und Methoden verwenden, die den Anwendungsfall abdecken, verbessern Sie die Code-Effizienz, indem Sie die Materialisierung von Datenstrukturen eliminieren, wo sie unnötig sind, und ersetzen Sie umständlichen Kontrollfluss durch einen optimierten Kontrollfluss
• Verbesserung von Docstrings/Dokumentation (von Rechtschreibung bis Semantik) und Verbesserung des Codestils (da wir einen Styleguide haben!)

Und ich mache all das, ohne die Ein- und Ausgaben des etablierten Codes zu ändern, sodass nichts in der Produktion unterbrochen wird.

Auf diese Weise können Sie sich einen Ruf aufbauen, weil Sie wissen, was Sie tun. Dabei bauen Sie Glaubwürdigkeit bei den Wissensarbeitern auf, mit denen Sie zusammenarbeiten. Wenn Sie in der Lage sind, klobige oder schlechte Komponenten durch bessere zu ersetzen, werden sie Sie noch mehr zu schätzen wissen. Indem Sie Ihre Glaubwürdigkeit aufbauen, bauen Sie Ihre Fähigkeit auf, sie davon zu überzeugen, die Praktiken anzunehmen, von denen Sie glauben, dass sie sich auszahlen werden.

Ich war zweimal in einer ähnlichen Situation und habe wie viele andere festgestellt, dass es absolut keine Möglichkeit gibt, die Dinge zu verbessern, es sei denn, Ihre Kollegen wollen sich ändern.

Es gibt eine einfache Möglichkeit, zu testen, ob sie bereit sind oder nicht, dem Team vorzuschlagen, zu einer Konferenz zu gehen oder einen Kurs zu den relevanten Programmierthemen zu belegen. Es kann sogar Benutzergruppen oder sogar allgemeine Programmierinteressengruppen geben, die hin und wieder offene Meetings haben, die Ihr Team besuchen könnte. Schlagen Sie etwas Lesematerial oder Videos vor, die sich die Leute ansehen können (Onkel Bobs Videos funktionieren in dieser Situation wunderbar).

Damit müssen Sie nicht auf Probleme oder Fehler hinweisen, die Sie Ihrer Meinung nach machen. Die Antwort des Teams auf diese Vorschläge wird Ihnen alles sagen, was Sie darüber wissen müssen, wie sehr es daran interessiert ist, Dinge zu verbessern. Wenn sie begeistert sind, diese Dinge auszuprobieren, hast du eine Chance, wenn sie kein Interesse haben, solltest du dir das Leiden ersparen und so schnell wie möglich da raus.

Man muss darüber nachdenken, was Menschen motiviert. "Es wäre für mich einfacher, Sie in Ihrem Job zu ersetzen, wenn Sie sich an folgende Praktiken gehalten hätten:" ist kein großer Motivator: Die meisten Menschen wollen nicht ersetzt werden. Auch außerhalb einer Hire-and-Fire-Philosophie hat der Mehraufwand, so zu codieren, dass jemand anderes es übernimmt , seinen Wert, da personenunabhängiger Code es erlaubt, flexibler auf wechselnde Arbeitslasten zu reagieren.

Aber in einer Situation "niemand außer $x wird diesen Code anfassen, bevor das Projekt abgeschlossen ist" hat die Frage "Wartbarkeit durch jedermann vs. Aufwand" unterschiedliche Antworten.

In Bezug auf die Wiederverwendung von Code: Eine Philosophie von C++ besteht darin, die Tools zum Erstellen generischer Lösungen bereitzustellen. 95 % des „wiederverwendbaren Codes“, den angehende Programmierer produzieren, werden nicht wiederverwendet. Und der Grund dafür ist, dass für einen erfahrenen Programmierer bei vielen einfachen Aufgaben die Kosten der "Wiederverwendung" höher sind, als nur aus dem Stegreif zu schreiben, speziell auf den betreffenden Code zugeschnitten.

Wenn Sie einem Bestseller-Autor mitteilen, dass er mit Ihren bereits auf Rechtschreib- und Grammatikfehler vorgeprüften Textvorlagen seinen Output verdoppeln kann und er nur noch die richtigen Eigennamen und Verben einpassen muss und Sie auch einige parametrisiert haben Stellen für Adverbien – können Sie sich vorstellen, wie aufgeregt er sein wird?

Können Sie sich vorstellen, wie aufgeregt er sein wird, wenn jemand anderes seinen Roman pflegen kann, wenn er nur richtig dokumentiert und parametrisiert ist?

Und niemand möchte in Handbüchern und Dokumentationen nach irgendwelchen trivialen Dingen suchen, die er aufschreiben kann, was zumindest den Eindruck erweckt, dass es weniger Zeit und sicherlich weniger geistige Anstrengung erfordert.

Wenn Sie ein hochqualifiziertes Team von Orgelbauern haben, die an einem Instrument arbeiten, werden Sie feststellen, dass jeder sein persönliches Werkzeugset hat, das er im Laufe der Jahre selbst verfeinert hat. Und jeder hat seine eigenen Spezialgebiete und charakteristischen Arbeitsstile.

Wenn Sie sagen: „Hier ist das Management. Wir haben entschieden, dass wir Pauls Werkzeuge standardisieren werden. Auch wenn sich alle einig sind, dass Paul der beste Orgelbauer im Unternehmen ist, werden sich nur wenige über diesen Wechsel freuen. Die Werkzeuge werden für unerfahrene Bauherren wahrscheinlich nicht gut funktionieren, und sie werden für die erfahrenen anders funktionieren als ihre eigenen Werkzeuge.

Nicht einmal Paul wird glücklich sein, weil alle zu ihm rennen und ihm die Schuld geben werden.

Der Sinn eines Teams ist nicht, dass alle ersetzt werden können, sondern dass sie es schaffen, an einem stimmigen Ganzen zu arbeiten. Wenn Sie versuchen, die Prozesse auf den kleinsten gemeinsamen Nenner zu reduzieren, mit dem Sie zufrieden sind, verbessern Sie weder die Leistung noch die Arbeitsmoral.

Entwickle deinen Stil. Spielen Sie Ihre Rolle im Team. Wenn Sie es gut und überzeugend machen, wird es schließlich zu "fragen wir user1807, das klingt wie etwas, das er vielleicht in seiner Trickkiste vorgepackt hat."

Was Sie nach etwa einem halben Jahr dort überprüfen sollten, ist nicht, wie Arbeit gemacht wird, sondern wie sie kommuniziert wird: Haben Sie das Gefühl, dass Kommunikation/Teamsitzungen so ablaufen, dass die wirklich wesentlichen Räder nicht Gefahr laufen, sehr kostspielig neu erfunden zu werden? ?

Aber in der Lage zu sein, das so festzuhalten, dass die Leute Ihnen zustimmen , einschließlich „Wir könnten und wir werden es besser machen“, ist etwas, das Sie Jahre brauchen werden, um es zu erreichen.

Machen Sie die Dinge, als Teamplayer, auf Ihre Art. Sie werden sehen, wie das den Projekten hilft oder nicht, andere werden sehen, wie es den Projekten hilft oder nicht. Menschen lernen, und dazu gehören auch Sie. Und Management.

Dinge konsequent anders zu machen, als man geneigt ist, ist eine Frage der Disziplin. Selbstdisziplin ist in Ordnung, aber Sie sind nicht in der Situation, andere zu disziplinieren.

Wenn sich für das Management herausstellt, dass dies ein guter Schritt sein könnte, werden Sie irgendwann Teamleiter sein. Es hat keinen Sinn, das Management zu diesem Ergebnis zu drängen: Ein Teamleiter, der vom Team nicht akzeptiert wird, wird nichts Unpopuläres erreichen. Du würdest mauern. Seien Sie also ein guter Teamleiter für sich selbst und ein gutes Teammitglied für andere.

Problem Nr. 1: Gruppe von Individuen

Wenn ein Entwickler eine konsistente API bereitstellen und pflegen kann, warum sollten Sie sich dann um Konventionen kümmern? Sie sind die Person, die den Code kennt. Niemand sonst wird die Implementierung aufrechterhalten. Kümmern Sie sich hauptsächlich um die API.

Problem Nr. 2: Das Rad neu erfinden

Das ist in der Tat ein Problem. Gemeinsamer Code sollte in einem Unternehmens- oder Team-Repository getrennt werden. Dies sollte im Laufe mehrerer spezieller Meetings mit dem gesamten Team entschieden werden.

Problem Nr. 3: nicht agil

Bitte erkennen Sie an, dass dies agilenicht der einzig wirklich bestmögliche Ansatz für die Softwareentwicklung ist. Es sorgt für mittelmäßige Entwickler .