Die normale Situation hier wäre, dass Sie mit Kollegen und dem Management zusammenarbeiten, um die Vorteile des Umschreibens zu diskutieren, Ihre Kollegen mit ins Boot holen, Unterlagen bereitstellen, Zeitschätzungen abgeben, die Arbeit aufteilen und es angehen. Auf diese Weise erhalten Sie zuerst die Zustimmung der Manager , besprechen verschiedene Probleme als Team und erstellen einen Plan, um sie zu überwinden. Kollegen sind dann viel eher am Projekt als Ganzes beteiligt, da sie es mitbestimmen und vorantreiben können. Wenn irgendwelche Kollegen es zu diesem Zeitpunkt wirklich nicht machen wollen, dann gibt es wenig Diskussionsbedarf, da sie a) reichlich Gelegenheit hatten, den Prozess abzuwägen, und b) es vom Management als vereinbartes Projekt abgesegnet wurde, Ihre Position ist also eindeutig.

In diesem Fall scheint es jedoch so, als hätten Sie es einfach alleine gemacht (oder zumindest das meiste davon erledigt) und möglicherweise einen anderen Entwickler verärgert, der das alte System perfekt versteht, aber nicht unbedingt mit den neuen Bibliotheken vertraut ist , Tools, Technologien, Codeparadigmen und Entwicklungspraktiken, die Sie verwenden. Ja, es gibt ein gutes Argument dafür, dass er sich hätte weiterbilden und mit der Zeit gehen sollen, aber in der Praxis wird das oft nicht passieren.

Du sagst dann:

Jeder kompetente Softwareentwickler würde sich den Code ansehen und sich sofort auf meine Seite stellen

... und verzeihen Sie mir, dass ich das sage, aber das scheint ziemlich ... gewagt zu sein. Diese Dinge sind selten so schwarz und weiß.

Dieser Teil macht mich besonders nervös:

Während ich einen Teil des Codes portierte, habe ich viele Fehler gefunden, die ich auf dem Weg behoben habe, die hätten vermieden werden sollen, aber nicht sein konnten, da es keine Möglichkeit gibt, Tests für den alten Code zu schreiben, noch gibt es eine angemessene Fehlerbehandlung/Protokollierung . Alle Zeichen deuten darauf hin, dass der Umzug eine gute Idee ist.

Wenn der alte Code keine ordnungsgemäße Fehlerbehandlung, keine Komponententests usw. enthält, wie können Sie dann überprüfen, ob er sich genauso verhält? Wie können Sie sicherstellen, dass die von Ihnen behobenen "Fehler" keine Ausnahmefälle waren und sich niemand auf dieses Verhalten verlassen hat? Wie können Sie absolut garantieren , dass Sie mit dem neuen Code keine kritischen, bahnbrechenden Änderungen einführen? Das Management und die Kunden kümmern sich nicht wirklich darum, wie schön der Code ist, sie kümmern sich darum, dass er funktioniert. Wenn es bedeutet, dass die Bereitstellung länger dauert, die Kunden aber zufrieden sind und nicht gehen, dann ist das für sie ein lohnender Kompromiss.

Um die Frage hier direkt zu beantworten – Sie holen das Management an Bord, indem Sie die Zeitersparnis demonstrieren und die notwendige Dokumentation und Ressourcen bereitstellen, die erforderlich sind, um den anderen Entwickler zu qualifizieren und ihn an Bord zu holen. Das ist jedoch nicht schnell - das ist lang und hart. In Wirklichkeit, meiner Meinung nach, hättest du die Situation von Anfang an ganz anders angehen sollen.

Sie haben hier ein paar Probleme im Zusammenhang mit Ihren mangelnden Kommunikationsfähigkeiten. Ich weiß nicht, wie gut Ihr Code ist oder wie schlecht der alte Code ist, aber schauen wir uns an, was Sie hier geschrieben haben.

1. Setzen Sie andere nicht herab und kommen Sie nicht von einem Ort der Arroganz

Was ich tun muss, ist zu erklären, dass ich wesentlich mehr Erfahrung habe und diese Art von Arbeit in der Vergangenheit mit hervorragenden Ergebnissen durchgeführt habe.

Hören Sie auf, sich solche Dinge anzuschauen. Solche Appelle an Autoritäten werden niemanden überzeugen. Es spricht nicht für den Wert Ihres Codes, es hebt keine Vorteile hervor, es sagt buchstäblich nur "Ich denke, ich bin der Beste darin, also machen wir es auf meine Weise". All dies wird Ihre Teamkollegen verärgern. Nicht das, was Sie wollen, wenn Sie ihr Buy-In nicht haben.

2. Lösen Sie sich vom Fachjargon

Ich verzettele mich auch damit, eine Menge „Dokumentation“ schreiben zu müssen, die erklärt, warum diese neue Architektur besser ist, aber es ist völlig technisch (über SOLID, Komponententests, Abhängigkeitsinjektion usw. sprechen), sodass es für das Management keinen Sinn macht verstehe es nicht.

Es hört sich so an, als würde dein anderer Teamkollege es auch nicht verstehen, also ändere die Sprache ein wenig. Sie benötigen dieses Dokument, um nicht nur die Zustimmung des Managements zu erhalten, sondern auch die Zustimmung Ihrer Teamkollegen. Sie sprechen viel über Dinge wie SOLID, aber Ihr durchschnittlicher Nicht-Programmierer (oder sogar ältere Programmierer) wird nicht wissen, was es ist, also verwenden Sie den Begriff, erklären Sie, was es ist, und erklären Sie die Vorteile des Frameworks. Dann sparsam verwenden. Tun Sie dies mit allen Fachbegriffen. Sie benötigen diese Dokumentation für das Buy-In Ihres Managers

3. Bringen Sie einige Management-Standpunkte ein

