Was kann ich tun, um diese Situation zu beheben?

Nichts, Sie waren nur ein paar Monate dort, es ist nicht Ihre Rolle und Sie haben nicht die Macht um etwas anderes zu tun, als darüber zu jammern.

Ihre Vorgesetzten haben viele Möglichkeiten, haben sie aber seit 7 Jahren nicht mehr genutzt. An diesem Punkt erraten Sie also nur noch die Gründe und analysieren stattdessen einen Kollegen sich auf Ihre eigenen Verantwortlichkeiten und Aufgaben zu konzentrieren.

Stellen Sie zwei oder drei der intelligentesten Entwickler ein, die Sie finden können. Gib ihnen den ganzen Code. Lassen Sie sie überprüfen, ob sie tatsächlich den gesamten Code haben, alles, was zum Ausführen der Software erforderlich ist. Lassen Sie sie lernen, was der Code tut, dokumentieren, umgestalten, bis sie den Punkt erreichen, an dem sie Probleme schneller als Herr A beheben können. All dies offensichtlich ohne Kenntnis von A.

An diesem Punkt sind Sie Stellen Sie sicher, dass Sie Herrn A vollständig von allen Unternehmensressourcen ausschließen, den Auftrag an Ihre neuen Entwickler übertragen und Herrn A darüber informieren, dass seine Anstellung beendet ist.

Ich würde denken, dass mit den Entwicklungsmethoden von Herrn A der Arbeitsaufwand für seinen Code normalerweise viel weniger als sieben Jahre beträgt und dass der Code verschleiert, aber nicht wirklich schwierig ist. Das macht die Arbeit der neuen Jungs viel einfacher.

PS. Aufgrund einiger Kommentare möchte ich dies noch einmal betonen: Das Problem ist nicht nur das Geld, das Problem ist, dass die Software viel weniger gut entwickelt ist als sie sein könnte, weil A sich darauf konzentriert, die Entwicklung zu erschweren, nicht darauf, das zu verbessern Software.

Kurze Antwort: Ihre Organisation ist derzeit in großer Gefahr, den Busfaktor zu erreichen.

Aus diesem Grund lassen Sie niemals eine Person die gesamte Kontrolle übernehmen Wissen. Es ist ein großes Risiko. Was würde passieren, wenn diese Person aussteigen würde oder buchstäblich von einem Bus angefahren würde? Wenn die Situation so ist, wie Sie es beschreiben, ist das gesamte Unternehmen verschwunden. Sie müssen dies Ihren Managern als organisatorisches Risiko und nicht als HR-Problem kennzeichnen.

Beginnen Sie, andere Personen mit oder ohne Herrn A über den Code zu informieren. Am besten ohne, da Sie ihn bereits als identifiziert haben das Problem.

Denken Sie daran, wenn Herr A bei dieser Risikominderung für Ihre Organisation nicht behilflich ist, ist er selbst eine Gefahr für die Organisation und muss gemanagt werden. Nehmen Sie ihm die Kraft, damit Sie nicht alle einen Weg nach vorne finden, wenn er wirklich von einem Bus angefahren wird.

Die anderen Antworten sind ziemlich gut, aber es gibt noch eine weitere Sache, die ich in Betracht ziehen würde:

Mein persönlicher Rat wäre, in Betracht zu ziehen, nach anderen Arbeitsplätzen zu suchen ... wenn das Management dies nicht getan hat Ich bin mir nicht sicher, ob dies ein Ort ist, für den Sie langfristig arbeiten möchten. Für mich ist dies ein Warnsignal für andere Probleme im Unternehmen.

und er trifft absichtlich schlechte Entscheidungen, um das Softwareprodukt instabil zu halten, schwer zu warten und Fehler zu beheben.

Warum lässt Ihr Team diese "schlechten Entscheidungen" hinter sich? Design Review oder Code Review? Wenn Sie keinen Codeüberprüfungsprozess oder gar keinen Entwurfsüberprüfungsprozess haben, setzen Sie sich langfristig dafür ein.

Bis dahin finden Sie alles, was Sie wissen müssen, im Blog-Artikel von Joel on Software: Dinge erledigen, wenn Sie nur ein Grunzen sind

