Hat es je geholfen, es auf Ihre Art zu tun? Gab es auch nur einmal eine Zeit, in der Sie Indirektion und Injektion und zusätzliche Schnittstellen verwendet haben und es in letzter Minute zu einem Ausweichmanöver kam und alles reibungslos und schön ohne Fluchen abgewickelt wurde? Sogar bei einem früheren Job, wenn es Ihnen nie gelungen ist, diesen Code hier einzuspielen?

Ich nehme an, dass es so war. Üben Sie sich darin, diese Geschichte zu erzählen. Sie ist spezifisch und real. Es geht nicht um “x könnte passieren” oder “y könnte sich ändern”, sondern um “Es war einmal, da habe ich es so gemacht, und so hat es funktioniert”. Manager (ich spreche als einer) sind misstrauisch, wenn es darum geht, Geld auszugeben (und glauben Sie mir, wenn Sie einen komplizierteren Code schreiben, den andere beim ersten Durchgang nicht verstehen, ist das Ausgaben von Geld) für das, was möglicherweise passieren könnte. Sie wollen keine Spekulationen finanzieren, die nur auf dem “Lernen aus Büchern” und der neuesten Modeerscheinung des Internets basieren könnten. Aber wenn Sie auf Ihre Erfahrungen zurückgreifen? Das ist eine ganz andere Situation.

Ich bin kein großer Fan von Fabriken, Providern, Injektoren und was weiß ich nicht alles. Sie sind in der Regel für Dinge eingerichtet, die nie wirklich passieren werden (Wechsel von MS SQL zu Oracle) oder wenn sie doch passieren (Änderung des Ordners, in dem die Dateien gespeichert werden), einen kleinen Einfluss haben. Sie haben ihren Platz in Arrangements, die sehr unbeständig sind und in denen Sie sich scheinbar befinden. Sie müssen also zeigen, dass sie diesen Platz haben. Sie scheinen aus der Position zu kommen: “Das ist die normale Art, Dinge zu tun, und ich brauche einen Grund, es nicht zu tun. Ihr Vorgesetzter kommt von: "Das ist nicht normal; normal ist einfach und unkompliziert. Nennen Sie mir einen guten Grund, eine weitere Schicht in den Weg zu legen. Arbeiten Sie an diesem Grund. Arbeiten Sie an einer Erfolgsgeschichte aus der Vergangenheit, in der diese zusätzliche Schicht Tage oder Wochen Arbeit gespart hat. Rechtfertigen Sie Ihre Ingenieurskunst, sonst ist es wirklich Over-Engineering.

Dieses Zitat aus einem Ihrer Kommentare beunruhigt mich:

Als Software-Ingenieur ist es für mich zur zweiten Natur geworden, ‘zu tun, was vielleicht keinen guten Grund an der Oberfläche hat’, so wie die von mir erwähnten Unbekannten miteinander zu verbinden. Ständig am Rande stehen zu müssen, um mich über zutiefst technische (und manchmal stark meinungsbildende) Themen zu erklären, zehrt an mir.

Ich habe mehrere Wiederholungen des folgenden Lebenszyklus erlebt:

• Ein erfahrenes Programmiererteam kommt mit einem anderen Ansatz zur Programmierung.
• Es wird für ein paar Jahre, bis zu einem Jahrzehnt, als etwas angesehen, das trotz aller Nachteile und Einschränkungen universell eingesetzt werden sollte. In dieser Phase reicht es aus, zu sagen: “Ich wende die Methodik X an”, ohne zu analysieren, ob X ein Nettovorteil ist.
• Sie kommt aus der Mode, aber ihre nützlichsten Ideen bleiben als Teil des Softwareentwicklungs-Toolkits erhalten, um herausgezogen und verwendet zu werden, wann immer sie Nettovorteile bringen.