Ich bin ein versierter Softwarearchitekt und es war ein Kinderspiel. Der neue Code ist vollständig einheitentestbar mit Abhängigkeitsinjektion und umfassender Protokollierung, sodass alle Fehler und Probleme superleicht aufzuspüren sind.

Solche Sachen sind gut. Aus technischer Sicht. Was Sie jetzt tun müssen, ist, dies in Managementsprache zu übersetzen, was bedeutet, die Dinge einfach bis zu ihrem logischen Abschluss in Bezug auf Kosten und Rendite zu verfolgen . Diese Kosten können sich entweder auf Geld oder Mitarbeiterzeit reduzieren (da sie Sie für Ihre Zeit bezahlen). Zum Beispiel:

„Ich bin ein versierter Softwarearchitekt und es war ein Kinderspiel. Der neue Code ist vollständig einheitentestbar mit Abhängigkeitsinjektion und umfassender Protokollierung, sodass alle Fehler und Probleme superleicht aufzuspüren sind, wodurch die Anzahl der dafür erforderlichen Arbeitsstunden drastisch reduziert wird Fehlerbehebungs- und Wartungsarbeiten, und damit die mit diesen Arbeiten verbundenen Kosten reduzieren, indem es Entwicklern viel einfacher gemacht wird, den problematischen Code zu finden, und indem sie Probleme mit neuem Code in neueren Versionen erkennen, bevor sie die nächste Stufe im Entwicklungslebenszyklus erreichen. "

Eine Reihe anderer Antworten hier geben auch großartige Edelsteine ​​​​für Beispiele dafür. Arbeiten Sie diese ein, wo Sie können, und haben Sie keine Angst, sich weitere einfallen zu lassen.

4. Sprechen Sie die Bedenken Ihres Teamkollegen an

Lassen Sie uns nun das Argument Ihres Teamkollegen ansprechen, den ursprünglichen Code beizubehalten: „Es funktioniert“. Okay, vielleicht funktioniert es nicht immer , aber seit einigen Jahren vertraut man darauf. Sie können dem Management vorschlagen, ein Testsystem mit Ihrer Implementierung gleichzeitig mit einem anderen System auszuführen, auf dem der Originalcode ausgeführt wird. Vielleicht feuern Sie sogar ein paar Testfälle ab, darunter einige, von denen Sie erwarten, dass sie den ursprünglichen Code brechen. Auf diese Weise hat Ihr Teamkollege dieses Argument nicht mehr, weil Sie allen bewiesen haben, dass Ihr Code auch funktioniert und sogar besser funktioniert .

5. Sprechen Sie nicht erwähnte (aber dennoch wichtige) Faktoren an

Lassen Sie uns ein weiteres Argument hinzufügen, das der Teamkollege verwenden könnte: „Wir alle kennen den ursprünglichen Code“. Dies ist etwas schwieriger abzuwehren, da es eindeutig wahr ist, Kostenauswirkungen mit sich bringt, die das Management versteht, und nichts, was Sie in Ihrem Code tun können, kann dies vollständig lindern. Ihre beste Abmilderung ist in Ihrer Dokumentation , das gleiche Zeug, von dem Sie sagen, dass Sie festgefahren sind.

Daher muss Ihre Dokumentation zwei Ziele erreichen:

1) Überzeugen Sie das Management von den Vorteilen Ihrer Idee (darüber habe ich bereits gesprochen)

2) Bringen Sie Ihre Teamkollegen mit Ihrem Code auf den neuesten Stand (oder zumindest so viel wie möglich ohne Trial-by-Fire).

Erst wenn Sie diese 5 Punkte adressiert haben, können Sie folgendes Problem umgehen:

Das Problem ist, dass das Management uns beide ansieht und nicht weiß, wem es glauben soll.

Den Kunden und dem Management ist es egal, ob etwas gut codiert ist. Sie kümmern sich darum, ob es in akzeptablem Maße funktioniert, sie kümmern sich um seine Kosten und sie kümmern sich darum, ob sie es pünktlich bekommen.

Der beste Weg, Ihre Entscheidungen zu begründen, besteht darin, sie in Bezug auf Arbeitsstunden und Kosten zu erläutern.

Die zeitsparenden Maßnahmen sollten für sich sprechen. Wenn Ihre Änderungen beispielsweise 2 Arbeitsstunden pro Tag einsparen, sind das 10 Arbeitsstunden pro Woche oder 500 pro Jahr. Geht man von einer völlig willkürlichen Zahl von 25 € Arbeitskosten pro Arbeitsstunde aus, sind das 12.500 € Einsparungen pro Jahr, die für produktivere Aufgaben verwendet werden können.

Wenn Ihre Änderungen eine Verringerung des Zeitaufwands für die Fehlerbehebung bedeuten, verbringen Sie mehr Zeit damit, einen Mehrwert für das Unternehmen in Form neuer Funktionen zu schaffen, für die Kunden bezahlen können. Kunden zahlen nicht für Fehlerbehebungen, sondern für Funktionen. Je weniger Zeit Ihr Team mit der Behebung von Fehlern verbringt, desto weniger Geld verschwendet das Unternehmen und desto mehr Geld verdient das Team für das Unternehmen.

Ich war mehr als einmal in einer ähnlichen Situation wie du. Was Sie zu vermissen scheinen, ist ein so alter und chaotischer Code, dass es wirklich schwierig ist zu sagen, was ein Fehler ist und auf welche Funktionalität die Leute angewiesen sind. Es ist auch wirklich schwierig, wichtige Eckfälle zu erkennen, die behoben wurden. Ihr „Unruhestifter“ ist derjenige, der über das meiste Wissen verfügt.

Jetzt ist es etwas spät, aber am besten wäre es gewesen, ihn von Anfang an in Testfälle einzubeziehen und ihn nach jeder Kleinigkeit zu fragen, die Ihnen als Fehler erscheint, und nach allen Randbedingungen. Wenn du das getan hättest, wäre er viel sicherer, dass du diese Dinge tatsächlich verstehst. Kenntnisse der „neuesten Techniken“ sind nicht wichtiger als Domänenkenntnisse. Sie brauchen beides, um robuste Software zu schreiben.

