Hat es jemals geholfen, es auf Ihre Art zu tun? Gab es jemals eine Zeit, in der Sie Indirektion und Injektion und zusätzliche Schnittstellen verwendet haben, und es gab eine Abweichung in letzter Minute, und alles wurde reibungslos und schön ohne Fluchen gehandhabt? Selbst bei einem früheren Job, wenn Sie diesen Code nie hierher bekommen konnten?

Ich gehe mal davon aus, dass es das gab. Übe, diese Geschichte zu erzählen . Es ist spezifisch und real. Es ist nicht "x könnte passieren" oder "y könnte sich ändern", sondern "Ich habe es einmal so gemacht und so hat es geklappt." Manager (ich spreche als einer) sind misstrauisch, wenn es darum geht, Geld auszugeben (und glauben Sie mir, wenn Sie komplizierteren Code schreiben, den andere auf Anhieb nicht verstehen können, geben Sie Geld aus) für das, was passieren könnte . Sie wollen keine Spekulation finanzieren, die laut Internet nur auf "Buchlernen" und der neuesten Modeerscheinung beruhen könnte. Aber wenn Sie auf Ihre Erfahrung zurückgreifen? Das ist eine ganz andere Situation.

Ich bin kein großer Fan von Fabriken, Anbietern, Injektoren und so weiter. Sie sind im Allgemeinen für Dinge eingerichtet, die nie wirklich passieren werden (Wechsel von MS SQL zu Oracle) oder wenn sie es tun (Wechsel des Ordners, in dem die Dateien gespeichert sind), nur geringe Auswirkungen haben. Sie haben einen Platz in sehr volatilen Arrangements, in denen Sie sich zu befinden scheinen. Sie müssen also zeigen, dass sie diesen Platz haben. Sie scheinen aus einer Position zu kommen, in der Sie sagen: "Das ist der normale Weg, Dinge zu tun, und ich brauche einen Grund, es nicht zu tun." Ihr Manager kommt von: „Das ist nicht normal; normal ist direkt und einfach. Geben Sie mir einen guten Grund, eine weitere Schicht in den Weg zu legen.“ Arbeite an diesem Grund. Arbeiten Sie an einer real passierten Erfolgsgeschichte in der Vergangenheitsform, bei der diese zusätzliche Schicht Tage oder Wochen Arbeit gespart hat. Begründen Sie Ihr Engineering, sonst ist es wirklich Over-Engineering.

Dieses Zitat aus einem Ihrer Kommentare beunruhigt mich.:

Als Software-Ingenieur wird es mir zur zweiten Natur, Dinge zu tun, die an der Oberfläche keinen triftigen Grund haben könnten, wie das Verbinden der Unbekannten, die ich erwähnt habe. Ständig am Rande stehen zu müssen, mich zu sehr technischen (und manchmal sehr eigensinnigen) Themen zu erklären, erschöpft mich.

Ich habe mehrere Wiederholungen des folgenden Lebenszyklus gesehen:

• Ein erfahrenes Programmierteam entwickelt einen anderen Ansatz für die Programmierung.
• Es wird für einige Jahre bis zu einem Jahrzehnt als etwas angesehen, das trotz aller Nachteile und Einschränkungen universell verwendet werden sollte. In dieser Phase genügt es zu sagen „Ich wende Methode X an“, ohne zu analysieren, ob X ein Nettonutzen ist.
• Es kommt aus der Mode, aber seine nützlichsten Ideen bleiben als Teil des Softwareentwicklungs-Toolkits erhalten, um herausgezogen und verwendet zu werden, wann immer sie Nettovorteile bringen.

Meiner Meinung nach bewegen sich sowohl TDD als auch Entwurfsmuster um die Trennung zwischen der zweiten und dritten Phase im Lebenszyklus der Programmiermethodik. Ich bin mir sicher, dass TDD und viele Designmuster ein langes und wertvolles Leben im Toolkit haben werden, um immer dann eingesetzt zu werden, wenn sie mehr helfen als schaden. Ich denke auch, dass sie immer noch überbeansprucht werden, eher aus Gewohnheit als aus absichtlichem Denken.

Sie sollten niemals ein Designmuster anwenden, da es Ihnen zur zweiten Natur geworden ist oder Sie Schwierigkeiten haben, Ihre Verwendung zu erklären. Denken Sie stattdessen vor der Anwendung eines Entwurfsmusters über dessen Kosten und Nutzen in dieser speziellen Situation nach. Wenn die Vorteile die Kosten wirklich überwiegen, sollten Sie genau wissen, warum, also sollte es Sie nicht ermüden, den Kompromiss zu erklären. Wenn die Vorteile die Kosten nicht überwiegen, verwenden Sie es nicht. Auch hier sollten Ihre eigenen Überlegungen zu Ihrem Design Sie darauf vorbereiten, zu antworten, wenn Sie gefragt werden, warum Sie kein möglicherweise anwendbares Designmuster verwendet haben.

