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

Problemzusammenfassung:

Kurz gesagt, ich habe eine Codebasis und ein Entwicklungsteam geerbt, das ich nicht ersetzen darf, und die Verwendung von God Objects ist ein großes Problem. In Zukunft möchte ich, dass wir die Dinge neu faktorisieren, aber ich werde von den Teams zurückgedrängt, die alles mit God Objects machen wollen, "weil es einfacher ist", und dies bedeutet, dass ich nicht die Möglichkeit habe, die Dinge neu zu faktorisieren. Aufgrund meiner jahrelangen Erfahrung in der Entwicklung habe ich mich zurückversetzt und darauf hingewiesen, dass ich der neue Chef bin, der eingestellt wurde, um diese Dinge usw. zu kennen, und ebenso die Vertriebsmitarbeiter von Drittanbietern im Offshore-Bereich, und dies jetzt auf der Führungsebene und in meinem Meeting ist morgen und ich möchte mit viel technischer Munition für Best Practices eintreten, da ich der Meinung bin, dass dies auf lange Sicht billiger sein wird (und ich persönlich bin der Meinung, dass dies das ist, worüber sich der Dritte Sorgen macht).

Mein Problem ist aus technischer Sicht, ich weiß, dass es langfristig gut ist, aber ich habe Probleme mit der Ultrakurz- und 6-Monats-Laufzeit, und obwohl ich es "weiß", kann ich es nicht mit Referenzen und zitierten Ressourcen außerhalb beweisen von einer Person (Robert C. Martin, auch bekannt als Onkel Bob), da mir gesagt wurde, dass es nicht gut genug ist, Daten von einer Person und nur einer Person (Robert C Martin) zu haben .

Frage:

Welche Ressourcen kann ich von bekannten Experten auf diesem Gebiet direkt zitieren (Titel, Erscheinungsjahr, Seitenzahl, Zitat), die ausdrücklich sagen, dass diese Verwendung von "Gott" -Objekten / Klassen / Systemen schlecht (oder gut) ist, da wir suchen für die technisch valide Lösung)?

Ich habe bereits recherchiert:

1. Ich habe eine Reihe von Büchern hier und ich habe ihre Verzeichnisse nach den Wörtern "God Object" und "God Class" durchsucht. Ich fand, dass es seltsamerweise fast nie benutzt wird und die Kopie des GoF-Buches, die ich zum Beispiel habe, es nie benutzt (zumindest gemäß dem Index vor mir), aber ich habe es in den beiden Büchern unten gefunden, aber ich möchte mehr Ich kann nutzen.
2. Ich habe auf der Wikipedia-Seite nach "God Object" gesucht und es handelt sich derzeit um einen Stub mit wenigen Verweisen. Obwohl ich persönlich damit einverstanden bin, heißt es, dass ich in einer Umgebung, in der persönliche Erfahrungen als ungültig gelten, nicht viel verwenden kann. Das zitierte Buch wird auch von den Leuten, mit denen ich diese technischen Punkte diskutiere, als zu alt angesehen, als das Argument, das sie vorbringen, ist, dass "es einst für schlecht gehalten wurde, aber niemand es beweisen konnte, und jetzt sagt moderne Software" Gott msgstr "Objekte sind gut zu benutzen". Ich persönlich glaube, dass diese Aussage falsch ist, aber ich möchte die Wahrheit beweisen, was auch immer es ist.
3. In Robert C. Martins "Agile Prinzipien, Muster und Praktiken in C #" (ISBN: 0-13-185725-8, gebunden) heißt es auf Seite 266: "Jeder weiß, dass Gottesklassen eine schlechte Idee sind. Wir wollen nicht die gesamte Intelligenz eines Systems auf ein einzelnes Objekt oder eine einzelne Funktion zu konzentrieren. Eines der Ziele von OOD ist die Aufteilung und Verteilung des Verhaltens in viele Klassen und viele Funktionen. " - Und manchmal ist es sowieso besser, Gottklassen zu verwenden (am Beispiel von Mikrocontrollern).
4. In Robert C. Martins "Clean Code: Ein Handbuch für agiles Softwarehandwerk" (Seite 136) (und nur diese Seite) wird die "Gottesklasse" als Paradebeispiel für eine Verletzung der "Klassen sollten klein sein" -Regel genannt er fördert damit das Prinzip der Einzelverantwortung "ab Seite 138.