Sie haben auch keine Möglichkeit zu überprüfen, ob sich das System wie das alte verhält. Das Schreiben von Tests, die auf dem alten System ausgeführt werden, ist langsamer, aber Sie können bewusster entscheiden, welches Verhalten Sie beibehalten und welche Abwärtskompatibilität Sie aufheben möchten.

Beziehen Sie ihn also jetzt so weit wie möglich in diese Dinge ein. Je mehr Input Sie von ihm bekommen können, desto besser wird das Ergebnis und desto besser ist Ihr Verbündeter.

Zeigen, nicht sagen

Dies ist für das Schreiben selbstverständlich, aber ehrlich gesagt auch für den Arbeitsplatz. Reden Sie nicht [Theorien] über die Verbesserungen, die Sie machen, zeigen Sie , wiesie sind [implementierte] Verbesserungen. Jargon ist eine großartige Möglichkeit, eine ansonsten wortreiche Beschreibung einer bestimmten Struktur abzukürzen, wenn Sie mit einem anderen Domänenexperten sprechen, da davon ausgegangen wird, dass andere Domänenexperten verstehen, was das bedeutet, aber Jargon ist häufig auch etwas, das Menschen nicht verstehen eigentlich verstehen, wovon sie reden, verstecken sich dahinter. Es ist auch eine Gefahr, wenn Sie mit jemandem sprechen, der nicht denselben Jargon "spricht", da es anmaßend oder als absichtlich verschleiernd rüberkommen kann oder sogar als ein Versagen, die Bedürfnisse des Projekts als Ganzes zu verstehen (insbesondere in Bezug auf allgemeinere Geschäftsziele) gegenüber der Ansicht aus der Perspektive eines einzelnen Mitglieds, was effektiv nur ein Satz möglicher Werkzeuge für die Arbeit an diesem Projekt ist.

Wenn Sie tatsächliche, deterministische Verbesserungen erzielt haben, sind diese auch messbar .

Dies geht über die reine Softwareentwicklung hinaus und ist etwas, worauf Sie sich bei Arbeitsplatzprojekten immer konzentrieren sollten.

Wenn Sie ein Projekt vorstellen, ist es in Ordnung, konzeptionelle Dinge oder Projektionen zu diskutieren, die auf diesen Konzepten basieren (aber Sie sollten idealerweise Ausgangspunktdaten haben, um zu zeigen, warum der Status quo ein Problem sein könnte, das gelöst werden muss, anstatt nur Lösungen für etwas vorzuschlagen das ist nicht eindeutig ein Problem).

Wenn Sie ein Projekt verteidigen, möchten Sie nachweisen können, dass tatsächlich Verbesserungen erzielt werden oder wurden. Dies ist die Sprache auf der Metaebene des Projekts/Geschäfts selbst und nicht nur ein werkzeugspezifisches Gerede, das die Bedeutung der angewandten Praktiken und getroffenen Entscheidungen nicht allgemein vermitteln kann.

Idealerweise haben Sie Daten, und die stärksten Daten sind Längsschnitte mit Gleichem im Vergleich zu Gleichem (so gut es möglich ist).

Wie Sie dies angehen möchten, wenn Sie Daten vor Ihren Änderungen hatten, bleibt Ihnen überlassen. Idealerweise würden Sie etwas vergleichen, das die Dinge weitgehend gerecht hält und nicht auf Launen der Zufälligkeit beruht.

Zur gleichen Zeit, wenn wir über Fehler sprechen, werden Fehler normalerweise nicht auf eine Art zuverlässig und wiederholbar getroffen, noch sind alle Fehler gleich, also wird dies immer ein Problem sein, wenn man Vergleiche zwischen vorher und nachher anstellt.

Für so etwas sind hier einige Dinge, die verwendet werden können, aber Sie müssen darauf achten, dass Sie ohne einen ausreichend langen Zeitraum für statistische Signifikanz (und eine Möglichkeit, festzustellen, was das in diesem Fall ausmacht) nach und nach gerecht sind mit Zahlen spielen:

• Zeit von der ersten Meldung des Problems bis zum Finden der Stelle im Quellcode, an der sich das Problem befindet
• Zeit vom Finden des Problemorts bis zum Erreichen einer Lösung
• Durchschnittliche Zeit zur Behebung des gemeldeten Fehlers
• Durchschnittliche Anzahl von Fehlern, die pro angemessenem Zeitfenster protokolliert wurden [Woche/Monat/Quartal]
• Durchschnittliche Entwicklerstunden, die pro angemessen festgelegtem Zeitfenster für die Bearbeitung von Fehlern aufgewendet werden

Möglicherweise haben Sie nicht auf alle Zugriff, aber Ihr Vorgesetzter oder der zuständige Projektmanager möglicherweise.

Da die Daten hier nicht konsistent sein werden, besteht ein anderer Ansatz darin, vergleichbare Einzelvorfälle sowohl vor als auch nach den Verbesserungen zu finden (sehr ähnliche Fehlermodalitäten usw.) und Fallstudienvergleiche zu erstellen. Gehen Sie in jedem Fall durch den Korrekturprozess, die für jeden Schritt benötigte Zeit usw.

Ähnliche Dinge können auch für Änderungen im Zusammenhang mit Funktionsverbesserungen durchgeführt werden, wenn Ihre Neuarchitektur erfolgreich war. Denken Sie daran, dass Sie Aspekte aufzeigen möchten, die Fehler im Vorfeld reduzieren und somit langfristig Zeit sparen. Zeigen Sie nach Möglichkeit die Anzahl der Fehler, die bei einer früheren Feature-Ergänzung oder einer ähnlichen Änderung aufgetreten sind, die damit verbundenen durchschnittlichen Zeitkosten und zeigen Sie dann, wie sich die möglicherweise höheren Vorabkosten der neueren Methodik im Laufe der Zeit auszahlen. Sprechen Sie nicht nur über die verwandten Theorien. Zeigen Sie sie im Kontext angewendet.