Denken Sie daran, dass Sie über diese Kompromisse im Hinblick auf die allgemeine Wartbarkeit des Programms nachdenken müssen, und nicht nur, um Ihr Stück schnell zum Laufen zu bringen. Zu viele Indirektionen können es zukünftigen Programmierern erschweren, herauszufinden, was wirklich vor sich geht.

Bin ich die einzige Person, die darüber verblüfft ist, dass wir in Workplace sehen, dass wir uns so sehr auf Programmierpraktiken konzentrieren und nicht auf den tatsächlichen Konflikt am Arbeitsplatz? Also werde ich einen anderen Ansatz wählen.

Hier sind die allgemeinen Aspekte Ihres Problems, wie ich es sehe:

1. Sie befinden sich in einem Fachgebiet, das Zusammenarbeit erfordert
2. Es gibt keine dokumentierten Verfahren, die regeln, wie diese Zusammenarbeit durchgeführt werden sollte
3. Es herrscht Uneinigkeit darüber, wie diese Zusammenarbeit erfolgen soll
4. Einer von denen, die anderer Meinung sind, ist Ihr Vorgesetzter

Für mich klingt es so, als müsste Ihre Gruppe zusammenkommen und sich darauf einigen, welche Standards und Praktiken Sie übernehmen werden, und sie global übernehmen, zum Guten oder zum Schlechten. Denn nichts ist schlimmer für ein Produkt als ein Team, das ständig zerstritten ist, und nichts ist schlimmer für Ihre Beziehung zu Ihrem Arbeitgeber, als ständig Streit mit ihm aufzuwärmen .

Versuchen Sie also, Ihr Team zusammenzubringen, um sich auf einige Standards zu einigen, und nutzen Sie dieses Treffen, um Ihre Argumente für die von Ihnen verwendeten Praktiken zu vertreten. Wenn du sie bekommst, großartig! Wenn nicht, dann sei es so. Ihre Aufgabe ist es nicht, schönen Code zu schreiben. Ihre Aufgabe ist es, ein fertiges Produkt zu liefern. Wenn Ihr Arbeitgeber (verkörpert durch Ihren Vorgesetzten) und eine Vielzahl Ihrer Gruppe darauf besteht, dass Sie es auf eine bestimmte Weise tun, wer sind Sie dann, um ihnen zu widersprechen?

Es hört sich jedoch so an, als würde der Großteil Ihres Teams Ihnen zustimmen, also sollte es während dieser Diskussionen ziemlich offensichtlich werden, dass Ihr Vorgesetzter der Außenseiter ist. Wenn sich diese Person immer noch weigert, zum Teamkonsens zu wechseln, dann ist das eine Funktionsstörung, bei deren Lösung wir Ihnen nicht helfen können (außer Ihnen zu empfehlen, zu einem anderen Team zu wechseln).

Leider ist er Ihr Manager, und Sie schreiben Code nicht so, wie er es möchte. Wenn er im Management ist, plant er vielleicht nicht, in 2-3 Jahren aus dem Unternehmen auszuscheiden, wie es die meisten Entwickler planen. Sie schreiben Code, der für Ihre Nachfolger schwieriger zu reparieren sein wird, weshalb er hart zu Ihnen ist, wenn Sie ihn so erstellen.

Wenn ich hier eine Vermutung anstellen darf, wohl wissend, dass ich weit daneben liegen könnte, wofür schreibst du dieses Zeug? Ich wäre eher überrascht, wenn es um mehr als LOB-Anwendungen geht. Entwurfsmuster verkomplizieren wahrscheinlich Code für eine LOB-Anwendung, die nicht besonders kompliziert sein muss, viel zu sehr.

In meinen 10 Jahren der Entwicklung wurde ein echtes Strategie-/Factory-Pattern nur dreimal benötigt, von denen zwei aus Jobs stammen:

