Comment prouver ou réfuter que «les objets de Dieu» sont faux?

Résumé du problème:

En bref, j'ai hérité d'une base de code et d'une équipe de développement que je ne suis pas autorisé à remplacer et l'utilisation de God Objects est un gros problème. Pour aller de l'avant, je veux que nous reformulions les choses, mais les équipes qui veulent tout faire avec God Objects sont réticentes "parce que c'est plus facile" et cela signifie que je ne serais pas autorisé à reformuler. J’ai repoussé mes années d’expérience en matière de développement, affirmant que je suis le nouveau patron qui a été embauché pour connaître ces informations, etc. C'est demain et je veux utiliser beaucoup de munitions techniques pour défendre les meilleures pratiques car je pense que cela coûtera moins cher à long terme (et personnellement, je pense que c'est ce qui inquiète le tiers) pour l'entreprise.

Mon problème est d'ordre technique. Je sais que c'est bon à long terme, mais j'ai des problèmes avec le très court terme et le terme de 6 mois. Bien que ce soit quelque chose, je "sais", je ne peux pas le prouver avec des références et des ressources citées à l'extérieur. d'une personne (Robert C. Martin, alias Oncle Bob), car c'est ce que l'on me demande de faire, car on me dit que disposer des données d'une personne et d'une seule personne (Robert C Martin) n'est pas assez bon pour argumenter .

Question:

Quelles sont certaines des ressources que je peux citer directement (titre, année de publication, numéro de page, citation) d’experts de renom dans le domaine qui expliquent explicitement que cet usage de «Dieu» Objets / Classes / Systèmes est mauvais (ou bon, car nous recherchons pour la solution la plus techniquement valable)?

Recherches que j'ai déjà effectuées:

1. J'ai un certain nombre de livres ici et j'ai cherché dans leurs index l'utilisation des mots "objet divin" et "classe de divinité". J'ai trouvé cela curieusement, il est presque jamais utilisé et la copie du livre GoF que j'ai par exemple, ne l'utilise jamais (du moins d'après l'index devant moi), mais je l'ai trouvée dans les deux livres ci-dessous, mais j'en veux plus Je peux utiliser.
2. J'ai vérifié la page Wikipedia pour "God Object" et c'est actuellement un bout avec peu de liens de référence, donc bien que je souscrive personnellement à son propos, il n'y a pas grand chose que je puisse utiliser dans un environnement où l'expérience personnelle n'est pas considérée comme valide. Le livre cité est également considéré trop vieux pour être valable par les personnes avec lesquelles je discute de ces points techniques, car il soutient que "c'était jadis considéré comme mauvais, mais personne ne pouvait le prouver, et le logiciel moderne dit maintenant" dieu "les objets sont bons à utiliser". Personnellement, je pense que cette affirmation est incorrecte, mais je veux prouver la vérité, quelle qu’elle soit.
3. Dans «Principes, schémas et pratiques agiles en C #» de Robert C. Martin (ISBN: 0-13-185725-8, couverture rigide), où il est écrit à la page 266 «Tout le monde sait que les classes de dieux sont une mauvaise idée. Nous ne voulons pas concentrer toute l'intelligence d'un système en un seul objet ou en une seule fonction. L'un des objectifs de OOD est le partitionnement et la distribution du comportement en plusieurs classes et plusieurs fonctions. " - Et continue ensuite en disant qu'il vaut parfois mieux utiliser les classes divines de temps en temps (citant des micro-contrôleurs par exemple).
4. Dans la section "Code propre: un manuel d'artisanat agile de logiciel" de Robert C. Martin, page 136 (et seulement cette page) parle de la "classe de Dieu" et la décrit comme un exemple typique d'une violation de la règle "les classes devraient être petites" il utilise pour promouvoir le principe de responsabilité unique "à partir de la page 138.

Le problème que j'ai est que toutes mes références et citations proviennent de la même personne (Robert C. Martin) et proviennent de la même personne / source. On me dit que parce qu’il n’est qu’un seul point de vue, mon désir de ne pas utiliser les "Classes divines" est invalide et n’est pas accepté comme une pratique exemplaire standard dans l’industrie du logiciel. Est-ce vrai? Est-ce que je fais mal les choses d'un point de vue technique en essayant de suivre l'enseignement d'Oncle Bob?