Hochheben, nicht runterdrücken

Ich werde keine Vermutungen darüber anstellen, wie Sie diesbezüglich mit anderen kommuniziert haben, aber es ist ziemlich klar, dass Sie es geschafft haben, mindestens einem Paar Zehen auf die Füße zu treten. Hier geht es nicht um Schuld , sondern darum, positive Wege zu finden, um entweder voranzukommen oder zumindest die Situation zu entschärfen.

Dies ist vielleicht das eigentliche zugrunde liegende Problem, mit dem Sie jetzt konfrontiert werden.

Es ist leicht, solche Situationen als extrem irritierend und stressig zu empfinden. Auch wenn es nicht unbedingt fair ist, besteht der beste Weg, um die Nase vorn zu haben, normalerweise darin, ruhig zu bleiben und nur über zukunftsgerichtete positive Dinge zu sprechen, anstatt schlecht zu reden, insbesondere in Bezug auf frühere Arbeiten. Verunglimpfen Sie die bisherige Arbeit nicht, schreien Sie sie nicht als veraltet an, sprechen Sie einfach über die nachweisbaren Auswirkungen Ihrer Verbesserungen.

Manchmal macht man sich Feinde, wenn man gute Arbeit leistet, und man kann das nicht kontrollieren. Was Sie tun können, ist zu versuchen, so auszusehen, als hätten Sie es ruhig und reif gehandhabt und wären derjenige gewesen, der die Hand ausgestreckt und versucht hat, hochzuziehen, anstatt dass derjenige, der da steht, sich darüber lustig macht.

Der beste Ansatz ist es, wann immer möglich, Personen, die Probleme verursachen könnten, im Voraus auf Ihre Seite zu stellen. Wenn es erst einmal bergab geht, wird es heikel oder unmöglich: Der ideale Zeitpunkt ist vorher. Zeigen Sie ihnen individuell und aus ihrer Perspektive, wie dies ihr Leben sowohl einfacher als auch nicht schwerer machen wird (achten Sie wieder auf Fachjargon, auch wenn Sie diesbezüglich mit jemand anderem in Ihrem Beruf sprechen) und hoffentlich einige Dinge einbeziehen, die sie vielleicht sogar spannend finden. Dazu ist es erforderlich, sie bis zu einem gewissen Grad zu verstehen. Finden Sie heraus, was ihre Bedenken tatsächlich sind (außerhalb einer Gruppenumgebung) und lindern Sie sie und zeigen Sie, wie dies eine Verbesserung für sie sein wird, nicht nur für das Geschäft/Projekt.

Im Idealfall geht es dabei nicht nur um Sie selbst, sondern um die Art von Dingen, bei denen wir ethisch hoffentlich alle möchten, dass alle um uns herum eine gute Arbeitserfahrung haben und glücklich sind.

Beachten Sie, dass dies nicht immer möglich ist. Aber zumindest in Gruppensituationen haben Sie ein gewisses Maß an Kontrolle darüber, wie Sie sich verhalten, also ist es an der Zeit, nicht mit jemandem herabzusprechen, die Arbeit (oder Bedenken, Perspektiven oder tatsächliche Beschwerden) anderer nicht zu verunglimpfen und Konzentriere dich einfach auf deine positiven Seiten.

Wenn jemand Bedenken äußert, verwenden Sie sie als Dreh- und Angelpunkt dafür, dass es „ein großartiger Punkt war, sie anzusprechen“, weil Sie ansprechen möchten, wie dies eine Verbesserung im Kontext dieser Bedenken sein wird. Nicht abweisendie Bedenken. Machen Sie den Akt der Besorgnis nicht ungültig. Finden Sie einen positiven, nach vorne gerichteten Blickwinkel. Verzetteln Sie sich nicht in Details, wenn die Dinge zu entgleisen, es ist in Ordnung zu sagen, dass Sie in Bezug auf ein bestimmtes Anliegen gerne separat ins Detail gehen würden, aber im Moment möchten Sie dies in Bezug auf versichern die breiteren Bildaspekte dieses Anliegens sind gut angegangen. Planen Sie ein entsprechendes Treffen, wenn nötig vor Ort. Verschieben Sie alle damit verbundenen Entgleisungen auf dieses Treffen. Sie müssen wahrscheinlich sicherstellen, dass derjenige, der sowohl Sie als auch diese andere Person beaufsichtigt, dem im Voraus zustimmt (und Sie werden so etwas definitiv nicht ohne ihre Anwesenheit tun wollen).

Dies ist ein Ansatz, den Sie anwenden können, um wie jemand auszusehen, der Dinge erledigt und auch mit Meinungsverschiedenheiten am Arbeitsplatz produktiv umgeht, anstatt allen über Ihnen Kopfschmerzen zu bereiten. Im Idealfall ist es nicht nur Ihr Aussehen, sondern es ist tatsächlich so.

Eine letzte Überlegung ist, dass, wenn Sie Dinge tun, die so interpretiert werden können, dass sie jemand anderen oder seine Arbeit schlecht aussehen lassen, sich die Zeit nehmen, all das Gute hervorzuheben, das sie getan haben, wie es Ihre Arbeit positiv beeinflusst oder erleichtert und wie Sie stehen nur auf ihren Schultern, um einen Schritt nach vorne zu machen. Beteiligen Sie sie idealerweise daran: Bitten Sie sie, einen verwandten Aspekt zu besprechen oder noch besser, ein bestimmtes Detail zu erklären. Geben Sie ihnen Raum, um in Bezug auf das, was Sie tun, weiterhin gut auszusehen, auch wenn vieles davon als Abschaffung ihres Codes angesehen werden könnte . Finden Sie Wege, die Perspektive zu ändern, sodass es nicht darum geht, ihre Arbeit loszuwerden .

