Comment puis-je prouver ou infirmer que les "objets de Dieu" sont faux?
Résumé du problème:
Pour faire court, 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. À l'avenir, je veux que nous refacturions les choses, mais je reçois un push-back des équipes qui veulent tout faire avec God Objects "parce que c'est plus facile" et cela signifie que je ne serais pas autorisé à refactoriser. J'ai repoussé en citant mes années d'expérience en développement, que je suis le nouveau patron qui a été embauché pour connaître ces choses, etc., tout comme le représentant commercial des sociétés offshore tierces, et c'est maintenant au niveau de la direction et de ma réunion est demain et je veux aller avec beaucoup de munitions techniques pour promouvoir les meilleures pratiques parce que je pense que ce sera moins cher à long terme (et je pense personnellement que c'est ce qui inquiète le tiers) pour l'entreprise.
Mon problème vient d'un niveau technique, je connais son bon long terme mais j'ai des problèmes avec le ultra court terme et le terme de 6 mois, et alors que c'est quelque chose que 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 m'a dit avoir des données d'une seule personne et qu'une seule personne (Robert C Martin) n'est pas un argument suffisant .
Question:
Quelles sont les ressources que je peux citer directement (titre, année de publication, numéro de page, citation) par des experts bien connus dans le domaine qui disent explicitement que cette utilisation des objets/classes/systèmes "Dieu" est mauvaise (ou bonne, car nous cherchons pour la solution la plus techniquement valable)?
Recherche que j'ai déjà effectuée:
- J'ai un certain nombre de livres ici et j'ai cherché dans leurs index l'utilisation des mots "objet dieu" et "classe dieu". J'ai trouvé que bizarrement ce n'est presque jamais utilisé et la copie du livre du GoF que j'ai par exemple, ne l'utilise jamais (au moins selon l'index en face de moi) mais je l'ai trouvé dans les deux livres ci-dessous, mais je veux plus Je peux utiliser.
- J'ai vérifié le page Wikipedia pour "God Object" et c'est actuellement un talon avec peu de liens de référence donc bien que je suis personnellement d'accord avec cela, il n'a pas grand-chose que je puisse utiliser dans un environnement où personnel l'expérience n'est pas considérée comme valide. Le livre cité est également considéré comme trop ancien pour être valide par les personnes avec qui je discute de ces points techniques, car l'argument qu'ils avancent est que "on pensait autrefois qu'il était mauvais, mais personne ne pouvait le prouver, et maintenant un logiciel moderne dit" Dieu "les objets sont bons à utiliser". Je crois personnellement que cette déclaration est incorrecte, mais je veux prouver la vérité, quelle qu'elle soit.
- Dans "Agile Principles, Patterns, and Practices in C #" de Robert C Martin (ISBN: 0-13-185725-8, couverture rigide) où à la page 266 il est écrit "Tout le monde sait que les classes divines sont une mauvaise idée. Nous ne voulons pas de concentrer toute l'intelligence d'un système en un seul objet ou une seule fonction. L'un des objectifs de l'OOD est de partitionner et de répartir les comportements en plusieurs classes et plusieurs fonctions. " - Et puis continue de dire parfois qu'il vaut mieux utiliser God Classes de toute façon parfois (citant les micro-contrôleurs comme exemple).
- Dans la page 136 (et seulement cette page) de Robert C Martin "Clean Code: A Handbook of Agile Software Craftsmanship" (et seulement cette page) parle de la "classe Dieu" et l'appelle comme un excellent exemple 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 toutes mes références et citations proviennent de la même personne (Robert C. Martin), et sont de la même personne/source. On me dit que parce qu'il n'est qu'un point de vue, mon désir de ne pas utiliser "God Classes" est invalide et n'est pas accepté comme une meilleure pratique standard dans l'industrie du logiciel. Est-ce vrai? Suis-je en train de mal faire les choses d'un point de vue technique en essayant de m'en tenir à l'enseignement de l'oncle Bob?
Objets divins et programmation et conception orientées objet:
Plus j'y pense, plus je pense que c'est plus quelque chose que vous apprenez lorsque vous étudiez OOP et ce n'est jamais explicitement appelé; Son implicite à une bonne conception est ma pensée (N'hésitez pas à me corriger , s'il vous plaît, comme je veux apprendre), le problème est que je "sais" cela, mais pas tout le monde, donc dans ce cas ce n'est pas considéré comme un argument valable parce que je l'appelle effectivement comme vérité universelle alors qu'en fait la plupart des gens l'ignorent statistiquement car statistiquement la plupart des gens ne sont pas des programmeurs.
Conclusion:
Je ne sais pas quoi rechercher pour obtenir les meilleurs résultats supplémentaires à citer, car ils font une affirmation 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 partisan des objets divins en raison de mon expérience personnelle avec le code qui les a utilisés. Toute aide ou citation serait profondément appréciée.
La justification de tout changement de pratique se fait 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 en raison de la conception existante, ce qui est fragile, ce qui se brise 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) de l'implémentation actuelle, ou, dans certains cas, comment les performances en souffrent, combien de temps il faut pour mettre un nouveau membre de l'équipe au courant, etc.
Deuxièmement, le code de travail l'emporte sur tous les arguments concernant la théorie ou une bonne conception. Cela est vrai même pour le mauvais code, malheureusement. Vous devrez donc fournir une meilleure alternative, ce qui signifie que vous, en tant que défenseur de meilleurs modèles et pratiques, devrez refactoriser pour trouver un meilleur design. Trouvez un plan de style étroit, de type traceur à travers la conception existante et implémentez une solution qui, peut-être, pour l'itération une, maintient l'implémentation de l'objet divin en fonctionnement, 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, que ce soit les performances, la maintenabilité, les fonctionnalités, la correction des bogues ou des conditions de concurrence, ou la réduction de la charge cognitive pour le 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 fournir une valeur initiale, et le gain initial peut ne pas être aussi impressionnant pour tout le monde, mais vous pouvez également travailler sur la recherche de défenseurs de votre nouvelle approche si vous vous y associez avec des membres de l'équipe qui sont au moins légèrement sympathiques.
Déplorer l'objet divin ne fonctionne que lorsque vous prêchez au chœur. C'est un outil pour nommer un problème, et ne fonctionne pour le résoudre que si vous avez un public réceptif qui est assez âgé et suffisamment motivé pour faire quelque chose. La fixation de l'objet Dieu gagne l'argument.
Étant donné que votre préoccupation immédiate semble être l'adhésion des dirigeants, je pense que vous feriez mieux de démontrer 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 faire valoir que vous pouvez fournir une direction technique en travaillant d'abord sur un pic technique sur ce que vous pensez qu'il faudrait faire pour le remplacer, en impliquant de préférence des ressources d'une ou deux personnes techniques qui ont des réserves sur la conception actuelle.
Je pense que vous avez trouvé suffisamment de ressources pour justifier votre argument; les personnes participant à de telles réunions ne prêteront attention qu'au résumé de vos recherches et cesseront d'écouter une fois que vous aurez mentionné deux ou trois sources corroborantes. Votre objectif initial devrait être de faire en sorte que le rachat résout le problème que vous voyez, sans nécessairement prouver que quelqu'un d'autre a tort ou que vous avez raison. C'est un problème social, pas logique.
Dans un rôle de leader technologique, vous devez lier n'importe laquelle de vos initiatives à des objectifs commerciaux, donc la chose la plus importante pour faire valoir vos arguments auprès des dirigeants est ce que le travail fera pour atteindre ces objectifs. Parce que vous êtes également considéré comme le "nouveau gars", vous ne pouvez pas vous attendre à ce que les gens jettent leur travail ou s'attendent à tomber rapidement dans la file; vous devez établir une certaine confiance en prouvant que vous pouvez livrer. En tant que préoccupation à long terme, dans un rôle de leadership, vous devez également apprendre à vous concentrer sur les résultats, mais pas nécessairement être attaché aux détails du résultat. Vous êtes maintenant là pour fournir une orientation stratégique, éliminer les obstacles tactiques aux progrès de votre équipe et offrir à votre équipe un mentorat, et non gagner des batailles de crédibilité avec les membres de votre équipe.
Prendre une décision descendante sera rarement crédible à moins que vous ayez un peu de peau dans le jeu; Si vous êtes à nouveau 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 une fois que vous sentez que la situation est hors de contrôle.
Mais compte tenu de votre situation actuelle, je dirais que votre meilleur pari est de faire valoir que votre approche apportera des avantages mesurables à long terme en fonction de votre expérience et qu'elle est conforme au travail de praticiens bien connus comme l'oncle Bob et ses collègues. , et que vous aimeriez passer quelques jours/semaines à donner l'exemple sur une refactorisation étroite de l'aspect rapport qualité-prix le plus élevé, pour montrer à quoi devrait ressembler votre vision d'un bon design. Cependant, vous devrez aligner votre cas sur des objectifs commerciaux spécifiques au-delà de vos préférences personnelles.
Tout d'abord, vous devez présenter que toute organisation mesurable doit adopter les meilleures pratiques de l'industrie. Dire que "ça marche juste pour nous!" ne peut être mesurée, ni dans le temps ni dans les ressources, car elle est tout simplement imprévisible. Le génie logiciel est une science autant que tout autre domaine scientifique, et ces concepts ont été étudiés, recherchés, testés et documentés.
le God Object est un anti-pattern qui déclare 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.
Dans la Google IO de 2009 , ce sujet a été partiellement expliqué lorsque le modèle MVP a été expliqué. Il peut ne pas être pertinent pour l'objet divin, mais peut vous donner des munitions.
En outre, l'utilisation de cet anti-modèle viole le principe de responsabilité unique dans les conceptions orientées objet, qui stipule que:
chaque classe devrait avoir une seule responsabilité, et cette responsabilité devrait être entièrement encapsulée par la classe. Tous ses services devraient être étroitement alignés sur cette responsabilité.
Le blog Decaying Code parle également de cela et de sa solution.
On ne peut pas parler du principe de responsabilité unique sans parler d'objet couplage .
[...] couplage ou 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 plus élevé de coupage d'objet signifie moins de cohésion, et vice versa. 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és, limitant ainsi considérablement la réutilisation du code.Lors de la conception d'une application complexe, simplicité doit venir à l'esprit. Les gros problèmes doivent être décomposés en plus petits, qui sont 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 les modèles, la représentation des objets du monde réel et, ultimement, l'encapsulation des données.
Vous avez raison quand vous dites 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 dans certaines universités) et je n'ai vu que ces principes enseignés dans les universités, en particulier dans les facultés d'ingénierie. C'est triste. Mais comme toute bonne pratique, ceux qui s'efforcent de s'améliorer apprennent généralement quelques modèles de conception , et finissent par comprendre comment passer du couplage à la cohésion.
Ce que j'enseigne habituellement aux étudiants, c'est que cela peut sembler exiger plus d'efforts pour adopter de bonnes normes de programmation, mais cela toujours porter ses fruits à long terme. Un bon exemple serait quelqu'un demandant à un programmeur d'écrire une fonction de tri. Le programmeur a deux choix; 1) écrire une fonction de tri rapide des bulles (moins de 5 minutes) qui ne sera pas viable à mesure que la liste des éléments s'allonge, ou 2) écrire un algorithme de tri plus complexe (aka optimisé) (tri rapide, etc.) qui évoluera mieux avec de plus grandes listes.
Oh là je vais, nécrosant 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 manager mais vous ne pouvez pas les remplacer et vous devez aller voir vos managers pour les amener à faire ce que vous pensez qu'ils devraient faire, ce qui dans ce cas, je suppose, c'est au moins de le faire tomber avec le dieu des objets qui 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 entreprise. Voulez-vous apporter toute sorte de changement significatif? Vous allez toujours au même endroit en fin de compte, car toutes les décisions doivent apparemment être approuvées au sommet.
Ayant été au courant de plusieurs tentatives infructueuses de nettoyage de code hérité et de changements de politique de code, je suis maintenant d'avis que vous ne pouvez pas lutter contre la culture qui a rendu le code possible en premier lieu lorsque cette culture est encore fermement ancrée ou à tout le moins, se battre La culture est un slog très difficile à monter, il est peu probable que quelqu'un puisse me payer suffisamment ou me donner assez de pouvoir pour me sentir comme si c'était une entreprise valable qui allait probablement réussir à nouveau.
Avant qu'il ne puisse y avoir de changement, ils doivent être motivés à changer et, malheureusement, en tant que programmeurs qui se foutent de lire Stack à l'occasion, il est difficile pour nous 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 à la fin de la journée, la société souffre de développeurs intellectuellement paresseux 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'immigrants d'un pays qui a construit une chambre forte de semences dans l'Arctique en cas d'apocalypse). Ils ont peut-être peur du changement. Peut-être apprécient-ils trop l'ancienneté au point que la chaîne de commandement n'a pas de sens même lorsqu'ils doivent embaucher de l'extérieur pour recruter un chef d'équipe ou un gestionnaire de développement, car ils reconnaissent que personne dans leur équipe permanente n'a suffisamment grandi dans leur temps là (ou parce que les condamnés à perpétuité ne veulent pas du risque associé à la responsabilité). Ou, et je l'ai vu, 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'il sait au fond de lui qu'il ne peut pas rivaliser avec la qualité et quand il y a assez de tromperie pour contourner, il est impossible de comprendre à qui s'adresser. blâmer quand tout va régulièrement en morceaux.
Comment combattez-vous les problèmes qui sont finalement enracinés dans la peur ou les mesures brisées pour réussir? Je vais vous dire ceci, cela prend beaucoup plus que même une équipe de développeurs de qualité engagée et vous en aviez beaucoup moins que le son au moment où ce Q a été publié.
Dans l'événement pas impossible que ce n'est pas un problème de culture insoluble ...
Maintenant, en supposant que les personnes au sommet sont très réceptives au changement et qu'elles sont réellement prêtes à vous faire confiance pour le faire, vous n'avez vraiment qu'à ponctuer tous vos arguments avec de l'argent et des opportunités perdues.
Chaque fois que cela prend plus de temps pour former une nouvelle personne à cette base de code ridicule, chaque fois que cela prend 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 entreprise avec laquelle vous souhaitez vous associer , cela coûte de l'argent. Beaucoup d'argent flippant. Plus important encore, cela laisse une fenêtre ouverte à un concurrent plus petit et plus agile, vous met dans une position où tout ce que vous pouvez faire est de réagir trop lentement et, finalement, de vous l'arracher.
Il suffit de reconnaître qu'une culture particulièrement têtue et stupide maintiendra à tout prix le statu quo, même si le toit physique de l'entreprise est en fait en feu à cause de cela.
Vous pourriez citer certains des principes les plus élémentaires OOP tels que le couplage lâche et la cohésion élevée. Un "objet divin" sonne comme s'il couple des classes indépendantes et a une faible cohésion.
Vous pouvez toujours demander à l'oncle Bob lui-même.
Le truc, c'est que c'est tellement évident pour les gens qui ont du sens qu'une fois qu'il est énoncé, il n'a pas besoin d'être re-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:
- SOLID
- Loi de Déméter
- Grande boule de boue
Tous ces concepts expriment des concepts connexes qui pourraient fournir des sources de référence viables, même s'ils ne le nomment pas réellement comme tel.
En fin de compte, vous êtes le patron. La raison de cela est parce que vous le dites, et bien que pour être considéré comme un bon gestionnaire, vous devez vraiment être prêt à justifier vos décisions; vous l'avez fait, et s'il y a toujours de la résistance, la bonne ligne de conduite est que votre équipe fasse ce qu'on lui dit.
Comment puis-je prouver ou infirmer que les objets "dieu" sont faux?
Vous ne pouvez pas.
Ce type de conjecture ne se prête pas à la preuve mathématique, et la preuve mathématique est le seul type de preuve qui soit solide.
Même si vous essayez de remplacer le mot émotif "faux" par des mesures quantifiables des effets de l'utilisation d'objets divins, vous constaterez que:
- les mesures disponibles sont brutes,
- il y a peu d'études crédibles où ces mesures ont été quantifiées pour le code produit par des programmeurs professionnels
- il y a peu ou pas d'études crédibles où les constructions ou les modèles (anti-) linguistiques 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 pouvaient que démontrer une corrélation empirique. Pas une preuve authentique.
Ce que vous faites en réalité, c'est débattre les avantages et les inconvénients des objets "dieu" en vue de changer les autres peuples opinions ... puis la pratique de votre organisation.
N'utilisez pas de mots comme "preuve" ou les personnes avec qui vous discutez sont susceptibles de vous rire au nez.
Vous voudrez peut-être voir gourou de la semaine # 84 . Tout tourne autour des objets divins (monolithes) et comment ils sont mauvais.
Extrait:
(Majeur) Il isole des fonctionnalités potentiellement indépendantes à l'intérieur d'une classe [...] (Mineur) Il 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 sont faux".
D'un point de vue psychologique, votre approche de refactoring peut être interprétée à tort comme une attaque à la compétence de l'équipe: "l'équipe a fait du mauvais travail" bien que le programme fonctionne comme prévu.
Ce que vous voulez vraiment faire, c'est faire face aux 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 bogues causés par les effets secondaires.
Être très précis et poser des questions au lieu de fournir des réponses peut être plus utile:
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