Und er hat einen speziellen Hinweis für den Umgang mit Bozos: FILE BUGS. Per Spolsky:

Als Grunzen ist Ihr Ziel die Schadensminimierung, a.k.a. Eindämmung. Irgendwann wird eines dieser Genies zwei Wochen damit verbringen, ein Stück Code zu schreiben, das so unglaublich schlecht ist, dass es niemals funktionieren kann. Sie sind versucht, die fünfzehn Minuten zu verbringen, die erforderlich sind, um das Ding von Grund auf neu zu schreiben. Der Versuchung widerstehen. Sie haben die perfekte Gelegenheit, diesen Idioten für mehrere Monate zu neutralisieren. Melde einfach weiterhin Fehler gegen ihren Code. Sie haben keine andere Wahl, als monatelang daran herumzuschnüffeln, bis Sie keine Fehler mehr finden. In diesen Monaten können sie nirgendwo anders Schaden anrichten.

Andernfalls sollte es Ihr Ziel als neuer Mitarbeiter im Team sein, Ihren eigenen Ruf als Exzellenz zu entwickeln.

Nur um es klarer zu sagen als die aktuellen Antworten ...

Ihr Problem :

Niemand wusste, wie man es behebt .

Ihre Lösung :

Dort Jetzt braucht die Firma den anderen nicht mehr.

Schreiben Sie dies an die Wand: (Sie müssen einige Namen und Orte ändern.)

Vor einigen Jahren gab ich eine Woche lang einen internen Programmdesignkurs bei ein produzierendes Unternehmen im mittleren Westen der Vereinigten Staaten. Am Freitagnachmittag war alles vorbei. Der DP-Manager, der den Kurs arrangiert hatte und ihn aus seinem Budget bezahlte, bat mich in sein Büro. "Was denken Sie?" er hat gefragt. Er bat mich, ihm meine Eindrücke von seiner Operation und seinen Mitarbeitern zu erzählen. "Ziemlich gut", sagte ich. "Sie haben dort einige gute Leute." Programmdesignkurse sind harte Arbeit; Ich war sehr müde; Die Beratung zur Mitarbeiterbewertung wird zusätzlich berechnet. Wie auch immer, ich wusste, dass er mir wirklich seine eigenen Gedanken erzählen wollte.

„Was denkst du über Fred?“ er hat gefragt. Wir alle finden Fred brillant. “ "Er ist sehr klug", sagte ich. "Er ist nicht sehr begeistert von Methoden, aber er weiß viel über Programmierung." "Ja", sagte der DP-Manager. Er drehte sich in seinem Stuhl um und sah sich einem riesigen Flussdiagramm an, das an der Wand klebte: etwa fünf große Blätter Zeilendruckerpapier, vielleicht zweihundert Symbole, Hunderte von Verbindungslinien. „Fred hat das gemacht. Es ist der Aufbau des Bruttolohns für unsere wöchentliche Gehaltsabrechnung. Niemand außer Fred versteht es. “ Seine Stimme wurde zu einer ehrfürchtigen Stille. „Fred sagt mir, dass er nicht sicher ist, ob er es selbst versteht.“

„Großartig“, murmelte ich respektvoll. Ich habe das Bild klar verstanden. Fred als Frankenstein, Fred der brillante Schöpfer des unkontrollierbaren Monster-Flussdiagramms. "Aber was ist mit Jane?" Ich sagte. „Ich fand Jane sehr gut. Sie hat die Programmdesign-Ideen sehr schnell aufgegriffen. “

"Ja", sagte der DP-Manager. „Jane kam mit einem guten Ruf zu uns. Wir dachten, sie würde genauso brillant sein wie Fred. Aber sie hat sich noch nicht wirklich bewährt. Wir haben ihr ein paar Probleme gegeben, von denen wir dachten, dass sie wirklich schwierig werden würden, aber als sie fertig war, stellte sich heraus, dass sie überhaupt nicht wirklich schwierig waren. Die meisten von ihnen fielen ziemlich einfach aus. Sie hat sich noch nicht wirklich bewährt - wenn Sie sehen, was ich meine? “

„ Ich habe gesehen, was er meinte. “