Das Problem, das ich habe, ist, dass alle meine Referenzen und Zitate von derselben Person (Robert C. Martin) stammen und von derselben Person / Quelle stammen. Mir wurde gesagt, dass mein Wunsch, "God Classes" nicht zu verwenden, ungültig ist und nicht als Standard-Best-Practice in der Software-Branche akzeptiert wird, weil er nur eine Ansicht ist. Ist das wahr? Mache ich aus technischer Sicht etwas falsch, indem ich versuche, mich an die Lehre von Onkel Bob zu halten?

Gott Objekte und objektorientierte Programmierung und Design:

Je mehr ich darüber nachdenke, desto mehr lernst du, wenn du OOP studierst. Sein implizites zu gutem Design ist mein Denken (Fühlen Sie sich frei, mich zu korrigieren, bitte, wie ich lernen möchte), das Problem ist, dass ich das "weiß", aber nicht jeder tut, so dass es in diesem Fall kein gültiges Argument ist, weil Ich bezeichne es effektiv als universelle Wahrheit, obwohl die meisten Menschen statistisch gesehen nichts davon wissen, da statistisch gesehen die meisten Menschen keine Programmierer sind.

Fazit:

Ich weiß nicht, wonach ich suchen soll, um die besten zusätzlichen Ergebnisse zu erzielen, da sie einen technischen Anspruch erheben, und ich möchte die Wahrheit wissen und sie mit Zitaten wie ein echter Ingenieur / Wissenschaftler nachweisen können, auch wenn Aufgrund meiner persönlichen Erfahrung mit Code, der sie verwendet, bin ich gegen Gottobjekte voreingenommen. Jede Unterstützung oder Zitate wäre sehr dankbar.

Der Grund für jede Änderung der Praxis besteht darin, die durch das vorhandene Design verursachten Schwachstellen zu identifizieren. Insbesondere müssen Sie herausfinden, was aufgrund des vorhandenen Designs schwieriger ist als es sein sollte, was zerbrechlich ist, was derzeit bricht, 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 lange es dauert, ein neues Teammitglied auf den neuesten Stand zu bringen usw.

Zweitens übertrumpft 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 Befürworter besserer Muster und Praktiken eine Neugestaltung vornehmen müssen, um ein besseres Design zu finden. Suchen Sie eine schmale Ebene im Tracer-Bullet-Stil durch das vorhandene Design und implementieren Sie eine Lösung, mit der die Implementierung des God-Objekts möglicherweise für die Iteration weiterhin funktioniert, die tatsächliche Implementierung jedoch auf das neue Design verschoben wird. 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 Fläche zu finden, die klein genug ist, um in schlecht strukturierten Systemen angegriffen werden zu können. Es kann länger dauern, als Sie möchten, um einen anfänglichen Wert zu erzielen. Die anfängliche Auszahlung ist möglicherweise nicht für alle so beeindruckend, aber Sie können auch arbeiten auf der Suche nach einigen Befürwortern Ihres neuen Ansatzes, wenn Sie sich mit Teammitgliedern zusammentun, die zumindest ein wenig mitfühlend sind.

Den Gott beklagen Das Objekt funktioniert nur, wenn Sie vor dem Chor predigen. Es ist ein Tool zum Benennen eines Problems und funktioniert nur dann, wenn Sie eine aufnahmefähige Zielgruppe haben, die hochrangig und motiviert genug ist, etwas dagegen zu unternehmen. Das Reparieren des Gottesobjekts gewinnt das Argument.

Da Ihre unmittelbare Sorge 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 Ziele mit den Geschäftszielen verknüpfen, für die Sie verantwortlich sind. Ich denke, Sie können ein Argument dafür liefern, dass Sie eine technische Richtung vorgeben können, indem Sie zunächst an einem technischen Ansatz arbeiten, der Ihrer Meinung nach ersetzt werden sollte, und dabei vorzugsweise Ressourcen von ein oder zwei technischen Mitarbeitern einbeziehen, die Vorbehalte gegen das aktuelle Design haben.

Ich denke, Sie haben genügend Ressourcen gefunden, um Ihre Argumentation zu rechtfertigen. Die Leute in solchen Meetings 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. Zunächst sollten Sie sich darauf konzentrieren, dass Buy-off das Problem löst, das Sie sehen, und nicht unbedingt, dass jemand anderes sich oder sich selbst als falsch erweist. Dies ist ein soziales Problem, kein logisches.