Objets divins et programmation et conception orientées objet:

Plus j'y pense, plus je pense que c'est quelque chose que vous apprenez lorsque vous étudiez la POO et que cela n'est jamais explicitement appelé; C'est ma pensée qui est implicite au bon design (n'hésitez pas à me corriger, comme je veux apprendre), le problème est que je "le sais", mais que tout le monde ne le sait pas, alors dans ce cas, l'argument n'est pas valable car J'appelle effectivement cela une vérité universelle alors qu'en fait, la plupart des gens l'ignorent statistiquement, puisque statistiquement, la plupart des gens ne sont pas des programmeurs.

Conclusion:

Je ne sais pas quoi chercher pour obtenir les meilleurs résultats supplémentaires à citer, car ils ont une prétention technique et je veux connaître la vérité et pouvoir le prouver avec des citations comme un vrai ingénieur / scientifique, même si Je suis partial contre les objets divins en raison de mon expérience personnelle avec le code qui les utilisait. Toute aide ou citation serait profondément appréciée.

La justification de tout changement de pratique est établie en identifiant les points douloureux créés par la conception existante. Plus précisément, vous devez identifier ce qui est plus difficile qu’il ne devrait l’être à cause de la conception existante, ce qui est fragile, ce qui se casse maintenant, quels comportements ne peuvent pas être mis en œuvre de manière simple, en tant que résultat direct (ou même quelque peu indirect): la mise en œuvre actuelle ou, dans certains cas, les conséquences sur les performances, le temps nécessaire pour amener un nouveau membre de l’équipe à la vitesse, etc.

Deuxièmement, le code de travail l'emporte sur tout argument relatif à la théorie ou à une bonne conception. Ceci est vrai même pour les codes défectueux, malheureusement. Vous devrez donc proposer une meilleure alternative, ce qui signifie que vous, défenseur de meilleurs modèles et pratiques, devrez restructurer votre projet pour en tirer un meilleur design. Recherchez un plan étroit de style traceur dans la conception existante et implémentez une solution qui, peut-être pour une itération, permet à l'implémentation d'objet divin de fonctionner, mais reporte l'implémentation réelle à la nouvelle conception. Ensuite, écrivez du code qui tire parti de cette nouvelle conception et montrez ce que vous gagnez grâce à ce changement: performances, maintenabilité, fonctionnalités, correction des bugs ou conditions de concurrence, ou réduction de la charge cognitive du développeur.

Il est souvent difficile de trouver une surface suffisamment petite pour attaquer dans des systèmes mal architecturés. Cela peut prendre plus de temps que vous ne le souhaitez pour offrir une valeur initiale, et le gain initial peut ne pas être impressionnant pour tout le monde, mais vous pouvez également travailler pour trouver des défenseurs de votre nouvelle approche si vous vous associez à des membres de l’équipe au moins légèrement sympathiques.

Lamenting the God Object ne fonctionne que lorsque vous prêchez à la chorale. C'est un outil pour nommer un problème, qui ne fonctionne que pour le résoudre lorsque votre public réceptif est assez âgé et suffisamment motivé pour faire quelque chose. Fixer l'objet de Dieu gagne la discussion.

Étant donné que votre préoccupation immédiate semble être un engagement des dirigeants, je pense que vous feriez mieux de soutenir que le remplacement de ce code doit être un objectif stratégique et le lier aux objectifs commerciaux dont vous êtes responsable. Je pense que vous pouvez affirmer que vous pouvez fournir une orientation technique en travaillant d'abord sur un pic technique sur ce qui devrait, selon vous, être remplacé, en faisant de préférence appel à des ressources d'un ou deux techniciens qui ont des réserves sur le modèle actuel.

Je pense que vous avez trouvé suffisamment de ressources pour justifier votre argument. les personnes qui assistent à de telles réunions ne prêtent attention qu’au résumé de votre recherche et cessent d’écouter lorsque vous mentionnez deux ou trois sources corroborantes. Au départ, votre objectif devrait être de faire en sorte que le problème que vous rencontrez soit corrigé par le travail que vous rencontrez, sans nécessairement prouver que quelqu'un d'autre a tort ou que vous avez raison. C’est un problème social et non logique.

Dans un rôle de leadership technologique, vous devez lier n'importe laquelle de vos initiatives aux objectifs de l'entreprise. Par conséquent, le point le plus important pour faire valoir votre point de vue auprès des dirigeants est ce que le travail permettra d'atteindre pour atteindre ces objectifs. Parce que vous êtes également considéré comme le «nouveau type», vous ne pouvez pas simplement vous attendre à ce que les gens jettent leur travail ou à une chute rapide. vous devez créer un climat de confiance en prouvant que vous êtes en mesure de livrer. En tant que préoccupation à long terme, dans un rôle de leadership, vous devez également apprendre à vous concentrer sur les résultats, sans nécessairement être attaché aux détails du résultat. Vous êtes maintenant là pour fournir une orientation stratégique, éliminer les obstacles tactiques du progrès de votre équipe et offrir à votre équipe le mentorat, sans gagner de batailles de crédibilité avec les membres de votre propre équipe.

Prendre une décision de haut en bas sera rarement crédible, sauf si vous avez un peu de peau dans le jeu; Si vous vous retrouvez dans une situation similaire, vous devriez vous concentrer davantage sur la recherche d'un consensus au sein de votre organisation plutôt que sur une escalade lorsque vous estimez que la situation est incontrôlable.

Mais compte tenu de votre situation actuelle, je dirais que votre meilleur choix est de faire valoir que votre approche apportera des avantages mesurables à long terme en fonction de votre expérience et que cela va dans le sens du travail accompli par des praticiens renommés tels que oncle Bob et autres. et que vous aimeriez consacrer quelques jours / semaines à l’exemple d’un refactoring étroit de l’aspect le plus rentable, afin de démontrer à quoi devrait ressembler votre conception d’un bon design. Cependant, vous devrez aligner tout votre cas sur des objectifs commerciaux spécifiques, au-delà de vos préférences personnelles.

Tout d’abord, vous devez indiquer que toute organisation mesurable doit adopter les meilleures pratiques de l’industrie. Dire que "ça marche pour nous!" ne peut être mesurée, ni dans le temps ni dans les ressources, car elle est simplement imprévisible. Le génie logiciel est une science au même titre que n'importe quel autre domaine scientifique et ces concepts ont été étudiés, recherchés, testés et documentés.

1. l' objet de Dieu est un anti-modèle qui stipule que

   En génie logiciel, un anti-modèle (ou anti-modèle) est un modèle utilisé dans les opérations sociales ou commerciales ou le génie logiciel qui peut être couramment utilisé mais qui est inefficace et / ou contre-productif dans la pratique.

2. Lors de la conférence Google IO de 2009 , ce sujet a été partiellement expliqué lorsque le modèle MVP a été expliqué. Cela peut ne pas être pertinent pour l'objet divin, mais peut vous donner des munitions.

3. En outre, l'utilisation de cet anti-motif enfreint le principe de responsabilité unique dans les conceptions orientées objet, selon laquelle:

   chaque classe devrait avoir une responsabilité unique, et cette responsabilité devrait être entièrement encapsulée par la classe. Tous ses services devraient être étroitement liés à cette responsabilité.

4. Le blog Decaying Code parle également de cela et de sa solution.

5. Nous ne pouvons pas parler du principe de responsabilité unique sans parler du couplage d’ objets .

   [...] le couplage ou la dépendance est le degré auquel chaque module de programme s'appuie sur chacun des autres modules.

   Lorsque le fait d'avoir un système étroitement couplé peut entraîner assembly of modules [to] require more effort and/or time [to maintain] due to the increased inter-module dependency.un niveau élevé d'attaque d'objet signifie moins de cohésion, et inversement. Les objets divins sont un bon exemple de couplage étroit car ils en savent plus qu'ils ne devraient, ce qui les surcharge de responsabilité et limite donc considérablement la possibilité de réutilisation du code.

6. Lors de la conception d’une application complexe, la simplicité doit venir à l’esprit. Les gros problèmes doivent être décomposés en problèmes plus petits, plus faciles à gérer, à tester et à documenter. Cela est particulièrement vrai dans un paradigme orienté objet.

   Avec cet argument, nous revenons à l'argument anti-modèle, mais ce paradigme concerne uniquement les modèles, la représentation d'objets dans le monde réel et, ultimement, l'encapsulation de données.

7. Vous avez raison de dire que ces "bonnes pratiques" sont plus présentes dans les salles de classe. Cependant, j'ai des expériences d'enseignement au collège (et à certaines universités) et je n'ai vu que ces principes être enseignés dans les universités, en particulier dans les facultés d'ingénierie. Ce qui est triste. Mais comme pour toute bonne pratique, ceux qui s’efforcent de s’améliorer apprennent généralement quelques modèles de conception de base et finissent par comprendre comment jongler entre couplage et cohésion.

   Ce que j’enseigne habituellement aux étudiants, c’est qu’il peut sembler exiger plus d’efforts pour adopter de bonnes normes de programmation, mais cela porte toujours ses fruits à long terme. Un bon exemple serait quelqu'un qui demande à un programmeur d'écrire une fonction de tri. Le programmeur a deux choix; 1) écrivez une fonction de tri à bulle rapide (moins de 5 minutes) qui ne sera pas durable à mesure que la liste d'éléments s'allonge, ou 2) écrivez un algorithme de tri plus complexe (aka optimisé) (tri rapide, etc.) qui sera mieux dimensionné avec de plus grandes listes.

