Wie beweise oder widerlege ich, dass “ Gottobjekte ” falsch sind?

Eine Änderung der Praxis wird durch die Identifizierung der Schmerzpunkte begründet erstellt durch das vorhandene Design. Insbesondere müssen Sie herausfinden, was aufgrund des vorhandenen Designs schwieriger ist als es sein sollte, was fragil ist, was jetzt kaputt geht, welche Verhaltensweisen nicht auf einfache Weise als direktes (oder sogar etwas indirektes) Ergebnis implementiert werden können Die aktuelle Implementierung oder in einigen Fällen, wie die Leistung leidet, wie viel Zeit erforderlich ist, um ein neues Teammitglied auf den neuesten Stand zu bringen usw.

Zweitens übertrifft der Arbeitscode alle Argumente über Theorie oder gutes Design Dies gilt leider auch für schlechten Code. Sie müssen also eine bessere Alternative anbieten, was bedeutet, dass Sie als Verfechter besserer Muster und Praktiken eine Umgestaltung vornehmen müssen, um ein besseres Design herauszuarbeiten. Suchen Sie eine schmale Ebene im Tracer-Bullet-Stil durch das vorhandene Design und implementieren Sie eine Lösung, die möglicherweise für die erste Iteration die Implementierung des God-Objekts am Laufen hält, die tatsächliche Implementierung jedoch auf das neue Design verschiebt. Schreiben Sie dann einen Code, der dieses neue Design nutzt, und zeigen Sie, was Sie aufgrund dieser Änderung gewinnen, ob es sich um Leistung, Wartbarkeit, Funktionen, Korrektur von Fehlern oder Rennbedingungen oder Reduzierung der kognitiven Belastung für den Entwickler handelt.

Es ist oft eine Herausforderung, eine Oberfläche zu finden, die klein genug ist, um in schlecht strukturierten Systemen anzugreifen. Es kann länger dauern, als Sie einen Anfangswert liefern möchten, und die anfängliche Auszahlung ist möglicherweise nicht so beeindruckend an alle, aber Sie können auch daran arbeiten, einige Befürworter Ihres neuen Ansatzes zu finden, wenn Sie sich mit Teammitgliedern zusammenschließen, die zumindest ein wenig sympathisch sind.

Das Gott-Objekt zu beklagen funktioniert nur, wenn Sie predigen der Chor. Es ist ein Werkzeug zum Benennen eines Problems und funktioniert nur, um es zu lösen, wenn Sie ein empfängliches Publikum haben, das älter und motiviert genug ist, etwas dagegen zu tun. Das Reparieren des Gott-Objekts gewinnt das Argument.

Da Ihr unmittelbares Anliegen das Executive Buy-In zu sein scheint, sollten Sie am besten dafür eintreten, dass das Ersetzen dieses Codes ein strategisches Ziel sein muss, und diese mit den Geschäftszielen verknüpfen, für die Sie verantwortlich sind. Ich denke, Sie Sie können geltend machen, dass Sie eine technische Anleitung geben können, indem Sie zunächst an einer technischen Spitze arbeiten, die Ihrer Meinung nach ersetzt werden sollte, wobei vorzugsweise Ressourcen von einer oder zwei technischen Personen verwendet werden, die Vorbehalte gegen das aktuelle Design haben.

Ich denke, Sie haben genügend Ressourcen gefunden, um Ihre Argumentation zu rechtfertigen. Personen in solchen Besprechungen werden nur auf die Zusammenfassung Ihrer Forschung achten und sie werden aufhören zuzuhören, nachdem Sie zwei oder drei bestätigende Quellen erwähnt haben.Ihr Fokus sollte zunächst darauf liegen, dass Buy-off das Problem löst, das Sie sehen, und nicht unbedingt beweist, dass jemand anderes falsch liegt oder Sie selbst Recht haben. Dies ist ein soziales Problem, kein logisches.