In einer technologischen Führungsrolle müssen Sie jede Ihrer Initiativen mit den Geschäftszielen verknüpfen. Das Wichtigste für Ihre Argumentation gegenüber Führungskräften ist also, was die Arbeit für diese Ziele leistet. Da Sie auch als der "neue Typ" angesehen werden, können Sie nicht einfach erwarten, dass die Leute ihre Arbeit wegwerfen oder sich schnell anstellen. Sie müssen Vertrauen aufbauen, indem Sie nachweisen, dass Sie liefern können. Als langfristiges Anliegen müssen Sie in einer Führungsrolle auch lernen, sich auf die Ergebnisse zu konzentrieren, aber nicht unbedingt an die Besonderheiten des Ergebnisses gebunden zu sein. Sie sind jetzt da, um die strategische Richtung vorzugeben, taktische Hindernisse für den Fortschritt Ihres Teams zu beseitigen und Ihr Team zu betreuen, statt mit Ihren eigenen Teammitgliedern Glaubwürdigkeitskämpfe zu gewinnen.

Eine Top-Down-Entscheidung zu treffen, ist nur dann glaubwürdig, wenn Sie einen Skin im Spiel haben. Wenn Sie sich immer wieder in einer ähnlichen Situation befinden, sollten Sie sich mehr auf die Konsensbildung in Ihrem Unternehmen konzentrieren, als auf die Eskalation, sobald Sie glauben, dass die Situation außer Kontrolle geraten ist.

Aber wenn man bedenkt, wo Sie jetzt sind, ist es am besten zu argumentieren, dass Ihr Ansatz messbare langfristige Vorteile bringt, die auf Ihren Erfahrungen beruhen und mit der Arbeit bekannter Praktiker wie Onkel Bob und Co im Einklang stehen. , und dass Sie ein paar Tage / Wochen mit gutem Beispiel vorangehen möchten, um ein enges Refactoring des höchsten Preis-Leistungs-Verhältnisses durchzuführen, um zu demonstrieren, wie Ihre Sicht auf gutes Design aussehen sollte. Sie müssen sich jedoch unabhängig von Ihren persönlichen Vorlieben an bestimmten Geschäftszielen ausrichten.

Zunächst müssen Sie darlegen, dass jede messbare Organisation die Best Practices der Branche übernehmen muss. Zu sagen, dass "es nur bei uns funktioniert!" kann nicht gemessen werden, weder in der Zeit noch in der Ressource, da es einfach unvorhersehbar ist. Software Engineering ist eine Wissenschaft wie keine andere Wissenschaft. Diese Konzepte wurden untersucht, erforscht, getestet und dokumentiert.

1. Das Gott-Objekt ist ein Anti-Muster, das das besagt

   In der Softwareentwicklung ist ein Antimuster (oder Antimuster) ein Muster, das im sozialen oder geschäftlichen Betrieb oder in der Softwareentwicklung verwendet wird und das häufig verwendet wird, in der Praxis jedoch ineffektiv und / oder kontraproduktiv ist.

2. In der Google IO-Konferenz von 2009 wurde dieses Thema teilweise erläutert, als das MVP-Muster erläutert wurde. Es ist möglicherweise nicht relevant für das Gott-Objekt, kann Ihnen aber Munition geben.

3. Die Verwendung dieses Anti-Musters verstößt auch gegen das Prinzip der alleinigen Verantwortung in objektorientierten Entwürfen, in dem Folgendes angegeben ist:

   Jede Klasse sollte eine einzige Verantwortung haben, und diese Verantwortung sollte vollständig von der Klasse gekapselt werden. Alle seine Dienstleistungen sollten eng mit dieser Verantwortung verbunden sein.

4. Der Decaying Code Blog spricht auch darüber und über seine Lösung.

5. Wir können nicht über die einzige Verantwortung Prinzip , ohne reden über das Objekt sprechen Kopplung .

   [...] Kopplung oder Abhängigkeit ist der Grad, in dem jedes Programmmodul auf jedes der anderen Module angewiesen ist.

   Wenn ein eng gekoppeltes System zu assembly of modules [to] require more effort and/or time [to maintain] due to the increased inter-module dependency.einem höheren Grad an Objektkopplung führen kann, bedeutet dies eine geringere Kohäsion und umgekehrt. Gott-Objekte sind ein gutes Beispiel für eine enge Kopplung, da sie mehr wissen, als sie sollten, sie also mit Verantwortung überladen und somit die Wiederverwendbarkeit von Code stark einschränken.

