Wie kann ein Junior einen Senior-Entwickler davon überzeugen, objektorientierte Konzepte zu verwenden? [Duplikat]

Dieses Thema bezieht sich auf Webentwicklung / Softwareentwicklung; Die Frage kann sich jedoch auf andere Fachgebiete beziehen, in denen ein jüngerer Mitarbeiter technisch versierter ist als ein Senior mit mehr Erfahrung.

Ich arbeite in einem Team, in dem das absolute Ausmaß der verwendeten objektorientierten Programmierung Vererbung ist . Prozeduraler Code wird in Klassenmethoden platziert. Es gibt wenig bis gar kein Typehinting in Methodensignaturen, keine Namespaces oder Schnittstellen - (ich weiß, richtig)? - Dies hat zu Legacy-Code geführt, der schwer zu pflegen und für neue Mitarbeiter (Junioren) sehr schwer zu erlernen und zu bearbeiten ist. Nur die Person, die es geschrieben hat, weiß wirklich, wie es funktioniert.

In einem technischen Meeting zu einem neuen Projekt gehe ich davon aus, dass jede Diskussion über gute OO-Praktiken (Entwurfsmuster usw.) höchstwahrscheinlich mit „es ist zu komplex“ beantwortet wird. Zu komplex mit 5 Klassen oder mehr.

Ich bin höflich, ruhig, respektvoll und ehrlich, genau wie der leitende Entwickler – er ist ein Freund. Infolgedessen glaubt er ehrlich, dass alles, was über die Vererbung hinausgeht, beim Programmieren "zu komplex" ist, und ich glaube ehrlich, dass das nicht der Fall ist - ich habe in der Vergangenheit Code geschrieben, der "einfach funktioniert", da er von mir vollständig getestet wurde und einwandfrei funktionierte Veröffentlichungstag, und der Code des Seniors erforderte einige Korrekturen.

Wie kann ich eine gute objektorientierte Lösung vorschlagen, die architektonisch solide und in diesem Meeting „sinnvoll“ ist, aber das Problem „es ist zu kompliziert“ vermeiden (wenn es wirklich nicht so ist, ist er nur daran gewöhnt, im prozeduralen Stil zu codieren) . Ich habe den größten Respekt vor meinem Senior, aber ich möchte den schrecklichen, prozeduralen Code (in Klassen) vermeiden, den unsere Legacy-Anwendung jetzt hat.

Wie kann eine jüngere Person mit viel weniger Erfahrung, aber deutlich mehr Antrieb (die diese Konzepte gelernt und mehrfach in die Praxis umgesetzt hat) einen älteren davon überzeugen, dass dies der beste Weg ist, mit angemessenem Respekt und Fingerspitzengefühl?

Eine Anmerkung, die vielleicht hilft: Vielleicht fühlen sie sich durch diese Veränderungen bedroht (was Sie in diesem speziellen Aspekt zum „Senior“ machen würde). Vielleicht bemerken Sie (auf subtile Weise), dass sie immer noch die Senior-Programmierer sein werden (weil sie andere Programmierprobleme kennen, die nichts mit OOP zu tun haben) ... und dass sie, sobald sie zusammenkommen, um OOP zu verwenden, Sie leicht erwischen werden gleiches Niveau an Fähigkeiten, also wird es zumindest kein Nachteil sein.
Es gibt gute Programmierer und es gibt "kluge" Programmierer. Die Kombination von „clever“ und OOP kann absolut tödlich sein (jemals versucht, C++-Code zu reparieren, der so clever war, dass er auf einem C++-Compiler kompiliert wurde, aber nicht auf einem anderen?) Und es gibt viele gute Gründe, eine große Codebasis nicht zu ändern. Grund Nummer eins ist das Kosten-Nutzen-Verhältnis.
Schauen Sie sich diesen Blogbeitrag an
Hmm, ich denke, diese Frage könnte ein wenig mehr abstrahiert werden, um jemanden mit mehr Erfahrung von einem Konzept zu überzeugen - was sicher schon einmal gestellt wurde (dies ist keine spezifische Website für Softwareentwicklung ...): -)
Zur Erinnerung: An OOP ist nichts Magisches, genauso wenig wie an der strukturierten Programmierung davor. Es ist ein gutes Tool, aber zum größten Teil ist es ein Formalismus von Best Practices, die in jeder Sprache angewendet werden können ... und wie diese Best Practices ist es nicht immer das beste Tool und/oder es lohnt sich nicht immer Investition zu kürzen. Es hört sich so an, als gäbe es viele Möglichkeiten, wie Code verbessert werden kann, ohne ihn auf OO verkaufen zu müssen, und mit einer viel, viel geringeren Investition.
FTR: Ich bin gegangen und habe meine Karriere anderswo fortgesetzt, wo ich anderen helfe, Best Practices zu lernen und zu lehren, wie man sie pragmatisch anwendet, mit dem Ziel, offener für die Ideen von Junioren zu sein und den in diesem Beitrag beschriebenen Zyklus nicht fortzusetzen. Zukünftige Leser – stellen Sie sicher, dass Sie dort sind, wo Sie es verdienen.