In einer Technologie-Führungsrolle müssen Sie jede Ihrer Initiativen mit Geschäftszielen verknüpfen. Das Wichtigste, um Ihren Fall gegenüber Führungskräften zu vertreten, ist also das, was die Arbeit wird für diese Ziele tun. Da Sie auch als „neuer Typ“ gelten, können Sie nicht einfach erwarten, dass die Leute ihre Arbeit wegwerfen oder sich schnell anstellen. Sie müssen Vertrauen aufbauen, indem Sie beweisen, dass Sie liefern können. Als langfristiges Anliegen müssen Sie in einer Führungsrolle auch lernen, sich auf Ergebnisse zu konzentrieren, aber nicht unbedingt an die Besonderheiten des Ergebnisses gebunden sein. Sie sind jetzt da, um strategische Anweisungen zu geben, taktische Hindernisse aus dem Fortschritt Ihres Teams zu entfernen und Ihrem Team Mentoring anzubieten, ohne mit Ihren eigenen Teammitgliedern Glaubwürdigkeitsschlachten zu gewinnen.

Eine Top-Down-Entscheidung treffen wird Seien Sie selten glaubwürdig, es sei denn, Sie haben einen Skin im Spiel. Wenn Sie sich erneut in einer ähnlichen Situation befinden, sollten Sie sich mehr auf die Konsensbildung in Ihrem Unternehmen konzentrieren, anstatt zu eskalieren, sobald Sie das Gefühl haben, dass die Situation außer Kontrolle geraten ist.

Aber wenn man bedenkt, wo Sie sich gerade befinden, würde ich sagen, dass Sie am besten argumentieren sollten, dass Ihr Ansatz auf der Grundlage Ihrer Erfahrung messbare langfristige Vorteile bringt und dass er mit der Arbeit bekannter Praktiker wie übereinstimmt Onkel Bob und Co., und dass Sie ein paar Tage / Wochen damit verbringen möchten, mit gutem Beispiel voranzugehen, um den höchsten Aspekt des Geldbeutels zu überarbeiten, um zu demonstrieren, wie Ihre Sicht auf gutes Design aussehen sollte. Sie müssen jedoch jeden Fall an bestimmten Geschäftszielen ausrichten, die über Ihre persönlichen Vorlieben hinausgehen.

Kommentare

• Ein guter Punkt, wenn es sich um einen handelt soziales Problem. Muss sein, warum es so viel schlecht geschriebenen Code und schlecht gestaltete Anwendungen gibt.
• +1 für die Verknüpfung mit ‚ business speak ‚ als solches; versuchen Sie, es für Ihr Publikum so relevant wie möglich zu machen. Wenn Sie ‚ mit Führungskräften sprechen, dann tun Sprechen Sie darüber, wie der Standard des Codes einen direkten Zusammenhang mit Wartung und Leistung hat, und diskutieren Sie, wie dies mit den Gesamtfinanzen des Projekts, der Langzeitstabilität usw. zusammenhängt. Es hört sich so an, als ob Sie ‚ wurde aufgrund Ihres Wissens eingestellt. Denken Sie daran. (‚ werden Sie kein Wichsmanager, der denkt er weiß es immer am besten – aber in diesem Fall sind Sie ‚ zu 100% korrekt.)
• +1 für “ Arbeitscode übertrifft alle Argumente über Theorie oder gutes Design. “ Etwas, das wir bei unserer Suche oft vergessen für perfekten Code.
• Tolle Antwort, viel Weisheit für aufstrebende Teamleiter.

Oh, hier bin ich und nekroiere eine andere alte Frage, aber ich gehe davon aus, dass Sie dieses Argument nicht gewonnen haben und hier warum.

Es klingt wie ein Kulturproblem