- Auszug aus dem Buch Softwareanforderungen &-Spezifikationen - Michel Jackson (eine Lektüre wert).

Die Antwort ist einfach: Feuern Sie ihn. Möglicherweise müssen Sie kurzfristig einen nicht trivialen Geldbetrag auszahlen, um das Chaos zu beheben, das er angerichtet hat, aber Herr A ist nicht schlauer als jeder andere auf der Welt - jemand anderes wird es sein in der Lage, die Software kurzfristig zu warten und langfristig besser zu machen.

Es gibt eine Perspektive zu berücksichtigen.

Das Unternehmen mag es so. Wenn sie es nicht getan haben, ist es eine lange Zeit, es bestehen zu lassen.

Wir neigen als Entwickler dazu zu vergessen, dass es nicht unsere Aufgabe ist, guten oder intelligenten Code zu schreiben. Es ist unsere Aufgabe, ein Produkt ins Leben zu rufen. Das Schreiben von gutem Code macht diesen Prozess nur besser, aber Sie können ein absolut fantastisches Produkt mit total beschissenem Code erstellen.

Das Unternehmen hat hinter seinen Entscheidungen gestanden und ihn sogar zurückgestellt. Sie "mögen" ihn und seine Art, Dinge zu tun. Sie werden das wahrscheinlich nicht ändern, selbst wenn Sie es irgendwie geschafft haben, ihn zu entlassen. Was wahrscheinlich passieren wird, ist, dass sie eine neue Person als "den Kerl" auswählen und der Prozess von vorne beginnt.

Es ist nicht Ihre Aufgabe, das Unternehmen zu leiten. Das Unternehmen hat seine Wahl getroffen. Sie müssen Ihre machen. Lernen Sie von dem Mann (er hat seit 7 Jahren den gleichen Job, er muss etwas richtig machen) oder machen Sie weiter.

Zum Guten oder Schlechten ist weder nichts noch niemand unersetzlich. (Einige sind vielleicht mehr als andere, aber immer noch) Wenn die Leute die Lösung kennen, können sie mit dem Reverse Engineering beginnen.

Ich war in der Vergangenheit mehr als ein paar Mal in Ihren Schuhen. In der ähnlichsten Situation wie Ihrer war "Mr. A" schon lange nicht mehr vorhanden. Ich hatte jedoch eine monolithische Lösung für das Back-End eines Kabelunternehmens, bei dem ich keinen Quellcode für die lokal entwickelten Bibliotheken hatte, und obendrein, wenn nicht Ich war ein Neuling in dieser Branche.

Ich habe es ziemlich modular angegriffen, indem ich mir den vorhandenen Code angesehen, das Reverse Engineering, wo es fehlte, und Module geschrieben habe, die wiederum durch bessere Funktionalität und Geschwindigkeit ersetzt wurden Kernaufgaben. Ich habe jedes Modul perfektioniert, bevor ich zum nächsten überging. In ein paar Monaten hatte ich die frühere Anwendung getötet.

Unersetzlich zu sein, ist übertrieben.

Der Umgang mit Legacy-Dingen ist keine leichte Aufgabe. Vielleicht erledigt Ihr Mitarbeiter dies aus Trägheit oder weil er es nicht besser weiß.

Aus geschäftlicher Sicht gibt es grundsätzlich zwei Lösungen:

1. Inkrementeller Übergang, mit anderen Worten, nehmen Sie einen kleinen Teil der Funktionalität, implementieren Sie sie erneut auf einen hohen Standard und setzen Sie sie um es in der Produktion und machen Sie dies Stück für Stück weiter, bis das alte System vollständig außer Betrieb genommen werden kann.
2. Erstellen Sie ein neues System vollständig und wechseln Sie dann entweder auf einmal oder schrittweise zu ihm, z Neue Kunden darauf starten und alte Kunden schrittweise darauf verschieben. Das neue System muss anfangs nicht so funktionsfähig sein wie das alte. Das Verkaufsargument kann ein niedrigerer Preis, eine schnellere Unterstützung usw. sein.
ol>