6. Beim Entwerfen einer komplexen Anwendung muss die Einfachheit berücksichtigt werden. Große Probleme müssen in kleinere Probleme zerlegt werden, die einfacher zu verwalten, zu testen und zu dokumentieren sind. Dies gilt insbesondere für ein objektorientiertes Paradigma.

   Mit diesem Argument kehren wir zum Anti-Muster-Argument zurück, aber dieses Paradigma handelt von Mustern, der Repräsentation realer Objekte und letztendlich der Datenkapselung.

7. Sie haben Recht, wenn Sie sagen, dass diese "guten Praktiken" in Klassenzimmern häufiger vorkommen. Ich habe jedoch Unterrichtserfahrungen am College (und an einigen Universitäten), und ich habe nur gesehen, dass diese Prinzipien an Universitäten, insbesondere an den Fakultäten für Ingenieurwissenschaften, gelehrt werden. Welches ist traurig. Aber wie bei jeder guten Praxis lernen diejenigen, die sich selbst verbessern möchten, in der Regel einige grundlegende Entwurfsmuster und verstehen schließlich, wie man zwischen Kopplung und Zusammenhalt dschungelt.

   Was ich in der Regel Studenten unterrichten ist , dass es möglicherweise scheinen mehr Anstrengungen zu erfordern gute Programmierstandards anzunehmen, aber es immer auf lange Sicht auszahlen. Ein gutes Beispiel wäre jemand, der einen Programmierer bittet, eine Sortierfunktion zu schreiben. Der Programmierer hat zwei Möglichkeiten; 1) Schreiben Sie eine schnelle Blasensortierfunktion (weniger als 5 Minuten), die bei wachsender Liste von Elementen nicht nachhaltig ist mit größeren Listen.

Oh, hier habe ich eine andere alte Frage, aber ich gehe davon aus, dass Sie dieses Argument nicht gewonnen haben und hier ist der Grund.

Es klingt wie ein Kulturproblem

Sie sind ihr Manager, aber Sie können sie nicht ersetzen, und Sie müssen zu Ihren Managern gehen, um sie zu veranlassen, das zu tun, was sie Ihrer Meinung nach tun sollten Objekte vorwärts bewegen. Es klingt für mich wie ein klassischer Fall von Code, der die Kultur widerspiegelt, in der er geboren wurde. Mit anderen Worten, das Gott-Objekt ist, wie diese Firma funktioniert. Möchten Sie eine sinnvolle Änderung vornehmen? Letztendlich sind Sie immer am selben Ort, da anscheinend alle Entscheidungen oben geklärt werden müssen.

Nachdem ich mehrere Fehlversuche bei Bereinigungen von Legacy-Codes und Änderungen der Code-Richtlinien kennengelernt habe, bin ich jetzt der Meinung, dass Sie die Kultur, die den Code erst ermöglicht hat, nicht bekämpfen können, wenn diese Kultur noch fest verwurzelt ist oder zumindest kämpft Kultur ist eine sehr harte Sache, die es kaum jemandem erlaubt, mich zu bezahlen oder mir die Kraft zu geben, das Gefühl zu haben, es sei ein lohnendes Unterfangen, das wahrscheinlich jemals wieder Erfolg haben würde.

Bevor es Veränderungen geben kann, müssen sie motiviert werden, sich zu verändern, und leider ist es für uns als Programmierer, die sich die Mühe machen, gelegentlich Stack zu lesen, schwer zu verstehen, dass nicht jeder von den gleichen Dingen motiviert ist. Ich habe viele der rationalen Argumente in meinen Erfahrungen gewonnen, aber am Ende leidet das Unternehmen aus einem bestimmten Grund unter intellektuell faulen Entwicklern.

Vielleicht waren die Geschäftsinteressen motiviert, nur an morgen zu denken, anstatt erst in der nächsten Woche oder in den nächsten fünf Jahren (ein besonders frustrierendes Szenario, wenn Sie das Kind von Einwanderern aus einem Land sind, das im Falle einer Apokalypse ein Saatgutdepot in der Arktis errichtet hat). Vielleicht haben sie Angst vor Veränderungen. Vielleicht schätzen sie das Dienstalter so sehr, dass die Befehlskette selbst dann bedeutungslos ist, 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 der Verantwortung verbundene Risiko nicht wollen). Oder, und ich habe es gesehen, vielleicht ist es das sehr reale und deprimierende Phänomen, dass sich Mittelmäßigkeit für sich einsetzt, weil sie tief im Inneren weiß, dass sie es kann. '