Sie sind ihre Manager, aber Sie können sie nicht ersetzen, und Sie müssen zu Ihren Managern gehen, um sie dazu zu bringen, das zu tun, von dem Sie glauben, dass sie es tun sollten. Es klingt für mich wie ein klassischer Fall von Code, der die Kultur widerspiegelt, in der er geboren wurde. Mit anderen Worten, das göttliche Objekt ist, wie diese Firma arbeitet. Möchten Sie irgendeine sinnvolle Änderung vornehmen? Sie gehen immer an den gleichen Ort dafür letztendlich, da anscheinend alle Entscheidungen oben geklärt werden müssen.

Wurde p Ich bin jetzt der Meinung, dass Sie die Kultur, die den Code überhaupt erst möglich gemacht hat, nicht bekämpfen können, wenn diese Kultur noch fest verankert ist oder zumindest die Kampfkultur ist Ein sehr harter Aufstieg, bei dem es unwahrscheinlich ist, dass mich jemals jemand genug bezahlen oder mir genug Kraft geben kann, um das Gefühl zu haben, dass es ein lohnendes Unterfangen war, das wahrscheinlich jemals wieder erfolgreich sein wird.

Bevor es Veränderungen geben kann, Sie müssen motiviert sein, sich zu ändern, und leider ist es für uns als Programmierer, denen es verdammt egal ist, gelegentlich Stack zu lesen, schwer zu verstehen, dass nicht jeder von den gleichen Dingen motiviert ist. Ich habe in meinen Erfahrungen viele rationale Argumente gewonnen, aber letztendlich leidet das Unternehmen aus einem bestimmten Grund unter intellektuell faulen Entwicklern.

Vielleicht waren die geschäftlichen Bedenken motiviert, nur an morgen und nicht an morgen zu denken nächste Woche oder fünf Jahre später (ein besonders frustrierendes Szenario, wenn Sie „das Kind von Einwanderern aus einem Land sind, das im Falle einer Apokalypse ein Samengewölbe in der Arktis gebaut hat). Vielleicht haben sie Angst vor Veränderungen.Vielleicht schätzen sie das Dienstalter zu sehr, bis zu dem Punkt, dass die Befehlskette bedeutungslos ist, selbst wenn sie von außen eingestellt werden müssen, um einen Entwickler-Teamleiter oder Manager hinzuzuziehen, weil sie erkennen, dass niemand in ihrem All-Lifer-Team in ihrer Zeit genug gewachsen ist dort (oder weil besagte Lifter das mit Verantwortung verbundene Risiko nicht wollen). Oder, und ich habe das gesehen, vielleicht ist es „das sehr reale und deprimierende Phänomen der Mittelmäßigkeit, die sich selbst einsetzt, weil sie tief im Inneren weiß, dass sie es kann“. Wenn Sie nicht mit der Qualität konkurrieren und wenn es genug Dummheiten gibt, um sie zu umgehen, ist es unmöglich herauszufinden, wer schuld ist, wenn alles regelmäßig in Stücke geht.

Wie bekämpfen Sie Probleme, die letztendlich in Angst oder Angst wurzeln? gebrochene Metriken für den Erfolg? Ich werde Ihnen das sagen, es braucht viel mehr als nur ein engagiertes Qualitäts-Entwicklerteam, und Sie hatten viel weniger als das vom Sound zum Zeitpunkt der Veröffentlichung dieses Qs.

In dem nicht unmöglichen Fall, dass es sich nicht um ein hartnäckiges Kulturproblem handelt …

Nehmen wir nun an, dass die Leute an der Spitze stehen sind sehr empfänglich für Veränderungen und sie sind tatsächlich bereit, Ihnen zu vertrauen, dass Sie es schaffen. Sie müssen wirklich nur alle Ihre Argumente mit Geld und verpassten Gelegenheiten untermalen.