Meiner Meinung nach schweben sowohl die TDD als auch die Entwurfsmuster um den Spagat zwischen der zweiten und dritten Phase im Lebenszyklus der Programmiermethodik herum. Ich bin sicher, dass die TDD und viele Entwurfsmuster eine lange und wertvolle Lebensdauer im Toolkit haben werden, um immer dann eingesetzt zu werden, wenn sie mehr helfen als schaden. Ich bin auch der Meinung, dass sie vielleicht immer noch zu oft verwendet werden, eher aus Gewohnheit als durch absichtliches Nachdenken.

Sie sollten nie ein Entwurfsmuster anwenden, weil es Ihnen in Fleisch und Blut übergegangen ist oder Sie Schwierigkeiten haben, Ihre Verwendung zu erklären. Denken Sie stattdessen vor der Anwendung eines Geschmacksmusters über dessen Kosten und Nutzen in dieser besonderen Situation nach. Wenn der Nutzen die Kosten wirklich aufwiegt, sollten Sie genau wissen, warum, so dass die Erklärung des Kompromisses Sie nicht überfordern sollte. Wenn sein Nutzen die Kosten nicht aufwiegt, sollten Sie es nicht verwenden. Auch hier sollten Ihre eigenen Überlegungen zu Ihrem Entwurf Sie darauf vorbereiten, zu antworten, wenn Sie gefragt werden, warum Sie ein möglicherweise anwendbares Entwurfsmuster nicht verwendet haben.

Denken Sie daran, dass Sie über diese Kompromisse im Hinblick auf die allgemeine Wartbarkeit des Programms nachdenken müssen und nicht nur darüber, wie Sie Ihr Stück schnell zum Laufen bekommen. Zu viel Indirektion kann es für zukünftige Programmierer schwieriger machen, herauszufinden, was wirklich vor sich geht.

Bin ich die einzige Person, die sich darüber wundert, dass am Arbeitsplatz so viel Wert auf Kodierungspraktiken gelegt wird und nicht auf den eigentlichen Konflikt am Arbeitsplatz? Deshalb werde ich einen anderen Ansatz wählen.

Hier sind die verallgemeinerten 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 erfolgen soll

3. Es besteht Uneinigkeit darüber, wie diese gemeinsame Arbeit durchgeführt werden sollte

4. Einer von denen, die anderer Meinung sind, ist Ihr Vorgesetzter

Es klingt für mich so, als müsse sich Ihre Gruppe zusammensetzen und sich darauf einigen, welche Standards und Praktiken Sie übernehmen werden, und diese weltweit übernehmen, im Guten wie im Schlechten. Denn nichts ist schlimmer für ein Produkt als ein Team, das ständig im Streit liegt, und nichts ist schlimmer für Ihre Beziehung zu Ihrem Arbeitgeber als ein ständiges Wiederaufwärmen von Argumenten mit ihm.

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

Es klingt jedoch so, als ob der größte Teil Ihres Teams mit Ihnen übereinstimmt, so dass es während dieser Diskussionen ziemlich offensichtlich werden sollte, dass Ihr Vorgesetzter der Ausgefallene ist. Wenn diese Person sich immer noch weigert, zum Teamkonsens zu wechseln, dann ist das eine Dysfunktion, bei deren Lösung wir Ihnen nicht helfen können (außer Ihnen zu empfehlen, in ein anderes Team zu wechseln).

Leider ist er Ihr Manager, und Sie schreiben den Code nicht so, wie er es möchte. Wenn er Manager ist, plant er vielleicht nicht, in 2-3 Jahren aus der Firma auszuscheiden, wie es die meisten Entwickler planen. Sie schreiben Code, der für Ihre Nachfolger schwieriger zu reparieren sein wird, weshalb er es Ihnen schwer macht, ihn auf diese Weise zu bauen.