Breitere Bildreflexion

Eine Sache, die Sie zurücktreten und bedenken sollten, ist, dass Sie, wenn Sie einen Kollegen haben, der mit moderneren Praktiken nicht Schritt hält, sich aber im Wesentlichen dem Projekt verschrieben hat, möglicherweise nicht die Geschäftsziele erreichen, für die Sie sich halten.

Sicher, aus Ihrer Sicht ist das Geldverschwendung. Es könnte sein. Es könnte nicht sein. Ihre Bedenken darüber, wie sehr sie aus Ihrer Sicht funktionieren oder nicht funktionieren, sind bemerkenswert, aber je nach Ihrer Position haben Sie diesbezüglich möglicherweise kein umfassenderes Bild. Niemand ist individuell unverfügbar, aber manchmal gibt es Gleichgewichte, wenn es darum geht, jemanden zu ersetzen, bei dem es sich nicht lohnt, die Arbeitsbelastung dieser Person jedoch nicht für etwas anderes Sinnvolles freizusetzen, und an diesem Punkt sind die entsprechenden Ressourcen besser an anderer Stelle eingesetzt anstatt das zu verbessern, was ihnen zugewiesen wurde/auf das sie sich konzentrieren.

Dem stimme ich persönlich nicht zu, aber es lohnt sich, sich darüber im Klaren zu sein, dass manchmal breitere politische Realitäten auf dem Spiel stehen und die eher stabilen Welten bestimmter Menschen durcheinanderzubringen vielleicht etwas Geld sparen, aber aus anderen Blickwinkeln vielleicht nicht der Mühe wert sind. Jedes Mal, wenn Sie dies tun, müssen Sie bereit sein, erhebliche Einsparungen vorzuweisen . Und im Idealfall müssen Sie in der Lage sein, dies zu tun, ohne jemanden schlecht dastehen zu lassen oder ihn auf andere Weise zu Ihrem Feind zu machen.

Software entsteht nicht ohne Menschen. Software ist nur insofern nützlich, als sie als Werkzeug für Menschen dient. Dasselbe gilt für die Entwicklungsarbeit. Ja, es geht darum, dem Computer zu sagen, was er tun soll. Aber es geht auch um Teamarbeit und Kommunikation. Ich würde sagen, es geht vor allem um Teamwork und Kommunikation .

Die meisten der Softwareentwicklungsprinzipien, die Sie ansprechen, sind im Kern wirklichüber die Schaffung konsistenter Rahmenbedingungen, die Teamarbeit, Kommunikation (auch wenn Sie individuell arbeiten, da es um die Kommunikation mit Ihrem zukünftigen Selbst geht) und grundlegende Realitäten menschlicher Fehlbarkeit dienen. Sie hatten einen Kommunikationsfehler mit Mitgliedern Ihres Teams und diese Reibung war das Ergebnis. Es ist leicht, „Arbeitsplatzpolitik“ als etwas abzutun, mit dem sich Menschen „nicht auseinandersetzen sollten, um Dinge zu erledigen“, aber was das wirklich bedeutet, ist, dass wir miteinander kommunizieren müssen, um als Team voranzukommen. Idealerweise ist dies die Rolle von jemandem, der das Team leitet. Aber die Realität ist, dass Sie, wenn Sie jemand sein wollen, der Dinge erledigt und signifikante positive Veränderungen bewirkt, auch die Erwartungen und die Kommunikation mit Ihren Kollegen verwalten müssen.

Es ist leicht, den Anschein zu erwecken, dass Prinzipien wie SOLID, TDD usw. etwas sind, das ein Einzelner einfach herunterfallen und durch umfassende Änderungen an einem schlecht codierten Projekt implementieren kann, aber in Wirklichkeit kann dies in Bezug auf die zugrunde liegenden Ziele effektiv selbstzerstörerisch sein von SOLID und ähnlichen Prinzipien und Theorien der Softwarearchitektur. Genauso wie der beste softwareimplementierte Algorithmus effektiv nutzlos wird, wenn niemand, der ihn benötigt, die zugehörige Software tatsächlich verwenden kann, ist die am besten strukturierte Software in Bezug auf diese architektonischen Aspekte nutzlos, wenn das Team, das daran arbeitet, dies nicht mehr effektiv tun kann ( dies schneidet zugegebenermaßen einige andere verwandte Blickwinkel für den Zweck dieser Diskussion ab).

Manchmal deutet dies auf die Notwendigkeit eines Personalwechsels hin, aber wenn Sie nicht in der Position sind, entsprechende Entscheidungen zu treffen, ist es wichtig, sich daran zu erinnern, dass dies nicht wirklich Ihre Wahl oder Ihre Position ist. Auf eigene Faust voranzutreiben, insbesondere wenn ein anderer Zeitplan entwickelt und vereinbart wurde, könnte sogar der schlechteste Schritt sein, und Sie könnten sich selbst ein schlimmeres Durcheinander anrichten als nur das, was Ihnen direkt ins Gesicht springt, weil andere Leute hätte vielleicht Pläne gehabt, wie man mit der Situation umgeht, und jetzt ist es stattdessen einfach explodiert. Der Sinn der meisten modernen Software-Engineering-Prinzipien besteht darin, nicht mehr nur so zu tun, als ob Code in einem perfekten Vakuum geschrieben wurde. Denken Sie also daran, dass es wirklich darum geht, die beteiligten Personen realistisch zu betrachten. Dazu gehört auch der Rest des Teams.

Ich bezweifle, dass Sie daraus irgendwelche Vorteile ziehen werden, es ist sehr schwer zu rechtfertigen, irgendetwas für das Management neu zu schreiben, ohne neue Funktionen bereitzustellen, es sind neue glänzende Dinge, mit denen sich das Management beschäftigt, je mehr neue UI beteiligt ist, desto besser. Ich habe gerade einen schwerfälligen Dinosaurier mit nur einem Thread in ein Meisterwerk mit mehreren Threads verwandelt, und es hat niemanden einen Scheiß interessiert, weil es nichts Neues gab, das sie auf dem Bildschirm anklicken konnten