Antworten (1)

Du zeigst es ihnen.

Ich war an vielen Orten, an denen ich Leute schulen musste, und im Laufe der Jahre habe ich festgestellt, dass es nicht reicht, über Dinge zu reden. Die Leute werden auf ihre Erfahrungen zurückgreifen, und ihrer Erfahrung nach macht die objektorientierte Programmierung (OO) die Dinge zu komplex. Was Sie tun müssen, ist ihnen Wert zu zeigen .

Nehmen Sie ein Problem, das sie haben und kennen, und lösen Sie es so, wie Sie es tun würden. Zeigen Sie ihnen, wie Ihre Lösung einen Mehrwert gegenüber dem bietet, was sie wissen. Dies gibt ihnen eine Grundlage zum Lernen und Ihnen beiden eine konkrete Diskussionsgrundlage statt einer theoretischen, die viele sofort verwerfen werden.

Aber das allein reicht (für die meisten Menschen) nicht aus. Ihre Lösung wird immer noch zu kompliziert aussehen , da neue/neuartige Konzepte für die Menschen ausnahmslos mehr Arbeit bedeuten als das, was sie wissen. Der nächste Schritt besteht darin, ein relativ einfaches Beispiel zu nehmen und sie dazu zu bringen, es tatsächlich zu verwenden . Wenn Sie ein leitender Entwickler wären, würde ich sagen, dass Sie etwas OO-Code implementieren und andere Fehler darin beheben lassen. Als Junior-Entwickler bin ich mir nicht sicher. Für einige Leute kann der Versuch, sie dazu zu bringen, zu einem Codecamp zu gehen oder an einem Hobbyprojekt zu arbeiten, ein interessanter Anreiz sein. Möglicherweise müssen Sie jedoch einige Funktionen in einer OO-Manier implementieren und den Senior damit arbeiten lassen (Bugfixes, Erweiterungen usw.).

Meiner Erfahrung nach glauben die Leute erst wirklich, wie einfach/gut etwas sein kann, wenn sie es selbst benutzt haben.

^ Letztendlich deutet diese Antwort darauf hin, dass Sie, anstatt sich an einem Treffen zu beteiligen, um die Vorzüge zu diskutieren, losgehen und ein Beispiel dafür erstellen und es ihnen dann zeigen. Es sollte erwähnt werden, dass dies die Gefahr von Kritik birgt, wenn Sie etwas tun, zu dem Sie nicht angewiesen wurden, aber hier können Sie das Mantra anwenden: „Es ist einfacher, um Vergebung als um Erlaubnis zu bitten“.
Das Zeigen hat also funktioniert. Nachdem die Dinge, die ich baute, einwandfrei funktionierten (getestet, entworfen usw.) und andere nicht, fingen sie an, mir zuzuhören :-) Schade, dass ich es beweisen musste, einige von uns sind tatsächlich ehrlich mit ihrem Wissen ...
@Jimbo: Wir müssen uns alle beweisen, sonst wissen andere nicht, ob wir ehrlich sind oder nicht. Es reicht nicht, Recht zu haben.
@LightnessRacesinOrbit Du liegst nicht falsch!
Wie kann ein Junior einen Senior-Entwickler davon überzeugen, objektorientierte Konzepte zu verwenden? [Duplikat]
AntwortenHierDatenschutz-Bestimmungen1y, 0v