Oh, j'y vais, en train de poser une autre vieille question, mais je vais deviner que vous n'avez pas gagné cet argument et voici pourquoi.

Cela ressemble à un problème de culture

Vous êtes leur responsable mais vous ne pouvez pas les remplacer et vous devez vous adresser à vos responsables afin de les amener à faire ce que vous croyez qu'ils devraient faire, ce qui dans ce cas, je suppose, consiste au moins à y renoncer avec dieu. les objets avancent. Cela me semble être un cas classique de code reflétant la culture dans laquelle il est né. En d'autres termes, l'objet divin est le fonctionnement de cette société. Voulez-vous faire tout type de changement significatif? En fin de compte, vous allez toujours au même endroit car toutes les décisions doivent apparemment être annulées en haut.

Ayant été au courant de plusieurs tentatives infructueuses de nettoyage de code hérité et de modifications de la politique de code, je suis maintenant convaincu qu'il est impossible de lutter contre la culture qui a rendu le code possible dès lors que cette culture est encore fermement ancrée ou à tout le moins la culture est une tâche ardue qui fait qu'il est peu probable que quelqu'un puisse me payer assez ou me donner assez de pouvoir pour avoir l'impression que c'était une entreprise utile qui allait probablement réussir à nouveau.

Avant qu'il y ait un changement, ils doivent être motivés et malheureusement, en tant que programmeurs qui lisent assez pour lire Stack, il nous est parfois difficile de comprendre que tout le monde n'est pas motivé par les mêmes choses. J'ai gagné beaucoup d'arguments rationnels dans mes expériences mais au bout du compte, la société souffre intellectuellement de fainéants intellectuels pour une raison.