Wie bekämpfen Sie Probleme, die letztendlich in Ängsten oder fehlerhaften Kennzahlen für den Erfolg begründet sind? Ich sage dir das, es braucht viel mehr als nur ein engagiertes Qualitätsentwicklerteam und du hattest viel weniger von dem Sound, den es zum Zeitpunkt der Veröffentlichung dieses Qs hatte.

In dem nicht unmöglichen Fall, dass es sich nicht um ein nicht lösbares Kulturproblem handelt ...

Angenommen, die Leute an der Spitze sind sehr bereit, sich zu verändern, und sie sind tatsächlich bereit, Ihnen zu vertrauen, damit Sie es schaffen, müssen Sie wirklich nur all Ihre Argumente mit Geld und verpassten Gelegenheiten untermauern.

Jedes Mal, wenn es länger dauert, jemanden auf diese lächerliche Codebasis vorzubereiten, und jedes Mal, wenn es länger dauert, eine Funktion zu ändern oder hinzuzufügen, wird es unerschwinglich, Endpunkte von einem Unternehmen, mit dem Sie eine Partnerschaft eingehen möchten, einem anderen System zugänglich zu machen Es kostet Geld. Viel verdammtes Geld. Am wichtigsten ist, dass ein kleinerer, agilerer Konkurrent ein Fenster offen lässt, in dem er Sie in die Lage versetzt, viel zu langsam auf sie zu reagieren und Ihnen letztendlich alles wegzureißen.

Beachten Sie nur, dass eine besonders hartnäckige und dumme Kultur den Status Quo um jeden Preis aufrechterhält, auch wenn das eigentliche physische Dach des Unternehmens deswegen tatsächlich in Flammen steht.

Sie können einige der grundlegendsten OOP-Prinzipien wie lose Kopplung und hohe Kohäsion anführen. Ein "Gott-Objekt" hört sich so an, als würde es Klassen ohne Beziehung koppeln und einen geringen Zusammenhalt haben.

Man könnte Onkel Bob immer selbst fragen.

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

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

• SOLIDE
• Gesetz von Demeter
• Großer Ball aus Schlamm

Alle diese ausdrücklichen verwandten Konzepte könnten brauchbare Referenzquellen liefern, auch wenn sie sie nicht wirklich als solche bezeichnen.

Letztendlich bist du aber der Boss. Der Grund dafür ist, dass Sie dies 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, muss Ihr Team das tun, was ihm gesagt wurde.

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

Du kannst 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" durch quantifizierbare Maße für die Auswirkungen der Verwendung von Gottobjekten zu ersetzen, werden Sie feststellen, dass:

1. die verfügbaren Maßnahmen sind grob,
2. Es gibt nur wenige glaubwürdige Studien, in denen diese Maßnahmen für von professionellen Programmierern erstellten Code quantifiziert wurden
3. Es gibt nur wenige, wenn überhaupt, glaubwürdige Studien, in denen Sprachkonstruktionen oder Entwurfsmuster mit diesen Maßnahmen verknüpft sind.

Und das ignoriert die Frage, ob ein bestimmtes Objekt ein "Gott" -Objekt ist.

Bestenfalls konnten solche Studien nur eine empirische Korrelation nachweisen. Kein echter Beweis.

Was Sie eigentlich tun diskutieren das Für und Wider von „Gott“ Objekte mit Blick auf andere Völker zu ändern Meinungen ... und dann der Praxis Ihres Unternehmens.

Verwenden Sie keine Worte wie "Beweise" oder die Leute, mit denen Sie diskutieren, neigen dazu, Ihnen ins Gesicht zu lachen.

Vielleicht möchten Sie den Guru der Woche Nr. 84 sehen . Alles dreht sich um Gottobjekte (Monolithen) und wie schlecht sie sind.

Extrakt:

(Major) Es isoliert potenziell unabhängige Funktionen innerhalb einer Klasse. (Minor) Es kann davon abhalten, die Klasse mit neuen Funktionen zu erweitern.

Ich bin mir nicht sicher, ob Ihr Team wirklich am akademischen Beweis interessiert ist, dass "Gott-Objekte falsch sind".

Aus psychologischer Sicht kann Ihr Refactoring-Ansatz als Angriff auf die Teamkompetenz 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 "God Objects" zu bewältigen: Explodierende Kosten für das Hinzufügen neuer Funktionen aufgrund zunehmender Fehler, die durch Nebenwirkungen verursacht werden.

Sehr spezifisch zu sein und 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