Frage:
Wie kann ein Mitarbeiter daran gehindert werden, das Unternehmen als Geisel zu nehmen?
MightyPizza
2018-06-04 01:55:05 UTC
view on stackexchange narkive permalink

Ich arbeite in einem Team, das Software schreibt, um einen der wichtigsten Geschäftsbereiche des Unternehmens zu unterstützen. Ich bin vor einigen Monaten dem Team beigetreten und habe festgestellt, dass mein Team aufgrund einer Person einen hohen Umsatz erzielt. Diese Person (nennen wir ihn Mr. A) ist seit 7 Jahren im Unternehmen. Es ist sehr schwierig, mit ihr zu arbeiten, und sie trifft wiederholt absichtlich schlechte Entscheidungen, um das Softwareprodukt instabil zu halten, schwer zu warten und Fehler zu beheben. Auf diese Weise kann nur er ein Problem beheben, wenn es ein Problem gibt.

Er hatte die Firma vor einigen Jahren verlassen, weil die Firma ihm nicht erlaubte, von zu Hause aus zu arbeiten, aber sobald er ging, musste die Firma ihn zurückstellen (und ihm erlauben, 100 zu arbeiten) % von zu Hause), weil die Software Probleme hatte und niemand wusste, wie man sie behebt.

Mein Manager weiß das, aber er sagt, dass er nichts gegen Herrn A. tun kann.

Was kann ich tun, um diese Situation zu beheben? Ich möchte die Software modern, wartbar und stabil machen.

Zu Ihrer Information, die Software überwacht Ereignisse, verarbeitet sie und ergreift dann geeignete Maßnahmen. Herr A hat:

  • Absichtlich von modernen Softwareentwicklungs-Frameworks ferngehalten;
  • Geschriebene Kerngeschäftslogik in Sprachen, die nicht getestet werden können;
  • Neu strukturierte Softwarekomponenten in 30 Module, um Komplexitäts- und Versionszertifizierungsprobleme hinzuzufügen.
  • Nicht skalierbar gestaltet, um sicherzustellen, dass keine HA-Funktionen (Hochverfügbarkeit) vorhanden sind.
  • Update:

    In Bezug auf nicht testbaren Code wird die Geschäftslogik von Java auf in XML eingebettete Groovy-Skripte verschoben. Die Komponententests des Java-Codes wurden verworfen.

    In Bezug auf Modularität / Komplexität hat jedes Modul ein eigenes Git-Repo und eine eigene Versionierung erhalten. Jetzt weiß nur Herr A, welche Versionen miteinander kompatibel sind. Sie können die 2.0-Version des Produkts nicht freigeben und nicht alle 2.0-Module bereitstellen. Sie müssen Modul A 2.0 freigeben, das mit Modul B 1.0-2.0 und Modul C 1.0-1.5 funktioniert. Für mich ist das schlechtes Design, es sollte alles unter einem Repo wie Spring Framework versioniert werden (Spring 5.0 bedeutet Spring-Core-5.0, Spring-Context-5.0, Spring-Web-5.0, Spring-Security-5.0 usw.).

    Der Manager sagt, er könne nichts dagegen tun, weil Herr A zuerst entlassen wurde, aber dann, wenn Probleme auftauchten, musste er zurückgerufen werden, um das Problem zu beheben. Daher kann das Produkt ohne ihn nicht gewartet werden.

    Ich sehe dies als mein Problem an, da ich den Manager nicht verlassen möchte, da er sehr nett zu mir war. Und mein erster Instinkt ist es, ein Problem zu lösen, nicht aufzugeben, obwohl ich sehen kann, wie einfach es wäre, dies aufzugeben, und ein Teil von mir ist versucht, dies zu tun.

    Andere haben das Team wegen verlassen ihn, denn beim Mittagessen ist er das, worüber sich alle beschweren. Jedes Mal, wenn es ein Treffen mit Herrn A gibt, kommen die Leute kopfschüttelnd heraus (stundenlang).

    2. Update:

    HA ist die Abkürzung für Hochverfügbarkeit. In der Softwarearchitektur bedeutet dies, dass Sie Ihre Software so entwickeln, dass sie redundant in der Produktionsumgebung gehostet / bereitgestellt werden kann. Wenn also eine Instanz ausfällt, können die anderen Instanzen die Last übernehmen, was zu Ausfallzeiten von null führt. Der Endbenutzer würde nicht einmal wissen, dass etwas schief gelaufen ist.

    In Bezug auf: Dies scheint eine normale große Codebasis zu sein. Ich glaube nicht, dass dies an der großen Codebasis liegt, da das Produkt nicht so reich an Funktionen ist. Es ist ein Backend-System, das Daten verarbeitet. Andere Unternehmen haben ähnliche Produkte, um ihre Geschäftsanforderungen zu erfüllen. Sie können dies mit modernen HA / Scalable-Optionen tun. Daher verstehe ich nicht, warum dieses Team dies in Java 6 ohne HA / Scalability tun muss.

    3. Update:

    Zu 'Arbeiten die neuesten Versionen aller Module zusammen?': Nicht unbedingt. Er hat bestimmte Module in prod zurückgesetzt, wenn ein Fehler festgestellt wurde, aber das Zurücksetzen hat mehr Fehler verursacht, da bestimmte Modulversionen nicht kompatibel sind. All dies könnte vermieden werden, wenn alle Module gemeinsam versioniert und freigegeben würden, da dann das gesamte Produkt getestet würde und insgesamt bestimmte Funktionen garantiert würden. In anderen Unternehmen / Projekten, in denen ich gearbeitet habe, konnten sie auf einfache Weise weitaus komplexere Projekte entwickeln und implementieren.

    @pipe: Ich bin nicht frisch von der Schule. Ich habe in den letzten 10 Jahren in verschiedenen Unternehmen und bei großen Projekten gearbeitet und alles, was ich als Vorschlag von Herrn A sehe, verstößt gegen Konventionen und den gesunden Menschenverstand. Mit den 30 Modulen (in separaten Repos) hatte er ursprünglich den Quellbaum eingerichtet. Ein intelligenter Entwickler, der 1 Jahr im Team war, erkannte die Kompatibilitätsprobleme und drängte darauf, alles zu einem Repo zu kombinieren, um ein Maven-Projekt mit mehreren Modulen zu erstellen. Dieser Entwickler hatte die Natur von Herrn A satt und fand einen Job bei einem der Top 5 IT-Unternehmen. Ich werde das Unternehmen nicht benennen, um dies anonym zu halten, aber mit Top 5 IT-Unternehmen meine ich Microsoft, Google, Apple, Facebook und Amazon. Dieser Entwickler war also weder dumm noch inkompetent. Er hatte 8 Jahre oder Erfahrung. Mr. A kehrte diese Änderung zurück zu dem, was es war, 30 Module in separaten Repos. Daher wurden diese 30 Module nicht hinzugefügt, um die Komplexität einer großen Codebasis zu bewältigen. Sie wurden eingerichtet, um sicherzustellen, dass das Produkt Kompatibilitätsprobleme aufweist. Unnötige Komplexität.

    Mehr zu "Warum ist das Ihr Problem?": Wenn ich mit Entwicklern spreche, die bei Microsoft, Google, Amazon, Facebook, Apple arbeiten (oder Freunde haben, die bei Microsoft arbeiten); Mir wurde gesagt, dass man oft Leute findet, mit denen man nur schwer arbeiten kann. Ich sehe diese Situation als Herausforderung, der ich mich immer wieder stellen werde, egal wo ich arbeite, egal wie großartig das Unternehmen ist. Ich muss also wissen, wie ich richtig damit umgehen soll, um in meinem Bereich weiter zu wachsen.

    Ziel (um diese Frage auf dem neuesten Stand zu halten):

    Ich stelle diese Frage, um zu wissen, wie Situationen wie die oben beschriebene am besten zu bewältigen sind, um die beschriebenen Ziele zu erreichen unten. Ich glaube, dass schwierige Mitarbeiter unmöglich zu vermeiden sind. Aufgrund der Erfahrungen anderer können wir vielleicht alle etwas lernen.

  • Verbessern Sie die Stabilität des Produkts, indem Sie den Spaghetti-Code und die unnötige Komplexität gemäß den Anforderungen des Managements minimieren.

  • Machen Sie es HA gemäß den Anforderungen des Managements Anfrage.

  • Verwenden Sie moderne Frameworks und Sprachspezifikationen (Java 6 vs Java 8), damit neue Entwickler auf dem Markt leicht zu finden sind und schneller produktiv sein können.

  • Beseitigen Sie die Abhängigkeit von einer einzelnen Person.