Trainer Der Veteran

Andere Antworten haben gute Ratschläge zum Umgang mit Legacy-Code und -Verwaltung gegeben. Ich möchte mich auf das konzentrieren, was ich für Ihr Kernproblem halte: den Umgang mit dem ursprünglichen Entwickler. So sieht man vieles nicht auf Augenhöhe. Wenn Sie möchten, dass er Sie nicht mehr untergräbt, müssen Sie ihn in Ihr Team holen. Was bedeutet, dass Sie ihn brauchen, um die Welt so zu sehen, wie Sie es tun. Und der Weg, dies zu tun, besteht darin, zunächst zu verstehen, wie seine Welt in bedeutenden Details aussieht.

Lesen Sie den Legacy-Code und versuchen Sie, die Muster und impliziten Regeln herauszufiltern , mit denen Sie nicht einverstanden sind. Notieren Sie sich diese, denn hier möchten Sie auf dieselbe Seite kommen. Überlegen Sie dann, warum Sie mit ihnen nicht einverstanden sind. Konzentrieren Sie sich nicht darauf, warum das Legacy-Muster schlecht ist . Konzentrieren Sie sich darauf, warum Ihr Ersetzungsmuster besser ist , aber erkennen Sie auch das Fundamental Theorem of Engineering an: Alles ist ein Kompromiss . Auch Ihr „besseres“ Muster hat unter manchen Bedingungen eine Schwäche. Sie müssen in der Lage sein, diese Fehlermodi zu identifizieren und zu verstehen, um erfolgreich argumentieren zu können, dass sie für die vorliegenden Szenarien am wenigsten relevant sind. Sobald Sie diese Vorbereitungsarbeit erledigt haben, sind Sie bereit für den nächsten Schritt.

Paar-Programmierung

Sag deinem Kumpel, dass du auf dem falschen Fuß aufgestanden bist, es dir leid tut, ein arroganter, herablassender Arsch zu sein, und du nur herausfinden willst, wie du auf die gleiche Seite kommst. Wählen Sie einen Code aus, der die oben identifizierten Anti-Patterns verkörpert, und sehen Sie sich die alte und Ihre „verbesserte“ Version nebeneinander an. Bitten Sie den Entwickler, die beiden zu kritisieren, und geben Sie ihm viel Zeit und Raum dafür. Suchen Sie nach Gelegenheiten, ihm zuzustimmen , anstatt ihm zu widersprechen. Sie versuchen, an dieser Stelle Brücken zu bauen. Die Meinungsverschiedenheit ist bereits implizit. Nachdem er seine Beobachtungen gemacht hat, stellen Sie Leitfragen, um zu verdeutlichen, warum Sie denken, dass Ihre Version besser ist. Bringen Sie insbesondere Codeausführungsszenarien zur Sprache, in denen Ihr Code offensichtlich überlegen ist. Im allerbesten Fall Testfälle zur Hand haben (Unit oder Abnahme), welcheveranschaulichen Sie die Überlegenheit Ihrer Version und bitten Sie ihn einfach, sie zu überprüfen.

Ihr Ziel ist es nicht, den Kerl in einer Falle zu fangen, sondern ihm zu helfen, die Welt aus Ihrer Perspektive zu sehen. Und das funktioniert nur, wenn Sie zuerst seine Perspektive auf einer bestimmten Ebene validieren. Insbesondere müssen Sie für die Geschichte außerordentlich sensibel sein . Viele Dinge, die wir heute als "schlecht" ansehen, waren vor Jahrzehnten üblich oder akzeptiert oder sogar gut , weil die Technologie anders war, das Wissen anders war, die Hardware anders war. Versuchen Sie, Grace Hopper zu sagen, dass „GOTO als schädlich angesehen wird“. Sie erwiderte: "Junger Mann, ich würde gerne sehen, wie Sie ein Assembler-Programm ohne JMP-Anweisungen schreiben. Kommen Sie zurück, wenn Sie fertig sind."

Das heißt, Sie können und sollten die Architektur des Systems im Kontext seiner Entstehungszeit verstehen . Auch wenn es sich damals nicht um Spitzentechnologie handelte, wurde sie möglicherweise auf relativ ausgereiften Mustern aufgebaut, die später überholt wurden. Sie werden viel erreichen, wenn Sie etwas Bewusstsein und Respekt für diese Entwicklungsgeschichte zeigen. Dies ist alles, um das Wichtigste zu sagen, was Sie lernen müssen: "Code ist nicht gut oder schlecht . Es ist gut oder schlecht in Bezug auf einen bestimmten Kontext ." Es ist durchaus möglich, dass, wenn Sie dabei waren, wannder Code ursprünglich geschrieben wurde, haben Sie ihn möglicherweise auf ähnliche Weise geschrieben. Noch vor einem Jahrzehnt habe ich mit meinem gesamten Team bei einem großen Fortune-100-Technologieunternehmen über die Vorteile von Unit-Tests gestritten. Auf keinen Fall würde ich dieses Gespräch heute führen. Vieles ändert sich mit der Zeit.

Bitten Sie um Hilfe