Wenn ich hier eine Vermutung äußern darf, wohl wissend, dass ich weit vom Ziel entfernt sein könnte, wofür schreiben Sie dann dieses Zeug? Ich wäre ziemlich überrascht, wenn es um mehr als BVG-Bewerbungen geht. Designmuster komplizieren wahrscheinlich viel zu viel Code für eine LOB-Anwendung, die nicht besonders kompliziert sein muss.

In den 10 Jahren meiner Entwicklung wurde ein echtes Strategie-/Fabrikmuster nur dreimal benötigt, davon zwei Mal von Jobs:

• In einer Anwendung, die Produktinformationen anzeigte, wobei einige dieser Produkte im Wesentlichen ein Haufen kleinerer Produkte in einer Schachtel waren, verwendeten wir eine Strategie, um zu bestimmen, welche Fabrik benötigt wurde, um die Produktinformationen (die über einen Schlüssel angefordert wurden) in eine Ansicht umzuwandeln. Nicht sehr glorreich, aber es hat seine Aufgabe erfüllt. Wenn ich mit Ihrer bescheidenen Prahlerei über Bugs mithalten darf: In meiner gesamten Amtszeit dort hatten wir nie einen einzigen Bug! (einer wurde gemeldet, nachdem ich gegangen war, stellte sich aber als Benutzerfehler heraus :)).
• In einer Anwendung, die Benutzern zeigte, wo sie für einen Kurs, an dem sie teilnahmen, hingehen sollten, verwendeten wir eine Factory und eine Abstraktion, um einen schnellen Wechsel zwischen einer Bing-Maps-API und einer Google-Maps-API zu ermöglichen. Der Grund dafür war, dass beide ein Kosten/Nutzen-Verhältnis hatten und das Unternehmen bei der Entscheidung, welche zu verwenden war, keine Fortschritte machte. Schließlich erfuhren wir von unserem Heimbüro, dass wir bereits einen API-Schlüssel für eines der beiden Programme hatten und in der Lage waren, in letzter Sekunde, kurz vor dem Start, zu diesem API zu wechseln.

Und ein drittes ist ein Projekt, mit dem ich mich herumschlage und das die Serverüberwachung für Windows-Server übernimmt:

• 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 Anwendungseinstellungen). Die Ausgabe-Implementierung variiert, je nachdem, ob ich einen neuen Monitor teste oder zum Einsatz komme, so dass IOutputInterface ConsoleOutput und SqlOutput als Implementierungen hat, die variieren können.

Beachten Sie, dass mein persönliches Projekt sofort häufiger Muster und Umkehrung der Kontrolle (IoC) verwendet als meine Arbeitsprojekte.

Wenn ich Ihnen nach all dem einen Rat geben kann, lassen Sie es so sein: Ein Job ist ein Job, und wenn Sie die Dinge auf Ihre Weise machen wollen, dann versuchen Sie, einen goldenen Mittelweg zu finden. Tech-Leute bleiben in der Regel nicht lange an einem Ort, und es ist es nicht der Mühe wert, sich mit dem Management darüber zu streiten, wie es gemacht wird. Lassen Sie Ihre persönlichen Heimprojekte ein Musterstapel sein, so viel Sie wollen.

Einfache Lösung: **

Schwere Lösung: Bei jeder Meinungsverschiedenheit liegt die Hälfte der Schuld bei Ihnen.

Nehmen Sie sich eine Auszeit, studieren Sie, wie andere Teams arbeiten, finden Sie heraus, wo die Impedanzabweichung zwischen Ihnen und der anderen Partei liegt. Sprechen Sie mit ihnen persönlich, früh und oft. Wenn Sie das gut machen, werden Sie beide lernen, die Anliegen und Referenzen der anderen Partei zu verstehen, und sie werden lernen, Sie für Ihren Input, Ihre Erfahrung und Ihre entschlossenen Meinungen zu schätzen. Hier einige Bereiche, die es zu berücksichtigen gilt:

• Qualitätsprodukt vs. Zeit bis zur Markteinführung
• gutes Produkt vs. guter Code
• intelligenter Code vs. selbsterklärender Code
• Top-down-Unternehmenskultur vs. Bottom-up-Engineering-Kultur

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