Kommentare sind nicht für eine ausführliche Diskussion gedacht.Diese Konversation wurde [in den Chat verschoben] (https://chat.stackexchange.com/rooms/78422/discussion-on-question-by-mightypizza-how-to-stop-an-employee-from-holding-the-c).
Ist bekannt, wann die Person in den Ruhestand geht?Wie alt sind sie ungefähr?Solche Informationen sind wichtig.
** Moderatorennotiz **: Bitte verwenden Sie Kommentare nur, um um Klarstellung zu bitten oder Verbesserungen für den Beitrag vorzuschlagen.Vermeiden Sie die Verwendung von Kommentaren für Diskussionen außerhalb des Themas und zum Veröffentlichen von Antworten.Alle weiteren irrelevanten Kommentare werden ohne vorherige Ankündigung gelöscht.
Ihre Frage macht viele Annahmen über die internen Motivationen von Herrn A. Entfernen Sie Ihre Annahmen über seine Motivationen und konzentrieren Sie sich nur auf die Fakten.Anstatt zu sagen „Er hat absichtlich schädliches Ding X getan“, geben Sie einfach an, dass er Ding X getan hat und es schädlich ist.Wenn Sie keine psychischen Kräfte haben, können Sie unmöglich wissen, dass er absichtlich Fehler einführt oder absichtlich Komplexität hinzufügt, um Probleme zu verursachen, und ehrlich gesagt sind die Wahrscheinlichkeit, dass dies wahr ist, fern.
Mir ist klar, dass die Befürwortung der Zahlung des Lösegelds eine hohe Investition in die Umstellung auf Software sein sollte, die nicht gegen Sie verwendet werden kann.Beißen Sie einfach in die Kugel und bezahlen Sie den Supportvertrag, während Sie zu einer anderen Software wechseln, die nicht von Red Hat geschrieben wurde.
Neunzehn antworten:
#1
+352
Kilisi
2018-06-04 03:33:25 UTC
view on stackexchange narkive permalink

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.

Kommentare sind nicht für eine ausführliche Diskussion gedacht.Dieses Gespräch wurde [in den Chat verschoben] (https://chat.stackexchange.com/rooms/78513/discussion-on-answer-by-kilisi-how-to-stop-an-employee-from-holding-the-Unternehmen).
#2
+192
gnasher729
2018-06-04 02:28:38 UTC
view on stackexchange narkive permalink

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.

Kommentare sind nicht für eine ausführliche Diskussion gedacht.Diese Konversation wurde [in den Chat verschoben] (https://chat.stackexchange.com/rooms/78563/discussion-on-answer-by-gnasher729-how-to-stop-an-employee-from-holding-the-comp).
(+1) "Das Problem ist nicht nur das Geld, ..." Viel schlimmer: Wenn die Software eine Schlüsselkomponente des Unternehmensworkflows ist, wenn Herr A. gegangen ist oder gestorben ist, würde das Unternehmen eine Katastrophe riskieren.Das OP sollte sich eine Frage stellen (nun, eigentlich sollte das Management): "Könnte das Unternehmen überleben, wenn die SW plötzlich nicht mehr verfügbar wäre? Und wie lange könnte es überleben?"
Da A zu 100% von zu Hause aus arbeitet, könnte es in der Tat recht einfach sein, ein ihm unbekanntes Entwicklungsteam aufzubauen - auf jeden Fall einfacher als vor Ort.
Ich stimme @Law29 zu - aber das "Renovierungsteam" müsste immer noch Büros außerhalb des üblichen Entwicklungsteams haben.
@jennifer oder nicht - wenn das gesamte Team an seiner Verachtung für diesen Charakter teilhat, würde es wahrscheinlich zu einem perversen Moralschub führen, wenn man sieht, wie sein Ersatzteam wächst
Sie können nicht drei intelligente Entwickler finden, um seinen Code herauszufinden.Sie sind zu schlau, um diesen Job anzunehmen.Stellen Sie sie stattdessen ein und lassen Sie sie einen Ersatz schreiben.Dies ist einer der wenigen Fälle, in denen eine Urknallumschreibung gerechtfertigt ist.
Stimmen Sie mit Ben Mz überein.Die drei Caballeros benötigen lediglich die UI-Beschreibung, die definierte Geschäftslogik und das Schema der gespeicherten Daten.Daraus kann jedes voll kompetente Team die Anwendung von Grund auf neu erstellen.Wenn Sie diese drei Dinge nicht festgelegt haben, sind die Probleme Ihres Unternehmens noch schlimmer als bereits beschrieben.
#3
+139
Jane S
2018-06-04 03:52:52 UTC
view on stackexchange narkive permalink

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.

Dies könnte eine willkürliche Abhängigkeit sein, da niemand dem Management mitgeteilt hat, dass die Software ohne diese Person überarbeitet werden kann.Diese Person ließ das Management glauben, er sei unersetzlich.
@Dan Genau, und das Management muss über das Risiko informiert werden, das mit seiner Organisation verbunden ist.Wie in meiner Antwort ist dies kein HR-Problem, sondern ein Problem der Risikominderung.
@jane Er war zuvor entlassen worden und das Management stellte ihn zurück.
@JaneS, Warum so negativ?Wie wäre es anstelle von "Bus Factor", dem "Lottery Factor".Wenn Herr A plötzlich 100 Millionen Dollar mit einem Lottoschein gewinnt, hat diese Firma einige Probleme.Ich sage manchmal nur "Key Man Risk".
In diesem speziellen Fall bevorzuge ich "Busfaktor".Wäre das Beste, was OP und wahrscheinlich dem Unternehmen passieren kann.
@gnasher729 Das Unternehmen, das ihn zurückstellte, achtete eindeutig nicht auf die Risikominderung.Sie haben eine Gelegenheit verpasst, das Problem zu lösen, daher muss es markiert werden, da sie beim nächsten Mal möglicherweise nicht so viel Glück haben.
@user2023861 "Bus Factor" ist ein etablierter Branchenbegriff.
Indem Sie ihn zunächst entlassen und ihn wieder einstellen, verstehen Sie das Risiko, das Herr A mit sich bringt, vollständig.Aber was dumm ist, ist, dass * das Management * schuld ist, weil sie keinen Plan haben, seine Auswirkungen zu minimieren.Sicher, es gibt eine Krisensituation, die "alles braucht, was nötig ist", aber Sie planen, zu verhindern, dass sie erneut auftritt.Dies ist das perfekte Beispiel für den Satz "Täusche mich einmal, schäme dich; täusche mich zweimal, schäme mich" ... währenddessen lacht Herr A. weiter.Es gibt dunkle Wolken am Horizont und dies ist ein% $ & * Sturm, der darauf wartet, passiert zu werden.
@user2023861 Wenn die Person im Lotto gewinnt, können Sie sie möglicherweise irgendwie davon überzeugen, Ihnen ein bisschen zu helfen.Es mag sehr teuer sein, aber es ist denkbar möglich.Wenn die Person geschlagen und getötet wird, ist es für Sie buchstäblich unmöglich, weitere Informationen daraus zu erhalten.Alles, was nicht geteilt oder aufgeschrieben wurde, ist für immer verschwunden und Sie müssen darauf verzichten.
#4
+95
Sam Weaver
2018-06-04 07:29:57 UTC
view on stackexchange narkive permalink

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.

Es ist unmöglich, von außen zu wissen, aber ist es möglich, dass dieser Mitarbeiter die Firma auf andere Weise als Geisel hält?Es klingt ein bisschen unwirklich, dass sie ihren Kopf so lange in den Sand stecken würden.
@l0b0 - Möglicherweise wurden sie getäuscht und im Dunkeln gehalten.Letztendlich möchte das Management dieses Problem entweder beheben oder es möchte, dass die Dinge fortgesetzt werden.Wenn sie wollen, dass es weitergeht, dann ist es die Entscheidung des OP, ob sie an einem solchen Ort arbeiten wollen oder nicht.
Jede Frage auf dieser Seite kann beantwortet werden: „Suche nach einem anderen Job”.
Als ich (vor langer Zeit) in meine Karriere eintrat, wurde mir gesagt, dass die Regel Nr. 1 in keinem Unternehmen lautet: "Niemand ist unverzichtbar".Ich stimme dieser Antwort zu, da das für das in der Frage beschriebene Durcheinander verantwortliche Management diese Regel 7 Jahre lang nicht befolgt hat.Daher denke ich, dass diese Antwort eine Option für das OP ist.
#5
+64
selbie
2018-06-04 04:03:55 UTC
view on stackexchange narkive permalink

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.

Abhängig davon, wie "praxisnah" der Manager bei der Codeüberprüfung ist, könnte das OP dem Manager auch mitteilen, wie oft der Code von Herrn A abgelehnt wird, sofern dies nicht kritisch gesagt wird.Wenn Sie es zu einer Frage machen, kann dies dem Manager helfen, "selbst darüber nachzudenken", was dazu führen kann, dass der Manager Herrn A loswird, ohne dass der "Fehler" auf das OP fällt.Beispiel: "Ich habe mir die Pull-Anfragen von Herrn A angesehen, um mein Wissen in der App zu erweitern. Ist es normal, dass Codeüberprüfungen so viele Ablehnungen haben, bevor sie bereitgestellt / akzeptiert werden?"
Das Team hat ihn bisher nicht befragt, da er bis jetzt Leute mit 0-3 Jahren Erfahrung hatte.Jetzt gibt es mich und einen anderen Mann, der gerade beigetreten ist. Wir haben ungefähr 10 Jahre Erfahrung.Wenn wir ihn befragen, sagt er nur, dass er es so will, oder er wird herablassend, z. B. "Warum willst du die Geschichte der Git zu einem Chaos machen?"Er sagte, wenn sich jemand weigerte, Git-Commits zu ändern, anstatt sich mehrmals zu verpflichten, wie es normale Leute tun.Er möchte, dass Entwickler Git-Commits ändern.
@MightyPizza ... ok, jetzt etwas Bestimmtes.Ich bin sicher, dass er Recht hat, und Sie müssen ihm zuhören.Ich wette, er schlägt vor, dass Sie Ihre Commits zu einem Commit (in einem bekannten Arbeitszustand) zerquetschen, bevor Sie sie verschieben.Git-Fetch / Git-Rebase (niemals Git-Pull) und Squash-Commits vor dem Push, sodass 100% der Zeit schnell vorwärts zusammengeführt werden.Er hat recht.Wenn Sie Überprüfungs-Commits codieren, möchten Sie nicht, dass sie aus einer zufälligen Folge bestehen, in der Sie den Master den ganzen Tag über neu basiert haben, während Sie eine Reihe kleiner Commits ausführen, von denen nur der letzte tatsächlich erstellt wird.Überprüfen Sie 1 Commit, das bekanntermaßen getestet / erstellt wurde.
(Es ist nicht dasselbe wie das Ändern des Verlaufs übrigens. Wenn jeder 1 Commit drückt, wächst die verknüpfte Liste der Commits am Ursprung um 1. Sie schreiben Ihre Commits neu, sodass Ihr Push auch 1 atomares, funktionierendes und getestetes Commit drückt, wenn Sie müssenBei mehreren Commits müssen sie alle Tests bestehen und bauen. Zerquetschen Sie das kaputte Material, denn es ist, als würden Sie Transaktionen auf halbem Weg sehen.)
@Rob Das Problem, das ich mit seinem Ansatz habe, ist, dass er Entwickler auffordert, ein Commit für eine Änderung durchzuführen, es dann auf Remote zu übertragen, dann weiter an derselben Änderung zu arbeiten, das lokale Commit zu ändern und dann Push auf Remote zu erzwingen (weil jetzt regelmäßigPush schlägt aufgrund des vorherigen Push fehl).Für mich ist das falsch.Ein Force Push im Rahmen der regulären Codierung ist schlecht.Dem Squash-Teil stimme ich zu.Ich habe keine Probleme damit.Es ist die Änderung von Commits und Force Pushs und ich bin nicht zufrieden damit.Gedanken?
@Rob Außerdem wird jedes Commit atomar sein. Für mich sollte ein Commit durchgeführt werden, wenn eine sinnvolle Änderung abgeschlossen wurde und der Quellbaum noch kompiliert werden kann.Dies bedeutet nicht, dass die gesamte Änderung für dieses Ticket / diese Filiale vorgenommen wird.Zusätzliche Commits wären normal, z. 1: Modul A geändert, um Feature X mit Unit-Tests hinzuzufügen, 2: Modul B geändert, um Merkmal X mit Komponententests hinzuzufügen, 3: Problem mit Komponententests in Modul A für Funktion X behoben
Einige Tools zwingen Sie sogar zum Squash / Rebase.Wir mussten definitiv mit Gerrit (einem Google-Tool).Der Punkt beim Quetschen ist, dass diese Commits Ihre Maschine nie verlassen haben, es ist also keine Änderung in der Geschichte.Sie stapeln Ihre Änderungen nur auf das letzte Ursprungs-Commit, sodass es so aussieht, als hätten Sie das vorherige öffentliche Commit bearbeitet.Bei meinem letzten Job würde niemand Commits auf andere Weise akzeptieren, und sie hatten Recht.
bei Force Push: Git Fetch;Git Rebase.Arbeiten Sie an Ihrem Zweig, quetschen Sie das Commit und drücken Sie.Dieses einzelne Commit wird als Ganzes akzeptiert oder abgelehnt, da Sie keine Reihe von Commits präsentieren, die voneinander abhängen.Wenn Sie abgerufen und neu basiert haben, werden Ihre Pushs 100% der Zeit schnell vorgespult.Sie werden niemals einen Konflikt beim Zusammenführen sehen.Wenn jemand direkt nach dem erneuten Basieren gedrückt hat, holen Sie ihn erneut und drücken Sie erneut.Wenn Sie auf diese Weise arbeiten, werden Sie fast nie Kopfschmerzen beim Zusammenführen haben.Nur Force Push wäre Ihr Zweig, der bei Ablehnung überprüft werden kann.
@MightyPizza Warum haben Sie ein Problem mit diesem Ansatz?Das ist der springende Punkt bei einem VCS.Was tun Sie, wenn Ihr lokales Repository aus irgendeinem Grund beschädigt wird oder verloren geht?Der Vorteil eines verteilten VCS besteht darin, dass Sie kleine lokale Commits durchführen können, bis der Code vollständig fertig ist, und daher nicht alles neu schreiben müssen, wenn ein Ansatz nicht funktioniert.Das regelmäßige Übertragen von Codeänderungen in den Remote-Zweig schützt Sie davor, das Ganze von vorne beginnen zu müssen, und ermöglicht anderen Personen, Ihren Teilcode zu verwenden, ohne zu warten, bis er vollständig ist.
@MaskedMan Vielleicht habe ich die Situation nicht richtig erklärt.Herr A bittet um ein Commit pro Ticket. Wenn mehrere Commits als Kontrollpunkt erforderlich sind, möchte er, dass das anfängliche Commit geändert und erzwungen wird.Während ich darum bitte, häufige Commits in der Ticketfiliale durchzuführen und mit Squash zusammenzuführen, um den Verlauf beim Commit zu minimieren.Keine Kraftstöße erforderlich.Ist das schlecht?Wollen Sie damit sagen, dass seltene Änderungen und Force Pushs besser sind als häufige Commits und Merge Squash (kein Force Push)?
@MightyPizza Du meinst Force Push auf den Master / Integration / Feature-Zweig?Dann haben Sie Recht, Force Push ist dort völlig falsch.Ich dachte, es würde Gewalt bedeuten, auf "Ihren" entfernten Zweig zu drängen. Tut mir leid, dass ich das falsch verstanden habe.
@MaskedMan Keine Sorge.Das Erzwingen eines Drucks auf den Zweig mit Remotefunktionen ist das, was Herr A verlangt.
#6
+44
walen
2018-06-04 14:32:56 UTC
view on stackexchange narkive permalink

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

Ihr Problem :

Niemand wusste, wie man es behebt .

Ihre Lösung :

  • Erfahren Sie, wie Sie das Problem selbst beheben können.
  • Dort Jetzt braucht die Firma den anderen nicht mehr.

    Das hat eine interessante Dynamik.Durch die Übernahme der Aufgabe, den verschleierten Mist zu verstehen, ist dieser Kerl nicht mehr die einzige Person mit diesem Wissen.Dem Manager zu erklären, dass Sie dies (wahrscheinlich zunächst in Ihrer Freizeit) tun, um das institutionelle Wissen zu verbreiten, zeigt Initiative, Vernunft und bietet Ihnen letztendlich die Möglichkeit, diese Person zu ersetzen, die seit Jahren eine toxische Entwicklungsumgebung bereitstellt.Und wenn sie dich nicht dabei mögen, hör sofort auf.Es ist eindeutig eine schlechte Umgebung
    Ich mag diese Antwort, weil dies der einzige Weg ist, solche Software in eine bessere Zukunft zu führen.Das Unternehmen hat im Laufe der Jahre ehrlich gesagt nur zwei Dinge gelernt: 1) Herr A hat eine Software entwickelt, die die Dinge in Bewegung hält.2) Unzählige Neulinge sind gegangen, weil sie nicht gut genug sind.
    Das ist die Antwort.Wenn sie den Kerl zurückgestellt haben, dann ist diese App eine Geldkuh.Wenn niemand anders daran arbeiten kann, kann er auch nicht behaupten, einen besseren Weg zu kennen.Sie müssen tatsächlich erfolgreich ein besseres System entwickeln, um das zu wissen.
    Es sei denn, das Lernen (\ * Husten \ * _Deobfuscating_ it) erfordert eine größere Investition, als ihn vorerst einzustellen ... Wenn der Systemnutzen schließlich nachlässt, hat das Management hoffentlich die Lektion gelernt und verfügt bereits über ein geeignetes Team, das lesbaren Code dokumentiert und erstelltim neuen System ...
    #7
    +37
    ctrl-alt-delor
    2018-06-04 17:59:20 UTC
    view on stackexchange narkive permalink

    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 normale Bedeutung von "Ich habe gesehen, was er meinte."ist "Ich war einverstanden mit dem, was er sagte."Es wird hier jedoch sarkastisch verwendet und hat die fast entgegengesetzte Bedeutung von „Seine Argumentationsweise ist falsch“.
    Ich verstehe, was der Autor gesagt hat.Jane ist mit ziemlicher Sicherheit die wirklich brillante, aber in typischer Manager-Manier;Der Manager findet die Person, die die nicht entzifferbare Monstrosität erzeugt, großartig, schließlich versteht sie ein so komplexes Problem.Wenn die Realität so ist, dass wirklich großartige Entwickler ein Händchen dafür haben, den Komplex in relativ einfache Lösungen umzuwandeln.Mein erster Kommentar war nur ein Vorschlag zur Verbesserung Ihrer Antwort, weil mir Ihre Antwort gefällt, aber ich denke, dass viele Leute den Punkt verpassen werden, ohne dass Sie den Punkt explizit angeben.
    @Dunk Wenn Sie einen Vorschlag haben, fügen Sie ihn der Antwort hinzu.Oder als Kommentar.
    Hilarious: D Ja, mach weiter und poste das an der Wand!
    @ctrl-alt-delor Es kann auch bedeuten: "Ihre Unternehmens- / Branchenwerte ziehen Wolle mehr über die Augen der Kunden als gute Arbeit."Es ist völlig offen für Interpretationen.
    Beeindruckend!Das gilt wirklich für mein Team.Mein Manager hat mir heute gesagt, dass er Herrn A schätzt, denn wenn die Dinge kaputt gehen, repariert er sie und rettet den Tag.Was meinem Manager egal war, war, warum die Dinge überhaupt in die Brüche gingen.
    @MightyPizza Nach all den Diskussionen und dem, was Sie gesagt haben, denke ich fast, dass Mr.A jemand sein könnte (ich kann mich irren), der es wagen könnte, einige Fehler gezielt in den Code einzufügen, um sie später zu beheben, nur um die Firma als Geisel zu halten.Wenn dies zutrifft, könnte dies in einigen Ländern ein Verbrechen sein.Wenn Sie dies jemals vermuten und Beweise haben, würde ich in Betracht ziehen, mit Ihrem Manager darüber zu sprechen.Natürlich ist dies ein riskantes Geschäft, denn es scheint, dass Mr.A ein kluger Kerl ist, und wenn er wirklich so etwas getan hat, wäre es schwer zu beweisen.Ich kann verstehen, warum viele Menschen das Unternehmen verlassen haben.
    @MightyPizza wird niemals auf Bösartigkeit zurückgeführt, was leichter auf Dummheit zurückzuführen ist.Nach meiner Erfahrung war es keine bewusste Entscheidung.Oft folgt es nur der Belohnung (dafür wurde er in der Vergangenheit belohnt; das schätzt sein Arbeitgeber.)
    Danke für diese Antwort.Ich erinnere mich an die Geschichte, aber ich erinnerte mich nicht, aus welchem Buch sie stammte.
    Entschuldigung, aber das IMO-Management wird nicht auf die Idee kommen.Wenn sie das Risiko bisher nicht verstehen, muss diese Beschreibung eine schwierige Anspielung sein, damit sie sie fangen können.Sie werden auch denken, Fred ist der brillante Typ und Jane ... nun, sie hat nur diese einfachen Aufgaben erledigt und sich nicht bewährt, oder?;-);
    @ctrl-alt-delor Stimmt, aber achten Sie auf Muster.Ich habe mit einer Person zusammengearbeitet, die nie ganz überrascht war, Änderungen vorzunehmen, die Systemprobleme verursachen würden, die er beheben konnte, oder die OT verursachten, aber im Laufe der Jahre habe ich gelernt, das Problem zu erkennen.Besonders die Abwehr, als er gefragt wurde, warum Teile des Systems so waren.Im Nachhinein ist es offensichtlich.Niemals zuschreiben, es sei denn, Sie erwischen sie auf frischer Tat, wenn Sie sich wegen eines Problems ins Gesicht lügen, das das gesamte System lahm legen könnte.Einige Leute kreieren ihre eigenen Belohnungen.
    @Underverse Mein Punkt ist, dass man nicht sagen kann (was die Motivation ist).Es geht nicht darum, nicht wegen schlechter oder fehlender Beweise zu verurteilen (obwohl dies auch wichtig ist).Es geht darum zu erkennen, dass schlechtes Training zu denselben Symptomen führen kann.https://www.youtube.com/watch?v=BJYsregPlM4
    #8
    +28
    Philip Kendall
    2018-06-04 02:13:19 UTC
    view on stackexchange narkive permalink

    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.

    Tatsächlich.Und es ist eine kurzfristige Investition, die letztendlich massive langfristige Vorteile hätte, möglicherweise sogar finanzielle (hoher Umsatz ist teuer!)
    Herabgestuft aus dem einfachen Grund, dass selbst der klügste Mann der Welt in wenigen Monaten nicht in der Lage ist, mehrere Jahre Arbeit zu durchdringen *, insbesondere wenn die verantwortliche Person ein begründetes Interesse daran zu haben scheint, Code zu verschleiern, Fallen zu bauen oder zu verwendenversteckte Compiler-Tools *.** Der Kerl wurde bereits gefeuert! ** Erstens wachsen wirklich kluge Kerle nicht auf Bäumen, man muss sie identifizieren und sie sind sehr teuer.Zweitens, wie gnasher729 betonte, schauen Sie zuerst von Experten, wie schlimm die Situation wirklich ist * ohne A wissen zu lassen * und entscheiden Sie erst dann (!), Was getan werden kann.
    tatsächlich.Der "Busfaktor" wurde bereits erwähnt.Das Risiko ist bereits da und es macht mehr Spaß, der Bus zu sein.Führen Sie ihn über (im übertragenen Sinne natürlich!) Und leiten Sie die Firma weiter
    Wenn Sie ihn entlassen, zeigt das Unternehmen in den 6-Uhr-Nachrichten, dass mehr als 100 landesweite Unternehmen schwer betroffen sind.
    @MightyPizza - gleiche Situation, wenn er sich entscheidet zu gehen oder von einem Bus angefahren wird.Es ist eine unhaltbare Situation, mit der sie sich befassen müssen
    @ThorstenS.Ja!Genau!Ich musste einmal ein Stück SW verbessern, das von einem Computerlinguisten geschrieben wurde, um das Unternehmen für eine Stelle an einer Universität im Ausland zu verlassen.Der Typ war eine Art "Genie" auf seinem Gebiet, aber ein ziemlich schlechter Programmierer (naja, ich würde sagen, ein armer SW-Ingenieur).Die SW war eine ~ 10kLOC + Monster PERL quasi-monolithische Schrift!Es hat funktioniert, aber es war ein Durcheinander (und er hat nicht versucht, etwas zu verschleiern).Nach einem Monat Analyse und Feedback von ihm, nachdem ich die Spezifikation der SW aufgeschrieben hatte, entschied ich mich, sie komplett in Java neu zu schreiben!...
    @ThorstenS.... Ja, anfangs gab es einige Sprünge, aber die Aufräumarbeiten lagen den Aufwand und die 3 Monate Arbeitszeit für die Erstauslösung (nur bei Kernfunktionalitäten).Nach dieser ersten Veröffentlichung war es ein Kinderspiel, die restlichen und neuen Funktionen wieder hinzuzufügen.Hätte ich hartnäckig versucht, das ursprüngliche Drehbuch zu verbessern, wäre ich in ein schmutziges und langes Kaninchenloch gegangen!
    Ich frage mich, ob es billiger wäre, Herrn A einfach auszuzahlen.Geben Sie ihm eine Sinecure, um in seiner Freizeit für die nächsten zwei Jahre Projekte durchzuführen, abhängig davon, dass er seinen eigenen Busfaktor entfernt und die erforderliche Dokumentation bereitstellt, um den Code von Grund auf neu auszuführen.
    #9
    +25
    coteyr
    2018-06-04 12:08:53 UTC
    view on stackexchange narkive permalink

    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.

    "... aber du kannst ein total geniales Produkt mit total beschissenem Code."Es wird nicht lange großartig bleiben.
    Das Unternehmen wird sich auf lange Sicht immer noch mit dem Busfaktor auseinandersetzen müssen.Sollte Herr A das nächste Mal endgültig verschwinden, ist das Unternehmen möglicherweise nicht bereit, die Auswirkungen dieses Ereignisses zu bewältigen.Es ist jedoch möglich, dass das Unternehmen bereits plant, etwas zu unternehmen oder zumindest einen Fonds einzurichten, um mit den möglichen Folgen dieser Situation fertig zu werden.
    @jpmc26 Wenn die einzige Definition von "fantastisch" "profitabel" ist, könnte es lange genug fantastisch bleiben, insbesondere wenn ein Produkt / eine Dienstleistung allein in einem Markt mit hohen Eintrittsbarrieren existiert.
    @jpmc26 hat meiner Erfahrung nach, Code von schlechter Qualität, sehr wenig damit zu tun, wie gut ein Produkt aufgenommen wird.Als Beispiel gebe ich Ihnen Civ 5. Sie konnten tatsächlich den schrecklichen verschachtelten Riesen für die Schleife sehen, wie die Karte dargestellt wurde.Dennoch war es trotzdem profitabel.
    AFAIK Die meisten großen Banken arbeiten immer noch auf Mainframes mit über 30 Jahre alten COBOL-Konten usw. - Ich würde sagen, dass Gewinnberichte im Wert von mehreren Milliarden Dollar ziemlich beeindruckend sind?
    Ich bin vollkommen einverstanden.Sie können auch wirklich großartigen Code schreiben, der kein Geld verdient.und ich würde vorschlagen, dass Code, der sich auf SE-Reinheit konzentriert, anstatt das zu tun, was der Kunde will, immer in diese Kategorie fällt.Das einzige, was zählt, ist, dass das Produkt Geld verdient.
    @Rob Entschuldigung, aber ich bin einigermaßen anderer Meinung.Der Zweck eines guten Managements besteht nicht darin, einfach "Geld zu verdienen", sondern "mehr Geld zu verdienen".Wenn eine total beschissene SW Geld verdient, aber das Unternehmen daran hindert, mehr zu verdienen, dann ist es nicht gut.Wartungskosten sind beispielsweise Verbindlichkeiten, auch wenn Ihr Produkt die Gewinnschwelle überschreitet.Sie verschwenden Ressourcen, um das gleiche Geld zu verdienen, das Sie mit einer besseren Software verdienen könnten, und Sie behindern wahrscheinlich die zukünftige Entwicklung des Unternehmens....
    @Rob ... Natürlich ist das OP nicht für das Management zuständig, aber Manager verstehen technische Themen selten.Gute Manager schätzen Mitarbeiter, die auf Ineffizienzen im Workflow / in den Prozessen des Unternehmens hinweisen können, weil sie ihnen bei ihrer Managementarbeit helfen.
    #10
    +12
    Rui F Ribeiro
    2018-06-04 12:36:31 UTC
    view on stackexchange narkive permalink

    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ß.

    Nun, es ist immer schwierig, wenn Manager auf die Bereitstellung neuer Funktionen drängen.Entwickler wissen, dass es wirklich notwendig ist, die Codebasis anzuhalten und umzugestalten.Aber wie kann man den Manager überzeugen?
    Manchmal und im obigen Beispiel gibt es bei regelmäßigen Abstürzen in jedem letzten Trimester keine wirklichen Alternativen.Es war definitiv zum Besseren.
    #11
    +10
    Artelius
    2018-06-04 09:09:33 UTC
    view on stackexchange narkive permalink

    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.
    3. 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.

    Ich würde mir über Ihren ersten Nachteil keine Sorgen machen.Aufgrund des [Conway-Gesetzes] (https://en.wikipedia.org/wiki/Conway%27s_law) ist die Anwendung wahrscheinlich bereits so aufgebaut, dass sie die Unternehmensstruktur widerspiegelt, unabhängig davon, ob Herr A dies beabsichtigt hat oder nicht.Die Lösung des OP würde wahrscheinlich auch von Grund auf neu erstellt werden.Wenn es die Struktur seines Teams (von 1) widerspiegelt, kann es natürlich zu einem Monolithen kompiliert werden. In diesem Fall kann Option 1 ohnehin ein unhaltbarer Ansatz sein.Und alles in allem ist dies immer noch etwas, was das OP nicht alleine tun kann, zumindest nicht durch einen direkten Ansatz.Er braucht ein Management-Buy-In.
    #12
    +4
    Dan
    2018-06-05 19:07:00 UTC
    view on stackexchange narkive permalink

    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 sind entweder ein Junior oder haben noch nie mit solchen Menschen gearbeitet.
    @BЈовић Ihre Meinung wäre viel aussagekräftiger - zumindest für mich -, wenn Sie etwas Spezielles zur Sicherung mitteilen würden.Meinungen ohne Fakten sind nicht umsetzbar.
    @employee-X Ich hatte das Pech, tatsächlich mit einer Person zu arbeiten, die der in der Frage beschriebenen Person ähnlich ist.Er war immer der klügste, alle anderen dumm.Er war auch unersetzlich, weil er seinen Schlammball halten musste.Mein Manager sagte auch, er könne nichts tun.Aber anstatt mitzumachen, machte der Rest des Teams diesen Kerl zur Hölle.Es war so gut als er ging :)
    #13
    +4
    DigitalBlade969
    2018-06-06 10:18:07 UTC
    view on stackexchange narkive permalink

    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.

    #14
    +3
    cybernard
    2018-06-06 21:41:46 UTC
    view on stackexchange narkive permalink

    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.

    8. 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.

    Die Worte "Code einfrieren" fallen mir ein.Wenn Herr A immer wieder neue Änderungen einführt, bleibt Ihr Projekt immer zurück.Um es zu ermöglichen, es zu ersetzen, muss das Management Herrn A anweisen, seinen Code über minimale und dringende Fehlerbehebungen hinaus einzufrieren.Das ist der fehlende "Punkt Null" in Ihrer Liste.Wenn Ihr Projekt zur Einführung bereit ist, können Sie die vorhandene Codebasis von Herrn A vollständig ersetzen.
    Beachten Sie auch eines: Wenn Herr A glaubt, dass seine Kontrolle entzogen wird und so hinterhältig ist wie beschrieben, wird Herr A einfach zurücktreten oder drohen.Dieser Plan braucht eine Eventualität.Auch hier ist ein Einfrieren des Codes und eine minimale Fehlerbehebung erforderlich, bis ein Ersatz bereitsteht.
    @cybernard: "guter, vereinbarter Ausgangspunkt".Das Problem ist, dass Herr A Zeit und Erfahrung hatte, um sicherzustellen, dass niemand sonst weiß, was dieser Ausgangspunkt sein würde, und sogar um sicherzustellen, dass kein solcher Punkt existiert, wenn er nicht möchte, dass er existiert.
    @mathreadler Dann müssen Sie nur noch einen Punkt auswählen und sich damit befassen.Beginnen Sie mit dem Code von gestern.Sie können auch von vorne anfangen.Jede Option wird ** brutal ** sein, aber dann wird sie langfristig behoben.
    @cybernard, aber es scheint, dass ständig dringende Probleme auftauchen, so dass es schwierig ist, langfristige Probleme zu berücksichtigen.
    @mathreadler Gibt es eine Prüfung zur Überwachung der Änderungen, die Herr A vornimmt, um festzustellen, ob er keinen Code hinzufügt, damit diese "dringenden" Situationen auftreten können?Auch hier kommt ein brandneues Repo ins Spiel. Er kann es nicht weiter sabotieren, und Sie können anfangen, die Spaghetti abzuwickeln.Ich persönlich denke, Herr A. hat Monate im Voraus geplant, damit er zusehen kann, wie Sie Ihre Räder drehen und bis zur Bank lachen.Sie hätten "Smart Developer" übernehmen lassen, Mr. A entlassen und die Teile anschließend abgeholt.Ich wette, Ihre Probleme wären inzwischen gelöst.Ansonsten bist du eine ständige Geisel.
    @mathreadler Es sei denn, Sie möchten etwas wirklich Verschlagenes.Lassen Sie jemanden fälschen, gehen Sie wütend aus der Tür, besonders mit Mr. A. in der Nähe.Jetzt arbeitet er / sie von zu Hause oder von einem anderen Ort aus, um den gesamten Code neu zu schreiben, oder startet ein neues Repo und macht rückgängig, was Herr A getan hat.Meldet sich nur beim Manager und nur dann, wenn der Code bereit oder ausreichend bereit ist.
    @mathreadler (gefälscht) gibt bekannt, dass Ihr Kunde ein Sicherheitsaudit durchläuft, das von einigen Branchengesetzen / -vorschriften usw. vorgeschrieben wird. Ihr Code muss das Audit bestehen, oder er wird Sie entlassen.Jetzt hat Herr A ein echtes Problem, Java 6 wird das Muster nicht bestehen und er kann nichts verlangen, wenn Sie nicht im Geschäft sind.Sie werden wahrscheinlich die Hilfe der Kunden benötigen, damit es real erscheint.ODER - Ihr Hauptkunde verlangt von Ihnen, dass Sie ein Sicherheitsaudit durch eine unabhängige Firma selbst prüfen.Wenn Ihr Code nicht innerhalb von 6 Monaten übergeben wird, werden sie an einen anderen Ort verschoben.
    #15
    +2
    Mark Lapasa
    2018-06-04 09:58:19 UTC
    view on stackexchange narkive permalink

    @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.

    Wenn der beste Weg am ersten Tag ist, wird Ihre Software wahrscheinlich ab dem zweiten Tag nicht mehr "modern, wartbar und stabil" sein.
    Oh Mann, ich kann nicht einmal richtig lesen.es ist spät.Es ist jedoch einfacher, modernen und wartbaren Code ohne den Aufwand von Legacy zu schreiben.Stabil kommt mit der Zeit.
    @mark Sie haben Recht, es ist einfacher, aber wir haben alle alten Kabeljau.Um es umzuschreiben?Es kann eine RIESIGE Menge Geld kosten (ohne einen sofortigen / relativ kurzfristigen ROI) und noch mehr Zeit (die Sie möglicherweise nicht haben).Möglicherweise benötigen Sie auch mehr Ressourcen als Sie haben.Endergebnis?Ein Produkt, das weniger ausgereift, weniger stabil und möglicherweise weniger funktionsreich ist als das vorhandene.Tut mir leid, aber das Umschreiben ist meistens keine Option.
    Oh, und mit einem solchen Haufen von Vermächtnissen umzugehen, die Schritt für Schritt und ohne Unterbrechungen ein neues modernes Produkt formen, umschreiben, wann / was erforderlich ist, und den gesamten Weg umgestalten, ist ... nun, was jeder (professionelle) Entwickler jeden Tag tut(sogar mit seinem eigenen Legacy-Code, den er vor zwei Jahren geschrieben hat)
    Das erinnert mich an: [Dinge, die Sie niemals tun sollten] (https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/) ...
    @AdrianoRepetti + Andere: Ich weiß nicht, warum das Downvote, aber ich habe nicht befürwortet, bei der Firma zu bleiben, um es neu zu schreiben.Ich habe mich dafür ausgesprochen, die gewonnenen Erkenntnisse zu nutzen und dorthin zu gehen, wo Wachstum statt Wartung zum kurzfristigen Nutzen stattfindet, wie Sie beschrieben haben. Jeder Tag, an dem MightyPizza versucht, dieses Problem zu lösen, ist ein Tag weniger, an dem er fliegen kann, anstatt geerdet zu sein.
    Die Abstimmungen (die ich nicht gemacht habe) sind wahrscheinlich teilweise auf diese ziemlich arrogante Aussage zurückzuführen: _Dies ist die absolut beste Antwort, die Sie bekommen werden _.... es ist nicht konstruktiv und es verringert den Aufwand der anderen Antworten hier ....
    Ich habe nicht abgelehnt, aber ich stimme cale_b zu, und IMO ist sowieso nicht die Lektion, die man lernen muss. Im Leben eines Entwicklers wird es immer Legacy-Code geben (es sei denn, Sie arbeiten mit sehr kurzen One-Shot-Projekten, bei denen Sie nie die grundlegenden Erfahrungen sammeln werdenWartbarkeit) und es ist wichtig zu lernen, wie man damit umgeht (weil Code, den Sie heute schreiben, morgen Legacy-Code sein wird).
    Ich wollte eine Antwort schreiben, aber die beste war schon da.+1.
    #16
    +2
    rackandboneman
    2018-06-07 03:37:05 UTC
    view on stackexchange narkive permalink

    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.

    #17
    +1
    Jeremy French
    2018-06-11 20:53:56 UTC
    view on stackexchange narkive permalink

    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.

    #18
    +1
    gachiemchiep
    2018-06-25 13:29:57 UTC
    view on stackexchange narkive permalink

    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.

    `Gibt es eine Anforderung, dass die Kerngeschäftslogik automatisch getestet werden muss` Ja.**Immer**.Es wird überprüft, ob Änderungen am Code vorhandene Anwendungsfälle nicht beschädigen.Es überprüft, ob der Code wie beabsichtigt funktioniert und wie beabsichtigt fehlschlägt.Es ist Ihre Roadmap auf dem Weg ins Chaos, die die Entwicklung von Unternehmenssoftware ist.
    (... cont) Die Frage macht deutlich, dass es in prod häufig Versionsinkompatibilitäten gibt und dass niemand weiß, welche Versionen miteinander kompatibel sind.Unit-Tests würden dies leicht auffindbar machen
    Wichtig ist, dass die Frage mir keine eindeutige Zahl darüber gab, "wie viel Schaden Mr.A angerichtet hat".Alle Details in dieser Frage können nur dazu führen, dass "Herr A den Entwicklungsprozess verlangsamt".Wenn die Arbeit von MrA alle Kosten-, Zeit- und Qualitätsanforderungen erfüllt, ist das in Ordnung.
    Ähm ... ich bin mir nicht sicher, ob du die ganze Frage gelesen hast.Das Hauptproblem hierbei ist, dass die Software sehr instabil ist.Wir bekommen ständig Ausfälle, er muss jedes Mal gerufen werden, um den Tag zu retten.Neueinstellungen können sinnvoll sein, wenn die Software aufgrund des nicht standardmäßigen Grundes, warum Dinge implementiert wurden, so dass sie nach 6-12 Monaten verlassen.Es ist auch nicht skalierbar, es ist langsam, benötigt viel mehr Speicher als es sollte.Die Verwendung moderner Frameworks hätte all diese Probleme gelöst.
    Ich verstehe, dass Mr.A Ihr System mit einem sehr niedrigen Qualitätsstandard hergestellt hat.Aber mein Punkt ist: Selbst wenn die Qualität von Mr.A sehr schlecht ist, ist es völlig in Ordnung, wenn er KEINE Fehler verursacht, deren Behebung Ihrem Unternehmen eine Menge Geld kostet.Alle Manager da draußen würden gerne mehr Server oder Ram hinzufügen, wenn dies ihr Problem lösen könnte.Ich denke also nicht, dass "mehr RAM zum Arbeiten benötigen" überhaupt ein Problem ist, tut mir leid.
    #19
      0
    torogiant
    2018-06-10 04:47:56 UTC
    view on stackexchange narkive permalink

    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.



    Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 4.0-Lizenz, unter der er vertrieben wird.
    Loading...