Wenn Ihr Kumpel besonders unnachgiebig ist, wählen Sie einfach einen Fehler aus, um ihn in einem Teil des Codes zu beheben, den Sie nicht umgestaltet haben. Bitten Sie ihn, mit Ihnen darauf zu schauen. Sagen Sie: „Ich habe nicht den Kontext, um diesen Code effizient zu debuggen. Können Sie mir Ihren Ansatz dafür zeigen?“ Lassen Sie sich von ihm durch seinen Prozess führen. Wenn er etwas tut, das Stammeswissen hervorruft, lassen Sie ihn innehalten und sagen: "Oh, weiß das noch jemand?" "Natürlich nicht." "Okay, weil ich das nicht erraten hätte, wenn ich mir nur den Code angesehen hätte. Können wir uns einen Moment Zeit nehmen, um das zu dokumentieren?" Nach einer Weile wird ihm das Händchenhalten auf die Nerven gehen, und er wird sehen, dass es für alle anderen kompliziert und frustrierend sein kann, nur weil es für ihn einfach ist, durch den Code zu navigieren. Wenn Sie wirklich den Punkt nach Hause fahren wollen, Bringen Sie ihn dazu, mit dem Junior-Entwickler zu spähen, während Sie allen über die Schulter schauen. Bringen Sie dem Junior-Entwickler bei, den gleichen fragenden statt herausfordernden Ansatz zu verwenden wie Sie.

Wenn du Glück hast, wird er frustriert und sagt so etwas wie: „Ok, wenn du so schlau bist, wie würdest du das machen?“ Sagen Sie dann: "Nun, wir haben einen Fehlerbericht, der zeigt, dass irgendwo in einem Code, den ich umgestaltet habe, ein Fehler ist. Schauen wir uns das an." Lassen Sie ihn dann durch Ihren neuen Code navigieren und Sie dazu befragen/herausfordern. Verwenden Sie die von Ihnen geschriebenen Komponententests, um den Fehler zu isolieren, und lassen Sie den Junior-Entwickler einen Teil der Zeit fahren, um zu veranschaulichen, dass es nicht nur um ihn oder Sie geht, sondern um das gesamte Team.

Wenn Sie sich auf Empathie und Qualität konzentriert haben, anstatt auf Urteilsvermögen und Cruft, dann helfen Sie ihm im Idealfall zu sehen, dass Sie tatsächlich wertvolle Verbesserungen vorgenommen haben, anstatt nur mit dem System herumzuspielen, das er über ein Jahrzehnt aufgebaut hat. Anstatt darauf zu bestehen, dass Sie der allwissende Architekt sind, der allen Codes Güte und Licht bringt, beginnen Sie mit einer gesunden Portion Demut von vorne und lassen Sie Ihren Code für sich selbst sprechen. Wenn er ein vernünftiger Programmierer ist, wird er schließlich anerkennen müssen, dass besserer Code besserer Code ist, mit dem selbst er lieber arbeiten würde. Und wenn Sie ihn nicht bis zu diesem Punkt bringen können, hat das vielleicht mehr mit Ihrer Einstellung zu tun als mit seiner. Denken Sie daran und viel Glück.

TL;DR: Wenn Sie nicht übertrieben haben, dann gibt es vielleicht nichts, was Sie für dieses Projekt tun können. Aber Sie könnten versuchen, es ein neues Projekt zu nennen und es separat auszuführen.

Ich war mehr als einmal in fast genau deiner Situation. Ich kann natürlich nicht sagen, dass Sie im Recht sind, da ich nicht alles über Ihr spezielles Projekt weiß, aber manchmal ist es wirklich schwarz und weiß, wie Sie es ausdrücken, ungeachtet dessen, was andere sagen.

Bei meinem ersten Arbeitgeber in meiner Karriere hatte ich das Glück, auch Ausfallzeiten zu haben. Ich habe immer wieder so viele schreckliche Fehler von ein paar Entwicklern gesehen, dass ich beschlossen habe, zu helfen. Sie lehnten ab, aber ich persönlich war einer der Leute, die sich mit den Folgen ihres Mülls auseinandersetzen mussten, wenn sich Leute beschwerten, also trat ich ihnen trotzdem auf die Zehen.

Ich habe eine bessere Version gemacht. Ich hatte direkten Kontakt mit den Endbenutzern als der Typ, dem ich auf die Zehen trat, also ließ ich sie es sogar testen. Sie liebten es und einige wechselten dazu.

Unser eigener Kundendienstleiter (ein Computer-Typ, der die technischen Auswirkungen verstand) sagte, er wolle die offizielle Version durch meine ersetzen, aber die Senioren jammerten darüber, meine Version wurde wie ein Stein fallen gelassen ... aber ungefähr ein Jahr später Ich habe den Job gewechselt, der CTO des alten Standorts hat meine Nummer von meinem alten Chef bekommen und der CTO hat mich persönlich angerufen und gefragt, ob ich im Rahmen eines Zeitvertrags zurückkommen würde, um meine Version dieses Tools zu unterstützen! Ich war interessiert, aber er mochte den von mir genannten Preis nicht (weit weniger als das, was sie für die Junk-Version ausgegeben haben), und er hat nie wieder zurückgerufen.

Bei meinem nächsten Arbeitgeber bekam ich den Segen, eine „Lite“-Version eines ihrer Produkte herzustellen. In etwa 2 Monaten habe ich eine Version erstellt, die weniger Fehler hatte, viel schneller lief, selbst auf weniger Hardware, einfacher zu warten und zu aktualisieren war, eine bessere Architekturdokumentation hatte und sogar anfing, funktionsreicher zu werden als die Originalversion (und einige Funktionen sie wollten sogar auf die Vollversion portiert werden) ... bis jemand sagte "Hey, wir sollten einfach die Vollversion durch diese bessere ersetzen." Dann bamm! Plötzlich wurde die "Lite"-Version gestrichen. Ich wurde wieder auf die Vollversion gesetzt, komplett mit all ihren scheußlichen Code-Gerüchen (das ist eine Untertreibung: Das Ganze war der Morast ewigen Gestanks), fehlender Dokumentation und Bugs und so.

Die Vollversion stürzte tatsächlich oft beim Start ab, manchmal brauchte es 10 Versuche oder mehr, bevor sie richtig startete, und die Antwort darauf war, die Software nicht direkt aufzurufen, sondern stattdessen ein Startskript dafür zu erstellen, das es einfach in einer Endlosschleife versuchte um es für einige Minuten zu starten. Dem Mann mit dem längsten Dienstalter und seinem Freund im Management war das egal.