Peut-être que les entreprises ont été motivées à ne penser qu'à demain plutôt qu'à la semaine prochaine ou dans cinq ans (un scénario particulièrement frustrant lorsque vous êtes l'enfant d'immigrés d'un pays qui a construit un caveau à semences dans l'Arctique en cas d'apocalypse). Peut-être qu'ils ont peur du changement. Ils attachent peut-être une trop grande importance à l’ancienneté au point que la chaîne de commandement n’a plus de sens, même s’ils doivent embaucher de l’extérieur pour recruter un chef d’équipe de développement, car ils reconnaissent que personne dans leur équipe n’a suffisamment grandi avec le temps là-bas (ou parce que ces condamnés à perpétuité ne veulent pas le risque associé à la responsabilité). Ou, et j'ai vu cela, c'est peut-être le phénomène très réel et déprimant de la médiocrité qui se défend parce qu'elle sait au fond d'elle-même qu'elle peut '

Comment combattez-vous des problèmes qui sont finalement ancrés dans la peur ou des métriques brisées pour réussir? Je vais vous dire ceci, cela prend beaucoup plus que même une équipe de développement dévouée et de qualité et vous en aviez bien moins que le son au moment où ce Q a été posté.

Dans le cas non impossible que ce ne soit pas un problème de culture insoluble ...

Maintenant, en supposant que les personnes au sommet soient très réceptives au changement et qu’elles soient réellement disposées à vous faire confiance, il vous suffit de ponctuer tous vos arguments avec de l’argent et des occasions manquées.

Chaque fois que cela prend plus de temps pour former une nouvelle personne sur ce code base ridicule, chaque fois qu'il faut plus de temps pour modifier ou ajouter une nouvelle fonctionnalité à quelque chose, chaque fois qu'il devient extrêmement difficile d'exposer des points de terminaison à un autre système d'une société avec laquelle vous souhaitez établir un partenariat. , cela coûte de l’argent. Beaucoup d'argent freaking. Plus important encore, cela laisse une fenêtre ouverte à un concurrent plus agile et plus agile, qui vous met dans une position où vous ne pouvez que réagir, mais trop lentement, pour finalement vous arracher tout cela à vous.

Il suffit de reconnaître qu’une culture particulièrement obstinée et stupide maintiendra le statu quo à tout prix, même si le toit physique de la société s’enflamme à cause de cela.

Vous pouvez citer certains des principes de base de la programmation orientée objet les plus élémentaires, tels que le couplage lâche et la cohésion élevée. Un "objet divin" sonne comme un couple de classes sans rapport et une faible cohésion.

Vous pouvez toujours demander à oncle Bob lui-même.

Le problème, c’est tellement évident pour les gens qui ont l’impression qu’une fois qu’il est énoncé, il n’a pas besoin d’être référencé par une multitude d’auteurs. Il ne doit y avoir qu'une seule source.

Les autres termes avec lesquels vous voudrez peut-être commencer lors de la recherche de sources sont:

• SOLIDE
• Loi de Demeter
• Grosse boule de boue

Tous ces concepts expriment des concepts susceptibles de générer des sources de référence viables, même s'ils ne le nomment pas en tant que tel.

En fin de compte, vous êtes le patron. La raison en est que vous le dites, et bien que pour être considéré comme un bon gestionnaire, vous devez être prêt à justifier vos décisions. vous l'avez fait, et s'il y a encore de la résistance, la ligne de conduite à suivre est que votre équipe agisse comme il le lui dit.

Comment prouver ou réfuter que les objets «dieu» sont faux?

Vous ne pouvez pas.

Ce type de conjecture n'est pas sujet à la preuve mathématique, et la preuve mathématique est le seul type de preuve qui soit valable.

Même si vous essayez de remplacer le mot émotionnel "faux" par des mesures quantifiables des effets de l'utilisation d'objets divins, vous constaterez que:

1. les mesures disponibles sont brutes,
2. il existe peu d'études crédibles où ces mesures ont été quantifiées pour du code produit par des programmeurs professionnels
3. il existe peu ou pas d'études crédibles où des constructions de langage ou des modèles (anti) de conception ont été liés à ces mesures.

Et c'est ignorer la question de décider quand un objet particulier est un objet "dieu".

Au mieux, ces types d’études ne pourraient démontrer qu’une corrélation empirique. Pas une preuve authentique.

Ce que vous êtes en train de faire, c'est de débattre du pour et du contre des objets "divins" en vue de changer les opinions des autres ... et ensuite la pratique de votre organisation.

N'utilisez pas de mots tels que "preuve" ou les personnes avec lesquelles vous discutez risquent de vous faire rire.

Vous voudrez peut-être voir le gourou de la semaine n ° 84 . Tout tourne autour des objets divins (monolithes) et de la façon dont ils sont mauvais.

Extrait:

(Majeure) Elle isole des fonctionnalités potentiellement indépendantes au sein d'une classe [...] (Mineure). Elle peut décourager l'extension de la classe avec de nouvelles fonctionnalités [...]

Je ne suis pas sûr si votre équipe est vraiment intéressée par la preuve académique que "les objets de Dieu ont tort".

D’un point de vue psychologique, votre approche de refactoring peut être mal comprise comme s’attaquer à la compétence de l’équipe: «L’équipe a fait un mauvais travail» même si le programme fonctionne comme prévu.

Ce que vous voulez vraiment faire, c'est gérer les effets secondaires négatifs du "code spagetti" et des "objets divins": exploser les coûts pour ajouter de nouvelles fonctionnalités en raison de l'augmentation des bugs causés par les effets secondaires.

Il peut être plus utile d’être très spécifique et de poser des questions au lieu de fournir des réponses:

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