Jedes Mal, wenn es länger dauert, jemanden zu trainieren Neu in dieser lächerlichen Codebasis: Jedes Mal, wenn es länger dauert, etwas zu ändern oder eine neue Funktion hinzuzufügen, kostet es Geld, wenn es unerschwinglich schwierig wird, Endpunkte von einem Unternehmen, mit dem Sie eine Partnerschaft eingehen möchten, einem anderen System zur Verfügung zu stellen Freaking Money. Am wichtigsten ist, dass ein Fenster für einen kleineren, agileren Konkurrenten offen bleibt, um Sie in eine Position zu bringen, in der Sie nur viel zu langsam auf sie reagieren können wly, und entreißen Sie letztendlich alles von Ihnen.

Erkennen Sie einfach, dass eine besonders hartnäckige und dumme Kultur den Status quo um jeden Preis aufrechterhält, selbst wenn das tatsächliche physische Dach des Unternehmens tatsächlich in Flammen steht, weil

Kommentare

• Kurz darauf verließ ich das Unternehmen. Sie versuchten, mich in Vollzeit einzustellen und mich von Seattle nach New York zu ziehen, um das Angebot anzunehmen. Ich habe ihnen im Grunde gesagt, dass “ Auf keinen Fall, ich ‚ nicht nach NY ziehen werde, wenn das Team, das ich leiten würde, in Bellevue ist. WA “ und zu diesem Zeitpunkt ging ich im Grunde genommen über die Straße und bekam einen Job bei MSFT, bis ich etwas Besseres fand.
• @honestduane Ja, diese Erwartungen allein spricht Bände. Gut für Sie im GTFO.

Sie können einige der grundlegendsten OOP-Prinzipien wie z lose Kupplung und hohe Kohäsion. Ein „Gott-Objekt“ klingt so, als würde es nicht verwandte Klassen koppeln und einen geringen Zusammenhalt haben.

Sie könnten Onkel Bob immer selbst fragen

Die Sache ist, dass es für Menschen mit jedem Sinn so offensichtlich ist, dass es, sobald es einmal formuliert ist, nicht von einer Vielzahl von Autoren erneut referenziert werden muss. Es muss nur sein eine Quelle.

Andere Begriffe, mit denen Sie bei der Suche nach Quellen beginnen möchten, sind:

• FEST
• Gesetz des Demeters
• Big Ball of Mud

Alle diese Konzepte beziehen sich auf verwandte Konzepte, die möglicherweise brauchbare Referenzquellen liefern, obwohl sie sie nicht als solche bezeichnen.

Letztendlich Sie sind der Chef. Der Grund dafür ist, dass Sie es sagen, und obwohl Sie als guter Manager gelten, sollten Sie wirklich bereit sein, Ihre Entscheidungen zu rechtfertigen. Sie haben das getan, und wenn es immer noch Widerstand gibt, Die richtige Vorgehensweise besteht darin, dass Ihr Team das tut, was ihm gesagt wurde.

Kommentare

• “ Wenn es immer noch Widerstand gibt, muss Ihr Team die richtigen Maßnahmen ergreifen, um ‚ “ Vielleicht besteht die richtige Vorgehensweise darin, zu beenden, anstatt Ihr Team unglücklich zu machen.?
• Der Manager ‚ s Die Entscheidung wurde hinreichend begründet. Wenn das Team nicht ‚ zustimmt, liegt das Problem beim Team. Das OP wurde für sein Fachwissen eingestellt und durfte es nicht zum Nutzen des Unternehmens nutzen, da sich Kollegen ‚ nicht angemessen verhalten, wenn ‚ t akzeptabel. Lassen Sie ‚ Ihre Behauptung auf den Kopf stellen – warum sollten ‚ die widerstandsfähigen Teammitglieder nicht kündigen, wenn ihre Sicht auf den Job nicht kompatibel ist das des Geschäfts?
• Fairer Punkt. Es hängt davon ab, wie Sie das Team führen möchten. Aber meiner Erfahrung nach führt es dazu, dass Menschen gezwungen werden, Dinge gegen ihren Willen zu tun. Ich würde lieber God Objects in der gesamten Codebasis sehen als ein elendes Entwicklungsteam. Vielleicht besteht die Antwort darin, sie auf einen Schulungskurs zu schicken. Jeder liebt einen Trainingskurs. Win-Win.
• Der leitende Entwickler / Manager / was auch immer sollte unbedingt alle angemessenen Maßnahmen ergreifen, um sicherzustellen, dass das Team eine gute Arbeitsbeziehung untereinander beibehält. Wenn zusätzliches Training hilfreich ist, sollten Sie es auf jeden Fall als Option in Betracht ziehen – aber dies scheint ein Fall von vorsätzlicher Ignoranz zu sein und jemandem zu sagen, dass er geschult werden muss, um Ihre Idee zu verstehen, wenn er denkt, dass er ‚ habe getan ist nicht einverstanden, anstatt nicht zu verstehen, könnte nach hinten losgehen. Es fällt mir schwer, mir Möglichkeiten für den Umgang mit Menschen vorzustellen, die ‚ nicht lernen möchten.