Die Vorteile von Option 1 bestehen darin, dass keine großen Vorabinvestitionen erforderlich sind und Ihr neuer Code vor Ort getestet wird allmählich statt auf einmal, und Sie sehen frühzeitig Vorteile (weil das Unternehmen weniger Zeit und Geld für die Wartung der Teile des alten Systems benötigt, die nicht mehr aktiv sind).

Die Nachteile sind jedoch die folgenden Die Struktur des neuen Systems kann stark von der Struktur des alten Systems beeinflusst werden, und in einigen Fällen ist es wirklich schwierig, Teile eines sehr unordentlichen Systems zu ersetzen. Manchmal ist ein bisschen Kreativität erforderlich - wenn alles andere fehlschlägt, kann Ihr neuer Code Tastendrücke und Tastenklicks auf dem alten System simulieren! Die Anbindung an das alte System kann jedoch so viel Arbeit verursachen, dass es besser ist, einfach Option 2 zu wählen.

In beiden Fällen kann etwas getan werden. Die Frage ist, wie viel wird es kosten und wie viel wird es sparen? Der Versuch, dies für jede der oben genannten Optionen abzuschätzen, hilft bei der Bestimmung der zu wählenden Option (falls vorhanden). Dies hängt von den funktionalen Anforderungen, der Struktur des vorhandenen Systems und der Bereitschaft des Unternehmens ab, Geld auszugeben / Kredite im Voraus für zukünftige Einsparungen zu verwenden.

Als Mitglied des Software-Teams besteht Ihre Aufgabe nicht darin, das Unternehmen und seine Mitarbeiter zu verwalten.

Ihre Aufgabe ist es, gute Software zu schreiben. Sorgen Sie sich also um die Software, nicht um die Leute.

Sie sehen die Probleme mit der Software, und aus Ihrer Frage geht hervor, dass Sie einige Ideen haben, um die Probleme zu beheben. Bringen Sie diese Ideen zu Ihrem Manager und kämpfen Sie für sie.

"Manager, diese Software wird nicht getestet und ihre aktuelle Implementierung ist nicht testbar. Ich schlage vor, wir arbeiten an der Neuimplementierung in einer Sprache, die mit Design testbarer ist Muster, die ein einfacheres Testen ermöglichen. "

Nun ist es sehr wahrscheinlich, dass:

A. Dies ist ein großes Unternehmen, in das das Unternehmen nicht investieren möchte, weil es die Notwendigkeit

B nicht sieht. Herr A wird gegen dieses Zeug argumentieren und wird angehört, da er älter ist.

Wenn das passiert, haben Sie versucht, Ihre Arbeit gut zu machen und wurden erstickt. Zeit, nach einem neuen Job zu suchen.

Wenn sich dies ändert und sie Ihnen zuhören, haben Sie sich für eine Menge Arbeit angemeldet.

Sie können keine Absicht hinter der Situation annehmen.

Absichtlich von modernen Softwareentwicklungs-Frameworks ferngehalten

Er könnte sich mit was am wohlsten fühlen er weiß es am besten?

Ich habe bei großen Unternehmen gearbeitet, deren Pipeline ein Patchwork aus altem und brandneuem Code war und bei denen bestimmte Codeteile "nur funktionierten" und nie berührt wurden. Oben waren die Programmierer, die sie geschrieben haben Es war lange her und niemand verstand wirklich, wie sie funktionierten. Deshalb fügten sie einfach neue Funktionen hinzu, um den sich ändernden Anforderungen gerecht zu werden. Ihre Pipeline war immer in Betrieb, sodass jeder größere Rollout katastrophale Folgen haben konnte (dh sehr teure Arbeits- und Lieferunterbrechungen), und sie scheuten sich

Es ist eine schlechte Angewohnheit und sorgt für eine nicht optimierte Infrastruktur, hat aber tatsächlich ihre Vorzüge.