Wenn Sie diesen Menschen frontal gegenüberstehen, werden Sie auf den größten Widerstand stoßen, Grashüpfer. Ich habe Veränderungen am effektivsten herbeigeführt, wenn ich strategisch die richtigen Druckpunkte getroffen habe. Das erfordert viel Geduld und viel Nachgeben. Ich muss mich erst an sie anpassen, bevor ich an den Schwachstellen Druck ausübe.

Leere deinen Geist, sei formlos. Formlos, wie Wasser. Wenn Sie Wasser in einen Becher geben, wird es zum Becher. … Nun kann Wasser fließen oder es kann abstürzen. - Bruce Lee

Hören Sie ihnen zu und stellen Sie eine Menge Fragen. **Wenn man jemandem zuhört, nimmt ihm das Verlangen zu widerstehen. Verstehen Sie, was ihr Denken motiviert, dann sprechen Sie ihre Sprache. Da Ihre Überzeugungen im Moment axial sind, spiegelt er wahrscheinlich Ihre Sturheit, Verachtung und Frustration wider. Da Sie ihm untergeordnet sind, ist es seine Entscheidung, sich nicht Ihrer Wellenlänge anzuschließen, und es liegt an Ihnen, die Brücke zu bauen.

Wie Sie ihn sehen, werden Sie sich selbst sehen. Wenn Sie ihn behandeln, werden Sie sich selbst behandeln. Wenn Ihr an ihn denkt, werdet Ihr an Euch selbst denken. Vergessen Sie das nie, denn in ihm werden Sie sich selbst finden oder verlieren. - Helen Schucman

Ein Wing Chun Kung Fu-Meister wird seinen Gegner einziehen und die Distanz verringern, bevor er die Mittellinie sucht und angreift, wo er am verwundbarsten ist. Streiten Sie sich nicht über Kleinigkeiten, nur um zu gewinnen, sondern finden Sie die Mittellinie des größeren Problems und konzentrieren Sie den Druck dort.

Ich habe täglich mit Ingenieuren zu tun, die sich weigern, umzurüsten oder neue Programmierparadigmen zu erlernen, und ich habe schon öfter als ich zählen kann, irgendeine Form von “Ich bin seit Lochkarten hier” Argument erhalten. Ich schätze, dass ich 80% der Schlachten verloren habe, aber diese 20%…woh…ich habe große Veränderungen bewirkt. Ich mag vielleicht vage klingen, aber machen Sie ein paar Google-Recherchen zu einigen dieser Schlüsselwörter, und Sie werden sehen, was ich meine.

Versuchen Sie auch, ein neues Eichhörnchen-Projekt anzugehen, damit Sie es auf Ihre Weise machen können. Wenn es wirklich funktioniert und Zeit oder Geld spart, werden sich die Leute auf Ihre Denkweise einstellen. Wenn es kein neues Projekt gibt, kreieren Sie in Ihrer Freizeit eines, um einen Schmerzpunkt zu lösen, den das Unternehmen hat, und niemand ist daran interessiert, sich die Zeit für die Lösung zu nehmen.

Was soll ich tun?

In der Softwaretechnik unterliegt die Frage, wie gut Code geschrieben (oder übergeschrieben) ist, immer einem gewissen Grad der Interpretation (Meinung). Für mich machen Sie die Schritte, die ich in Ihrer Position machen würde, aber letztendlich ist Ihr Vorgesetzter derjenige, der das Licht sehen muß….es ihm immer wieder zeigen muß…

Ich würde weiterhin, so schmerzhaft es auch sein mag, genau das tun, was Sie tun, und aufzeigen, wie sich die Investition in die Verwendung des Entwurfsmusters auszahlt wo Sie können, ohne Ihren Vorgesetzten schlecht aussehen zu lassen.