• In einer Anwendung, in der Produktinformationen angezeigt wurden, bei denen einige dieser Produkte im Wesentlichen eine Reihe kleinerer Produkte in einer Schachtel waren, haben wir eine Strategie verwendet, um zu bestimmen, welche Fabrik benötigt wird, um die Produktinformationen (die über einen Schlüssel angefordert werden) in eine Ansicht umzuwandeln. Nicht sehr glorreich, aber es hat seinen Zweck erfüllt. Wenn ich mich Ihrer bescheidenen Prahlerei über Fehler anschließen darf, hatten wir in meiner gesamten Amtszeit dort nie einen einzigen Fehler! (Einer wurde gemeldet, nachdem ich gegangen war, stellte sich aber als Benutzerfehler heraus :)).
• In einer Anwendung, die Benutzern zeigte, wohin sie für einen Kurs gehen sollten, an dem sie teilnahmen, verwendeten wir eine Fabrik und eine Abstraktion, um einen schnellen Wechsel zwischen einer Bing Maps-API und einer Google Maps-API zu ermöglichen. Dies lag daran, dass beide ein Kosten-Nutzen-Verhältnis hatten und das Unternehmen keine Fortschritte bei der Entscheidung machte, welches verwendet werden sollte. Schließlich hörten wir von unserem Home Office, dass wir bereits einen API-Schlüssel für einen von ihnen hatten und in letzter Sekunde direkt vor dem Start zu dieser API wechseln konnten.

Und ein drittes ist ein Projekt, mit dem ich herumspiele, das die Serverüberwachung für Windows-Server durchführt:

• Ich verwende eine Schnittstelle für die Ausgabe der Überwachungsdaten und für die Monitore selbst. Die Monitore sind in hohem Maße konfigurierbar (basierend auf den Anwendungseinstellungen). Die Ausgabeimplementierung variiert je nachdem, ob ich einen neuen Monitor teste oder zur Bereitstellung übergehe, sodass IOutputInterface ConsoleOutput und SqlOutput als Implementierungen hat, die variieren können.

Beachten Sie, dass mein persönliches Projekt Muster und Inversion of Control (IoC) sofort häufiger verwendet als meine Arbeitsprojekte.

Wenn ich dir nach all dem einen Rat geben kann, dann lass es sein: Job ist Job, und wenn du die Dinge auf deine Art machen willst, dann versuche, einen goldenen Mittelweg zu finden. Tech-Leute bleiben im Allgemeinen nicht lange an einem Ort und es lohnt sich nicht, sich mit dem Management darüber zu streiten, wie es gemacht wird. Lassen Sie Ihre persönlichen Heimprojekte zu einem Musterstapel werden, so viel Sie wollen.

Einfache Lösung: beenden .

Schwierige Lösung: Bei jeder Meinungsverschiedenheit liegt die halbe Schuld bei Ihnen .

Nehmen Sie sich eine Auszeit, studieren Sie, wie andere Teams arbeiten, finden Sie heraus, wo die Impedanz-Fehlanpassung zwischen Ihnen und der anderen Partei liegt. Sprechen Sie mit ihnen persönlich, früh und oft. Wenn Sie dies gut machen, werden Sie beide lernen, die Bedenken und Referenzen der anderen Partei zu verstehen, und sie werden lernen, Sie für Ihren Beitrag, Ihre Erfahrung und Ihre entschiedene Meinung zu schätzen. Hier sind einige Bereiche, die Sie berücksichtigen sollten:

• Qualitätsprodukt vs. Time-to-Market
• gutes Produkt vs. guter Code
• Smart Code vs. selbsterklärender Code
• Top-down-Unternehmenskultur vs. Bottom-up-Engineering-Kultur

Wenn es nicht gut funktioniert, ziehen Sie eine andere Rolle im Team, ein anderes Team im Unternehmen oder schließlich ein anderes Unternehmen in Betracht .

Wenn Sie sich diesen Leuten direkt stellen, werden Sie auf den größten Widerstand stoßen, Heuschrecke. Ich war am effektivsten darin, Veränderungen herbeizuführen, wenn ich strategisch die richtigen Druckpunkte getroffen habe. Es erfordert viel Geduld und viel Hingabe. Ich muss mich erst darauf einstellen, bevor ich an den Schwachstellen Druck ausübe.

Leere deinen Geist, sei formlos. Formlos, wie Wasser. Wenn du Wasser in eine Tasse füllst, wird es zur Tasse. ... Jetzt kann Wasser fließen oder es kann abstürzen. - Bruce Lee

Hören Sie ihnen zu und stellen Sie viele Fragen. Jemandem wirklich zuzuhören, nimmt ihm den Wunsch, sich zu widersetzen. Verstehen Sie, was ihr Denken motiviert, und sprechen Sie dann ihre Sprache. Da Ihre Überzeugungen im Moment axial sind, spiegelt er wahrscheinlich Ihre Sturheit, Verachtung und Frustration wider. Da Sie untergeordnet sind, ist es seine Entscheidung, sich nicht Ihrer Wellenlänge anzuschließen, und es liegt an Ihnen, die Brücke zu bauen.