Was Sie tun könnten, insbesondere wenn Sie viel arbeiten oder den gesamten Code: Wenn es keine ordnungsgemäße Dokumentation gibt, schlagen Sie entweder vor, eine zu erstellen (wenn Sie wissen, dass Sie qua sind Sie können (wie Sie es bereits tun) mit Ihrem Manager über die Anpassung neuer Technologien oder Verbesserungen sprechen, aber erwarten, dass nichts möglich ist, wenn Sie Zeit haben, um die Arbeit zu beschleunigen.

Kommen Sie, auch wenn er Ihnen zustimmt.

Es besteht die Möglichkeit, dass niemand höher den Vorteil sieht, Ressourcen dafür auszugeben, und Ihr Versuch könnte als ah angesehen werden, das neue Blut denkt, kann die Welt verändern und Lehren Sie uns den Fehler unserer Wege.

Leider widersetzen sich Unternehmensstrukturen plötzlichen Veränderungen, und bei Modernisierungen geht es darum, den Widerstand allmählich abzubauen oder ihn Stück für Stück umzusetzen, es sei denn, Sie können nachweisen, dass Ihre "revolutionären Veränderungen dies bewirken werden" ein goldenes Zeitalter des finanziellen Gewinns ohne Risiken ".

Selbst wenn er dies böswillig tut, um seinen Job zu behalten, sehe ich es nicht in Ihrer Verantwortung, den Deckel abzublasen, insbesondere wenn Ihr unmittelbarer Vorgesetzter es ist darüber informiert.

Was würden Sie tun? mit Ihrem Vorgesetzten oder ohne ihn mit dem höheren Management oder mit dem betreffenden Kollegen sprechen?

Da Ihr Vorgesetzter beschlossen hat, die Angelegenheit nicht weiter zu verfolgen, möchte er wahrscheinlich nicht mit oder ohne Sie mit seinen Vorgesetzten sprechen. oder er hat es bereits getan und dort eine Blockade erlebt.

Wenn Sie mit seinen Vorgesetzten ohne ihn sprechen, riskieren Sie, ihn zu entfremden.

Das Gespräch mit dem Kollegen wird mit Sicherheit zu einer sehr schlechten Arbeit führen Umwelt danach und er wird sicherlich jede Anschuldigung bestreiten.

Die einzige Möglichkeit, dies zu beheben, besteht darin, Mr. A die Kontrolle zu entziehen.

Lassen Sie sich zuerst vom Management genehmigen.

Erstellen Sie einen brandneuen Git.

1. Importieren Sie einen guten, vereinbarten Startpunkt.

2. Beginnen Sie von dort aus und bringen Sie den Code vor.

3. Geben Sie Herrn A überhaupt keinen Zugriff (sagen Sie ihm nicht einmal, dass er existiert)

4. Portieren Sie Herrn A. Änderungen an Ihrem eigenen Repo oder schreiben Sie ihn neu.

5. Lassen Sie Herrn A. mit seinem Repo machen, was er will, da Sie es nicht verwenden werden.

6. Make Änderungen an gefälschten Codes, damit es bei Bedarf aktiv erscheint, um Ihr neues Repo vor ihm zu verbergen.

7. Schließlich wird der Code so weit auseinander gehen, dass er automatisch veraltet ist.

ol>

Sie müssen eine kritische Entscheidung treffen, um die Modulstrategie beizubehalten oder aufzugeben. Module sind nicht unbedingt schlecht, Sie müssen sie synchronisiert und funktionsfähig halten.

Dies wird eine Menge Arbeit sein, da Sie viel vorhandenen Code neu schreiben müssen.

Ein zusätzlicher Vorteil ist, dass der Code irgendwann so weit auseinander geht, dass er seinen Code nicht mehr beanspruchen kann. Es wird ihm völlig fremd sein.

@MightyPizza - Sie verschwenden Ihre Zeit. Arbeiten Sie für ein anderes Unternehmen, das eine bessere und bessere Zukunft hat. Sie sollten nur dann so viel Energie in die Lösung dieses Problems investieren, wenn dieses Unternehmen Ihre letzte Station ist.

Dies ist die absolut beste Antwort, die Sie erhalten werden. Bereiten Sie sich auf den Sprung vor.

"Ich möchte die Software modern, wartbar und stabil machen."

Der beste Weg, dies zu tun, ist am ersten Tag, erste Codezeile. nicht mit dem heißen Müllhaufen eines anderen.

Beachten Sie, dass dies als Nicht-Manager nicht unbedingt Ihr zu lösendes Problem sein muss (abgesehen davon, dass Sie die Anweisungen befolgen, um Dinge zu tun, die als Teil einer Lösung festgelegt wurden).

Auch , interpretieren Sie "Wir wollen, dass Problem XY gelöst wird" niemals blind in eine Aussage "... wegen Problem XY".

Beachten Sie auch, dass Sie, sobald Sie eine Initiative ergreifen, auch mit Genehmigung, die Situation zu ändern, Sie engagieren sich in der Unternehmenspolitik. In der Unternehmenspolitik gibt es keinen "unschuldigen Innovator ohne persönliche Agenda, den wir nicht für unbeabsichtigte Konsequenzen verantwortlich machen können".

Wenn Sie dies tun, tun Sie es mit eine persönliche Agenda und besitzen die Konsequenzen so oder so.

Wenn er so lange in der Position geblieben ist, zeigt dies, dass das Unternehmen bewusst oder unbewusst Hanlons Rasiermesser anwendet:

Niemals der Bosheit das zuschreiben, was angemessen ist erklärt durch Dummheit.

Es klingt sehr schwierig, tatsächliche Fälle von Bosheit zu finden, nur Dinge, die im Laufe der Zeit nicht so gut geklappt haben. Tatsächlich sieht es so aus, als hätte Herr A die Leute versuchen lassen, Dinge zu ändern, und sie dann heldenhaft behoben, wenn sie einen Fehler gemacht haben.

Sie sollten auch bedenken, dass Herr A möglicherweise unter dem Mahnwesen leidet. Kruger-Effekt, da er nicht erkennen kann, dass das, was er tut, falsch ist.

Es könnte sein, dass er einmal gut war, aber aufgehört hat zu lernen und aufgehört hat, es zu versuchen. Wer weiß. Was Sie als erstes Prinzip annehmen müssen, ist, dass Sie, egal wie ärgerlich er ist, mit ihm umgehen müssen, als wäre er kein bösartiger Agent.

Ihre Frage scheint die Annahme anzunehmen, dass er es ist ist kurz nach der Arbeitsplatzsicherheit und weigert sich, Dinge zu aktualisieren, um dies einzubetten. Sie mögen Recht haben, aber Sie können auf dieser Grundlage nicht mit ihm umgehen.

Ich bin sicher, einige Ihrer guten Ideen stoßen auf den Widerstand "Wir haben es einmal versucht und es hat aufgrund von X nicht funktioniert." Aus geschäftlicher Sicht ist dies sinnvoll. Sie sind das Risiko eingegangen, dass etwas nicht funktioniert hat. Warum sollten sie es dann erneut versuchen?

Sie geben als Ihr Ziel an.

Ich möchte die Software modern, wartbar und stabil machen.

Lassen Sie uns dies aufschlüsseln nach geschäftlichen Anforderungen

1. Modern

In der Moderne gibt es keinen impliziten Geschäftswert. Es ist auf jeden Fall fraglich. Sie sagen Java 8, andere würden sagen, Rust oder Golag sind modern. Solange ein System unterstützt wird, ist es nicht sinnvoll, es zu aktualisieren.

2. Wartbar

Dies könnte auch schwierig zu argumentieren sein. Herr A wird argumentieren, dass es wartbar ist, wie er es behauptet. Sie müssten argumentieren, dass die Wartungskosten drastisch sinken würden, um eine umfassende Änderung des Frameworks zu rechtfertigen.

3. Stabil

Sie sagen, dass Sie das System HA machen möchten, aber Sie sagen auch, dass es

die Software Ereignisse überwacht, einige Verarbeitungen an ihnen vornimmt und ergreift dann die entsprechenden Maßnahmen.

Was nicht so klingt, als würde HA benötigt.

Was tun?

Ihr System klingt wie ein großer Schlammball, der durch

Ein großer Schlammball ist ein willkürlich strukturierter, weitläufiger, schlampiger Dschungel mit Klebeband und Pressdraht und Spaghetti-Code. Diese Systeme weisen unverkennbare Anzeichen für unreguliertes Wachstum und wiederholte, zweckmäßige Reparaturen auf. Es hört sich so an, als hätten viele andere versucht und sind gescheitert.

Sie können damit beginnen, es zu umgehen:

• Wenn Sie das System nicht HA machen können, verwenden Sie a Nachrichtenbussystem oder ähnliches, um die Nachrichten auf diese Weise zu erfassen, wenn das System ausfällt, verlieren Sie keine Daten.
• Wenn Sie keine Komponententests schreiben können, schreiben Sie Systemtests. Diese sind nicht so ordentlich, aber sie ermöglichen Tests auf dem System.
• Wenn das nächste Mal eine Aktion erforderlich ist, bauen Sie diese in ein unabhängiges Subsystem ein, das den Nachrichtenbus abhören und selbst ausführen kann Aktion.
• Wenn Sie anfangen können, einige nachgelagerte Effekte zu beeinflussen (z. B. die gekapselten Aktionen zu kapseln), fügen Sie diese in ein Subsystem ein.

Es gibt einige Argumente um den majectic monolith über microservices zu unterstützen, aber es wird davon ausgegangen, dass der monolith gut konstruiert ist. In Ihrem Fall kann das System als ausgereifter Monolith in Ordnung sein, aber wenn es nicht ausgereift ist, müssen Sie die Dinge aufteilen.

Dies scheint ein guter Artikel zu sein, mit dem Sie beginnen können:

Ein häufigerer Ansatz besteht darin, mit einem Monolithen zu beginnen und die Mikrodienste an den Rändern schrittweise abzuziehen. Ein solcher Ansatz kann einen wesentlichen Monolithen im Herzen der Microservices-Architektur hinterlassen, wobei jedoch die meisten Neuentwicklungen in den Microservices stattfinden, während sich der Monolith relativ ruhig befindet.

Es ist jedoch wichtig, mitzuspielen Sagen Sie ihm bei Herrn A nicht, dass Sie das System ersetzen, sondern dass Sie "die Zuverlässigkeit verbessern" oder Redundanz hinzufügen. Wenn Sie angreifen, was er getan hat, wird er es Ihnen schwerer machen, Ihre Ziele zu erreichen.

Möglicherweise wird Ihnen klar, dass Sie das System komplexer machen. Es ist wahr, aber notwendig, wenn Sie langfristig vorankommen wollen.

Warum wollen alle Mr. A so sehr feuern? Ich denke, er hat hier nichts falsch gemacht. Bei der Softwareentwicklung geht es nicht darum, neue Dinge mit coolen Tools oder einem Framework zu erstellen. Es geht darum, eine stabile Sache zu machen, die einfach "funktioniert". Ihr Unternehmen liebt Herrn A und ist mit seiner Arbeit zufrieden.

Absichtlich von modernen Softwareentwicklungs-Frameworks ferngehalten

Ihr System befindet sich derzeit in einem stabilen Zustand. Warum muss das Team überhaupt ein modernes Softwareentwicklungsframework wie Scrum oder Agile verwenden?

Geschriebene Kerngeschäftslogik in Sprachen, die nicht getestet werden können

Muss die Kerngeschäftslogik automatisch getestet werden?

Umstrukturierte Softwarekomponenten in 30 Module, um Komplexitäts- und Versionszertifizierungsprobleme hinzuzufügen

Wie viel mehr hat diese Implementierung Ihr Unternehmen gekostet?

Sie wurde nicht skalierbar entworfen, um sicherzustellen, dass keine HA-Funktionen (Hochverfügbarkeit) vorhanden sind.

Immer noch die gleiche Frage - wie viel hat diese Implementierung Ihr Unternehmen mehr gekostet?

Meiner Meinung nach sind alle Dinge, die Sie hier aufschreiben, nur Ihre Beschwerde gegen ihn. Wenn er viele "schreckliche" Dinge getan hätte, wäre das System selbst im ersten Jahr zusammengeschmolzen, und er hätte nicht so lange in Ihrer Firma bleiben können.

Einfach gesagt, das Unternehmen muss ihm eine großzügige Gehaltserhöhung anbieten, um den aktuellen Status der Software und all das Wissen zu dokumentieren, das nicht dokumentiert wird. Dann entlassen sie ihn. Oder sie beauftragen eine technische Beratungsfirma, um alles zu dokumentieren, und er sieht die Schrift an der Wand und geht schließlich.