Ändern Sie nicht, was Sie tun es sei denn Sie fühlen sich in Gefahr, schlimmer als ein Verweis zu bekommen. Zeigen Sie ihnen immer wieder die Vorteile der Verwendung des Musters, und schließlich sollten sie sich damit abfinden.

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

Irgendwann jedoch, wenn sie Ihnen die Wahl verweigern, haben Sie die Wahl, ob dieses Umfeld das richtige für Sie ist. Ich glaube nicht, dass Sie noch nicht so weit sind, aber vielleicht müssen Sie zu einer Umgebung übergehen, die für gute Kodierungspraktiken akzeptabler ist.

Denken Sie daran, dieser Kampf, in dem Sie sich befinden, ist ein Marathon. Wenn Sie die Kodierungskultur ändern wollen, wird es an Ihnen liegen, den Wert des Musters zu demonstrieren.

Erstens können wir aus den gegebenen Informationen nicht erkennen, wer Recht hat. Tatsächlich könnte ich, wenn ich zur Prüfung des Projekts herangezogen würde, immer noch Schwierigkeiten haben zu entscheiden, wer der Richtige ist, weil Sie vielleicht mit anderen Zielen vor Augen entwerfen. Aber meine Vermutung wäre, dass der Chef die Ziele besser kennt als Sie.

Zweitens, Ihre Frage: “Wie kann ich meinen Chef überreden?” Die Antwort ist, dass Sie das wahrscheinlich nicht können. Am Ende ist er der Chef. Das einzige Mal, als ich meinen Chef dazu überredete, seine Vorstellungen über 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 nicht zuverlässig machen können, außer es anders zu entwerfen.

Wir wissen nicht, wer aus technischer Sicht hier richtig ist - es könnte ein Manager sein, der tief in der Vergangenheit feststeckt, oder ein neuer Entwickler, der blind an den ganzen Hype glaubt.

Aber er ist Ihr Manager, und Sie haben es nicht mit dem Manager zu tun, sondern mit seiner Weigerung, das zu tun, was Sie für das Beste halten, und darauf zu bestehen, das zu tun, was er für das Beste hält. Und das ist der normale Zustand der Dinge, daß Ihr Manager die Entscheidung trifft. Es ist auch der Normalzustand, dass er letztlich die Verantwortung für Erfolg oder Misserfolg trägt und nicht Sie. Er hat die Autorität. Und er hat Recht, Sie sollten seine Autorität nicht in Frage stellen. Sie können in Frage stellen, ob er Recht hat, aber nicht seine Autorität. Also setzen Sie sich entweder damit auseinander oder wechseln Sie zu einem Unternehmen, das die Dinge auf Ihre Art und Weise erledigt.

In der Zwischenzeit denken Sie nicht darüber nach, dass die Dinge nicht so laufen, wie Sie es sich wünschen, sondern überlegen Sie, wie Sie den qualitativ hochwertigsten Code produzieren können, den Sie innerhalb Ihrer Grenzen produzieren können. Viele Dinge können auf unterschiedliche Weise erledigt werden. Es gibt “geradlinig, schlecht entworfen” und “geradlinig, gut entworfen”. Entscheiden Sie sich für Letzteres.

Die Erfahrung erlaubt es zu beurteilen, ob der Nutzen aus dem Entwurfsmuster möglich und in der Zukunft wahrscheinlich ist. Wenn der Vorgesetzte das Muster kennt und es dennoch ablehnt, erkennt er wahrscheinlich den Fall, wenn sich die Anwendung dieses oder eines ähnlichen Musters nicht auszahlt. Manchmal widerspricht die Erfahrung den Regeln oder eher deren Auslegung.

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

Ich würde eine paarweise Programmierung und Peer-Review vorschlagen. Das wird Ihren Mitarbeitern helfen, Ihren Code besser zu verstehen, da Sie warum und wie erklären müssen, wie Sie es tun, und nicht im Nachhinein.

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