Wie beweise oder widerlege ich, dass „Gott“ -Objekte falsch sind?

Sie können nicht.

Diese Art von Vermutung ist für mathematische Beweise nicht zugänglich, und mathematische Beweise sind die einzigen Beweise, die stichhaltig sind.

Selbst wenn Sie versuchen, das emotionale Wort „falsch“ zu ersetzen. Mit quantifizierbaren Maßen der Auswirkungen der Verwendung von Gottobjekten werden Sie Folgendes feststellen:

1. Die verfügbaren Maße sind grob.
2. Es gibt nur wenige glaubwürdige Studien, in denen diese Maße quantifiziert wurden Für Code, der von professionellen Programmierern
3. erstellt wurde, gibt es nur wenige glaubwürdige Studien, in denen Sprachkonstrukte oder Design- (Anti-) Muster mit diesen Maßnahmen verknüpft wurden.

Und das ignoriert das Problem der Entscheidung, wann ein bestimmtes Objekt ein „Gott“ -Objekt ist.

Bestenfalls konnten diese Arten von Studien nur eine empirische Korrelation nachweisen. Kein echter Beweis.

---

Was Sie tatsächlich tun, ist die Vor- und Nachteile von „Gott“ -Objekten zu debattieren, um die Meinungen anderer Völker zu ändern … und dann die Praxis Ihrer Organisation.

Verwenden Sie keine Wörter wie „Beweis“, oder die Personen, mit denen Sie diskutieren, neigen dazu, Ihnen ins Gesicht zu lachen.

Vielleicht möchten Sie Guru der Woche # 84 sehen Es geht nur um Gottobjekte (Monolithen) und wie schlecht sie sind.

Auszug:

(Major) Es isoliert potenziell unabhängige Funktionalität innerhalb einer Klasse […] (geringfügig) Es kann davon abgeraten werden, die Klasse um neue Funktionen zu erweitern […]

Ich bin mir nicht sicher, ob Ihr Team wirklich an einem akademischen Beweis interessiert ist, dass „Gottes Objekte falsch sind“.

Aus psychologischer Sicht kann Ihr Refactoring-Ansatz als Angriff auf die Kompetenz des Teams a la missverstanden werden: „Das Team hat einen schlechten Job gemacht“, obwohl das Programm wie erwartet funktioniert.

Was Sie wirklich tun möchten, ist, die negativen Nebenwirkungen von „Spagetti-Code“ und „Gott-Objekten“ zu bewältigen: Explosionskosten für das Hinzufügen neuer Funktionen aufgrund zunehmender Fehler, die durch Nebenwirkungen verursacht werden.

Seien Sie sehr Spezifische Fragen zu stellen, anstatt Antworten zu geben, kann hilfreicher sein:

manager > Why did implement the new tax-calculation schema took more than 4 weeks team > because {reason a} manager > And why was {reason a}? team > because {reason b} manager > And why was {reason b}? ... team > because {reason z} manager > what could we do to avoid {reason z} ? team > refactor code