Wenn du ihn siehst, wirst du dich selbst sehen. Wenn Sie ihn behandeln, behandeln Sie sich selbst. Wenn du an ihn denkst, wirst du an dich selbst denken. Vergiss das nie, denn in ihm wirst du dich finden oder verlieren. -Helen Schumann

Ein Meister des Wing Chun Kung Fu zieht seinen Gegner heran und schließt die Distanz, bevor er die Mittellinie sucht und angreift, wo er am verwundbarsten ist. Streiten Sie nicht um Kleinigkeiten, nur um zu gewinnen, finden Sie die Mittellinie des größeren Problems und konzentrieren Sie sich dort auf den Druck.

Ich habe täglich mit Ingenieuren zu tun, die sich weigern, umzurüsten oder neue Programmierparadigmen zu lernen, und mir wurde öfter als ich zählen kann, irgendeine Art von „Ich bin hier, seit es Lochkarten gibt“-Argumente gegeben. Ich schätze, ich habe 80 % der Kämpfe verloren, aber diese 20 % … woh … ich habe große Veränderungen bewirkt. Ich mag vage klingen, aber wenn Sie einige dieser Schlüsselwörter bei Google recherchieren, werden Sie verstehen, was ich meine.

Versuchen Sie auch, an einem neuen Eichhörnchenprojekt teilzunehmen , bei dem Sie es auf Ihre Weise tun können. Wenn es wirklich funktioniert und Zeit oder Geld spart, werden sich die Leute Ihrer Denkweise anschließen. Wenn es kein neues Projekt gibt, erstellen Sie eines in Ihrer Freizeit, um einen Schwachpunkt des Unternehmens zu lösen, und niemand ist daran interessiert, sich die Zeit für die Lösung zu nehmen.

Was soll ich machen?

Wie gut Code geschrieben (oder überschrieben) wird, unterliegt in der Softwareentwicklung immer einem gewissen Maß an Interpretation (Meinung). Für mich unternehmen Sie die Schritte, die ich an Ihrer Position tun würde, aber letztendlich ist Ihr Manager derjenige, der das Licht sehen muss .... zeigen Sie es ihm weiterhin.

Ich würde weiterhin, so schmerzhaft es auch sein mag , genau das tun, was Sie tun, und darauf hinweisen, wie sich die Investition in die Verwendung des Designmusters auszahlt, wo immer Sie können, ohne Ihren Manager schlecht dastehen zu lassen .

Ändere nicht, was du tust, es sei denn , du fühlst dich in Gefahr von Schlimmerem als einem Verweis. Zeigen Sie ihnen weiterhin die Vorteile der Verwendung des Musters, und schließlich sollten sie vorbeikommen.

Versuchen Sie, während Sie den Kampf fortsetzen, einige andere Verbündete im Team zu gewinnen. Auf diese Weise sind Sie nicht die einzige Stimme, die sich für das Muster ausspricht.

Wenn sie sich jedoch weigern, haben Sie irgendwann die Wahl, ob diese Umgebung für Sie geeignet ist. Ich glaube, Sie sind noch nicht so weit, aber Sie müssen möglicherweise zu einer Umgebung wechseln, die für gute Programmierpraktiken akzeptabler ist.

Denken Sie daran, dass dieser Kampf, in dem Sie sich befinden, ein Marathon ist . Wenn Sie die Codierungskultur ändern möchten, liegt es an Ihnen, den Wert des Musters zu demonstrieren.

Erstens können wir anhand der gegebenen Informationen nicht sagen, wer Recht hat. Wenn ich hinzugezogen würde, um das Projekt zu prüfen, hätte ich möglicherweise immer noch Schwierigkeiten zu entscheiden, wer Recht hat, weil Sie möglicherweise mit anderen Zielen entwerfen. Aber ich vermute, dass der Chef die Ziele besser kennt als Sie.

Zweitens Ihre Frage: "Wie kann ich meinen Chef überzeugen?" Die Antwort ist, Sie können wahrscheinlich nicht. Am Ende ist er der Boss. Das einzige Mal, dass ich meinen Chef überredete, seine Ansichten zum Software-Engineering zu ändern, war, nachdem wir ein Jahr damit verbracht hatten, ein unzuverlässiges Stück Software zu patchen, das so geschrieben war, wie er es wollte, und wir ihm sagten, dass wir es nur durch Design zuverlässig machen könnten anders.