Manchmal kann man einfach nichts tun.

Wenn Ihr Kollege wirklich so dumm oder so stur ist, wie Sie vermuten, und Sie nicht übertreiben, dann müssen Sie vielleicht einfach die Idee aufgeben, seine Unterstützung zu haben. In diesem Fall müssen Sie nur denjenigen überzeugen, der die Entscheidung treffen kann, und es dabei belassen.

Wenn Sie weder Ihren Kollegen noch den Manager mit der Entscheidungsrolle überzeugen können, dann ist es ein verlorener Fall und Sie müssen dieses Projekt einfach verlassen. Hoffentlich ist der Arbeitgeber groß genug, dass du wechseln kannst.

Eine andere Route, obwohl es immer noch um wechselnde Projekte geht, ist ...

Verkaufen Sie Ihre Software als neues Produkt

Damit meine ich nicht unbedingt, ein eigenes Unternehmen zu gründen, um gegen den Arbeitgeber anzutreten. Das ist eine Option, aber was ich meine, ist, ihnen die Idee zu verkaufen, dass Ihre Software als "Unsere App 2.0" betrachtet werden könnte, oder sie eine völlig andere Software zu nennen.

Microsoft hat sowohl Internet Explorer als auch Edge. Sie haben Notepad, aber sie haben auch Wordpad und Word, jedes besser als das davor.

Sie können Ihre Software als Konkurrent der Software Ihres Konkurrenten verkaufen, selbst wenn es sich um dieselbe Firma handelt. Dann kann Ihr Kollege seine Software so haben, wie sie ist, und wenn es niemand will, stirbt sein Projekt von selbst.

Präsentieren Sie das neue System

Vereinbaren Sie eine große technische Team-/Multi-Team-Präsentation über das neue System. Demonstrieren Sie den Fehlerfindungsprozess mit dem alten System. Demonstrieren Sie dann einen Fehler im neuen System. Verwenden Sie idealerweise tatsächliche Beispielprobleme, von denen das Management weiß, dass sie legitim sind, und nicht einige kleine orchestrierte Fehler.

Sehen ist Glauben. Der ursprüngliche Entwickler wird es schwer haben, das alte System zu verteidigen, wenn das neue System in Aktion zu sehen ist.

Geben Sie dann Statistiken an, die die Menge der Fehler zeigen, die mit dem neuen System im Laufe der X-Zeit gefunden wurden.

Klopfen Sie nicht das vorherige System und wie schlecht es ist. Verkaufen Sie nur das neue System und wie gut es ist, ohne Arroganz, was wichtig ist. Sie wollen Freunde finden, um das neue System zu unterstützen, nicht Feinde, um sich dagegen zu wehren.

Zeigen Sie die Zeit an - verlangen Sie die Gründe.

Führen Sie alten und Ihren Code aus und zeigen Sie, wie viel Zeit Sie sparen.
Zeigen Sie, wie alter Code beim Wechsel in die Cloud Müll wäre. Zeigen Sie, dass die Laufzeit Null ist, wenn es nicht mehr funktioniert. Wenn es nicht mehr funktioniert, würde dies nicht nur zu mehr Zeit / Arbeitsstunden für die Reparatur führen, sondern auch jede "Produktion" stoppen.

Machen Sie ihnen bis zu dem Punkt bewusst, dass sie es persönlich beweisen können, dass ein fehlerhaftes altes System viel anfälliger für Exploits ist.

Sie müssen grundsätzlich beweisen, dass das System nicht funktioniert. Es "läuft" einfach. Und sogar ein kleiner Kiesel wird es zerquetschen.

Wenn es für Sie notwendig wird, dem Management zu „helfen“, zu wissen, „wen es glauben soll“, schlagen Sie ihm vor, diesen QA-Thread zu lesen.

Aber halten Sie Ihren Lebenslauf auf dem neuesten Stand – ich bin mir sicher, dass einer der Gründe für meine Entlassung darin bestand, die Kompilierzeit und die ausführbare Größe durch einen Ansatz zu halbieren, den ein „erfahrenerer“ Kollege dem Management als unmöglich erklärt hatte, als ich ihn empfahl.

Eine der Antworten kam bereits dem nahe, was ich sagen wollte, aber ich denke, es lohnt sich, sie zusammenzufassen, also werde ich mich kurz fassen.

Manager, insbesondere nicht-technische Manager, mögen Zahlen. Sie mögen Diagramme. Sie brauchen harte Zahlen, die ihre Entscheidungen rechtfertigen können. Das ist alles, was Sie wirklich brauchen, um es ihnen zu zeigen.

Stellen Sie ein paar Folien zusammen (wo möglich):

New vs Old deployment time
Frequency of bugs with time
Time to fix bugs 

Dinge dieser Art. Stellen Sie ein paar gute Statistiken zusammen, halten Sie sie kurz und übersichtlich, zeigen Sie sie dem Management, und Sie haben garantiert ihre Aufmerksamkeit, wenn Ihre Beiträge so wirkungsvoll sind, wie Sie behaupten. Das ist wirklich alles, was Sie tun müssen, um das Management zu überzeugen. Die restlichen Antworten beziehen sich hauptsächlich auf die Büropolitik, die ich in Fällen vermeiden möchte, in denen Sie Ihren Standpunkt mit soliden Zahlen / Grafiken demonstrieren können. Machen Sie sich keine Sorgen um den anderen Entwickler, sobald Sie das Management überzeugt haben, liegt die Verantwortung bei ihm, sich zu überwinden oder einen anderen Job zu finden.

Tut mir leid für eine so knappe Antwort, aber hier ist eine einfache und wichtige Sache, die ich aus meiner früheren Erfahrung gelernt habe und die Sie leider vermissen:

Konsistenz ist wichtig