Aus technischer Sicht wissen wir nicht, wer hier richtig ist – es könnte ein Manager sein, der tief in der Vergangenheit steckt, oder ein neuer Entwickler, der blind an den ganzen Hype glaubt.

Aber er ist Ihr Manager, und Sie beschäftigen sich nicht mit dem Manager, sondern mit seiner Weigerung, das zu tun, was Sie für das Beste halten, und bestehen darauf, das zu tun, was er für das Beste hält. Und das ist der Normalzustand, dass Ihr Vorgesetzter die Entscheidung trifft. Es ist auch der Normalzustand, dass letztendlich er für Erfolg oder Misserfolg verantwortlich ist und nicht Sie. Er hat die Autorität. Und er hat recht, man sollte seine Autorität nicht in Frage stellen. Sie können in Frage stellen, ob er Recht hat, aber nicht seine Autorität. Also kümmerst du dich entweder darum oder wechselst zu einem Unternehmen, das die Dinge auf deine Art macht.

Anstatt zu denken, dass die Dinge nicht so laufen, wie Sie es möchten, denken Sie in der Zwischenzeit darüber nach, wie Sie innerhalb Ihrer Grenzen den qualitativ hochwertigsten Code produzieren. Vieles lässt sich auf unterschiedliche Weise erledigen. Es gibt „einfach, schlecht gestaltet“ und „einfach, gut gestaltet“. Entscheiden Sie sich für Letzteres.

Die Erfahrung erlaubt es zu beurteilen, ob die Vorteile aus dem Entwurfsmuster in der Zukunft möglich und wahrscheinlich sind. Wenn der Vorgesetzte das Muster kennt und es trotzdem ablehnt, erkennt er wahrscheinlich den Fall, wenn sich die Anwendung dieses oder eines ähnlichen Musters nicht auszahlt. Manchmal widersprechen Erfahrungen den Regeln oder eher Interpretationen.

Es gibt eine bekannte Meinung, dass kürzerer und einfacherer Code leichter zu verstehen und offener für signifikante Änderungen ist.

Im Grunde versuchen Sie, eine weitere Ebene der Indirektion zu haben, und noch eine und so weiter. Es verkompliziert die Dinge.

Lösen diese Schichten tatsächlich ein Problem? Das Hinzufügen von Funktionen in Zukunft einfacher zu machen, löst kein Problem. Der Kunde ist nicht bereit, dafür zu zahlen. Daher ist es kein Problem, das Unternehmen lösen müssen. Für Unternehmen besteht das Problem nicht.

Außerdem geht das nicht. Es ist nicht abzusehen, welche besondere Funktion der Kunde in Zukunft wünschen könnte. Wenn Sie ein Produkt auf eine besondere Weise entwerfen, erschweren Sie es, bestimmte Funktionen hinzuzufügen. Es ist besser, das Design offen zu halten.

Sie tätigen also nicht nur eine nicht autorisierte Investition im Namen Ihres Unternehmens, sondern haben auch keine Ahnung von dem damit verbundenen Risikofaktor.

Komplizierte Dinge brauchen mehr Zeit, um erledigt und gewartet zu werden. Zeit ist Geld.

Komplizierte Dinge begrenzen, wie viel und welche Art von anderen Dingen im System hinzugefügt werden können. Wenn man einmal auf den Weg geht, Dinge kompliziert zu machen, dann muss man auch andere bestehende und neue Dinge kompliziert machen, selbst wenn sie selbst nicht kompliziert sein müssen.

Darin liegt eine letzte Botschaft. Es heißt, dass die Zahl zwei in der Informatik nicht existiert. Wenn ein Ding zwei Variationen hat, fügen Sie keine weitere Indirektionsebene hinzu. Sie lassen die beiden Varianten einfach bestehen. So ist es einfacher. Wenn Sie nicht drei oder mehr Variationen haben, ist die Gemeinsamkeit nicht klar, also abstrahieren Sie sie nicht. Sie wissen nicht, was Sie extrahieren sollen, Sie gehen Risiken ein und machen Wunschdenken.

Ich würde Pair Programming und Peer Review vorschlagen. Dies wird Ihren Kollegen helfen, Ihren Code besser zu verstehen, da Sie erklären müssen, warum und wie Sie es tun, anstatt nachträglich.

Entweder werden sie von Ihnen lernen und sehen, warum es klug ist, oder Sie werden lernen, dass die besten Programmierer Code schreiben, den andere pflegen können.