Résumé du problème:

En bref, jai hérité dune base de code et dune équipe de développement que je nai pas le droit de remplacer et lutilisation de God Objects est un gros problème. À lavenir, je veux que nous re-factorisons les choses mais je reçois du recul de la part des équipes qui veulent tout faire avec God Objects « parce que cest plus facile » et cela signifie que je ne serais pas autorisé à re-factoriser. Jai repoussé en citant mes années dexpérience dans le développement, que je suis le nouveau patron qui a été embauché pour savoir ces choses, etc., tout comme le représentant des ventes des comptes des sociétés offshore tierces, et cest maintenant au niveau exécutif et à ma réunion Cest demain et je veux entrer avec beaucoup de munitions techniques pour préconiser les meilleures pratiques car je pense que ce sera moins cher à long terme (et je pense personnellement que cest ce qui inquiète le tiers) pour lentreprise.

Mon problème est dordre technique, je sais que cest bon à long terme mais jai des problèmes avec lultra court terme et le terme 6 mois, et bien que ce soit quelque chose que je « sais » je ne peux pas le prouver avec des références et des ressources citées en dehors dune personne (Robert C. Martin, alias Oncle Bob), car cest ce que lon me demande de faire, comme on ma dit que le fait davoir des données dune personne et dune seule personne (Robert C Martin) nest pas un argument assez bon.

Question:

Que sont som 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 recherchons le solution la plus techniquement valide)?

Recherche que jai déjà effectuée:

  1. Jai un certain nombre de livres ici et jai recherché dans leurs index lutilisation des mots « objet de Dieu » et « classe de Dieu ». Jai trouvé que bizarrement il nest presque jamais utilisé et que la copie du livre GoF que jai par exemple ne lutilise jamais (du moins selon lindex devant moi) mais je lai trouvé dans les deux livres ci-dessous, mais je veux plus Je peux utiliser.
  2. Jai vérifié la page Wikipédia pour « God Object » et cest actuellement un talon avec de petits liens de référence, bien que personnellement daccord avec ce quil dit, il na pas grand-chose que je puisse utiliser dans un environnement où lexpérience personnelle nest pas considérée comme valide. Le livre cité est également considéré comme trop vieux pour être valide par les personnes avec lesquelles je débat de ces points techniques comme argument ils font que « on pensait autrefois que cétait mauvais mais personne ne pouvait le prouver, et maintenant les logiciels modernes disent que les objets » dieu « sont bons à utiliser ». Personnellement, je pense que cette affirmation est incorrecte, mais je veux prouver la vérité , quoi que ce soit.
  3. Dans «Principes, modèles et pratiques Agile en C #» de Robert C Martin (ISBN: 0-13-185725-8, relié) whe À la page 266, il est dit: «Tout le monde sait que les classes divines sont une mauvaise idée. Nous ne voulons pas concentrer toute lintelligence dun système dans un seul objet ou une seule fonction. Lun des objectifs de lOOD est le partitionnement et la distribution du comportement en plusieurs classes et plusieurs fonctions. – Et puis continue en disant quil est parfois préférable dutiliser les classes de Dieu de toute façon parfois (citant les micro-contrôleurs comme exemple).
  4. Dans le code propre de Robert C Martin: un manuel de lartisanat logiciel agile « page 136 (et seulement cette page) parle de la » classe de Dieu « et lappelle comme un excellent exemple de violation de la règle » les classes devraient être petites « quil utilise pour promouvoir le principe de responsabilité unique » à partir de la page 138 .

Le problème que jai, cest 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 quil nest quun point de vue, mon désir de ne pas utiliser les «classes divines» est invalide et nest pas accepté comme une meilleure pratique standard dans lindustrie du logiciel. Est-ce vrai? Est-ce que je fais les choses mal dun point de vue technique en essayant de men tenir à lenseignement de loncle Bob?

Objets de Dieu et programmation et conception orientées objet:

Plus je pense à cela, plus je pense que cest quelque chose que vous apprenez lorsque vous étudiez la POO et que cela nest jamais explicitement appelé; cest implicite à bon le design est ma pensée (nhésitez pas à me corriger, sil 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 nest pas considéré comme un argument valable car jappelle effectivement cest une vérité universelle alors quen fait la plupart des gens lignorent statistiquement puisque 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 véritable ingénieur / scientifique, même si je suis biaisé contre les objets divins en raison de mon expérience avec le code qui les a utilisés. Toute aide ou citation serait vivement appréciée.

Commentaires

  • Demandez-leur une documentation sur les objets de Dieu comme bonne pratique.
  • Fuyez! Vous ‘ ne voulez pas y travailler.
  • Veuillez définir votre compréhension de  » Objet de Dieu  » et comment cela se rapporte à votre question. Vous passez 4 paragraphes à dire que la classe de Dieu nest ‘ t un terme standard dans la littérature. Alors pourquoi lutilisez-vous? Si vous utilisez les termes standard de lindustrie et que vous pouvez montrer comment ces concepts sappliquent à votre projet actuel, vous pourriez convaincre certaines personnes de votre point de vue. Utiliser des mots inventés lors dune réunion daffaires ne fera que saper votre argument. Les termes standards de lindustrie existent – vous nêtes ‘ pas la première personne à voir un cauchemar tout-est-global ou mono-objet, ou tout ce que vous essayez de décrire.
  • Il vous ‘ manque le terme  » antipattern « . Une recherche Google sur  » god object antipattern  » renvoie tonnes de pages sur les raisons pour lesquelles elles ‘ cest mauvais.
  • Vous ne devriez pas ‘ attaquer lobjet divin mais les problèmes quil crée. Comme: nous avons un couplage très étroit entre tout et un changement dans A nécessite également des changements dans B, C et D. Donc, pour éviter cela, nous ‘ allons extraire des classes. Ou: nous voulons que le code soit dans un cadre de test, et nous pouvons ‘ faire cela, quallons-nous faire? Essayez également déviter dutiliser le terme  » Dieu « , les gens qui ne sont pas réceptifs penseront que vous ‘ utilisez des hyperboles.

Réponse

Le cas de tout changement de pratique est fait en identifiant les points douloureux créé par la conception existante. Plus précisément, vous devez identifier ce qui est plus difficile quil 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 limplémentation actuelle, ou, dans certains cas, la façon dont les performances en souffrent, le temps nécessaire pour mettre un nouveau membre de léquipe au courant, etc.

Deuxièmement, le code de travail lemporte sur tout argument concernant la théorie ou la bonne conception Cela est vrai même pour le mauvais code, malheureusement. Vous allez donc devoir fournir une meilleure alternative, ce qui signifie que vous, en tant que défenseur de meilleurs modèles et pratiques, devrez refactoriser pour créer un meilleur design. Trouvez un plan étroit de style traceur à travers la conception existante et implémentez une solution qui, peut-être, pour la première itération, permet à limplémentation de lobjet divin de fonctionner, mais reporte la mise en œuvre 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, quil sagisse de performances, de maintenabilité, de fonctionnalités, de correction de bogues ou de conditions de concurrence, ou de 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 souhaiteriez pour fournir une valeur initiale, et le gain initial peut ne pas être si impressionnant à tout le monde, mais vous pouvez également travailler pour trouver des défenseurs de votre nouvelle approche si vous vous associez avec des membres de l’équipe qui sont au moins légèrement sympathiques.

Lamenting the God Object ne fonctionne que lorsque vous «prêchez à le choeur. C « est un outil pour nommer un problème, et ne fonctionne pour le résoudre que lorsque vous avez un public réceptif, suffisamment expérimenté et motivé pour faire quelque chose. Fixer l » objet Dieu gagne l « argument.

Étant donné que votre préoccupation immédiate semble être ladhésion de la direction, je pense que vous feriez mieux de faire valoir que le remplacement de ce code doit être un objectif stratégique et de les lier aux objectifs commerciaux dont vous êtes responsable. Je pense que vous peut faire valoir que vous pouvez fournir une direction technique en travaillant dabord sur un pic technique sur ce que vous pensez quil faudrait faire pour le remplacer, de préférence en impliquant des ressources dune 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 participants à de telles réunions ne porteront attention quau résumé de votre recherche, et ils cesseront découter après que vous ayez mentionné deux ou trois sources corroborantes.Votre objectif initial devrait être de faire en sorte que le problème soit résolu, sans nécessairement prouver que quelquun a tort ou que vous avez raison. Cest un problème social, pas logique.

Dans un rôle de leadership technologique, vous devez lier lune de vos initiatives à des objectifs commerciaux, donc la chose la plus importante pour faire valoir votre cas auprès des dirigeants est ce le travail fera pour 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 sattendent à 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 spécificités du résultat. Vous êtes maintenant là pour fournir une direction stratégique, éliminer les obstacles tactiques à la progression de votre équipe et offrir un mentorat à votre équipe, et non gagner des batailles de crédibilité avec les membres de votre propre équipe.

Prendre une décision descendante sera être rarement crédible à moins davoir un peu de peau dans le jeu; si vous êtes à nouveau dans une situation similaire, vous devriez vous concentrer davantage sur la recherche dun 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 basés sur votre expérience et quelle est conforme au travail de praticiens bien connus comme oncle Bob and co., et que vous « aimeriez passer quelques jours / semaines à montrer lexemple sur une refactorisation étroite du meilleur rapport qualité-prix, pour montrer à quoi devrait ressembler votre vision dun bon design. Vous devrez toutefois aligner votre cas sur des objectifs commerciaux spécifiques au-delà de vos préférences personnelles.

Commentaires

  • Bon point à propos de problème social. Ce doit être la raison pour laquelle il y a tant de mauvais code écrit et des applications mal conçues.
  • +1 pour lassocier avec ‘ business speak ‘ en tant que tel; essayez de le rendre aussi pertinent que possible pour votre public. Si vous ‘ parlez aux dirigeants, faites expliquez comment la norme de code a un lien direct avec la maintenance et les performances, et discutez de la façon dont cela est lié aux finances globales du projet, à la stabilité à long terme, etc. Il semble que vous ‘ jai été embauché en raison de vos connaissances; rappelez-vous ceci. (Il suffit de ‘ devenir un gestionnaire de branlette qui pense il sait toujours mieux – mais dans ce cas, vous ‘ êtes correct à 100%.)
  • +1 pour  » le code de travail lemporte sur tout argument sur la théorie ou la bonne conception.  » Quelque chose que nous oublions souvent dans notre quête pour un code parfait.
  • Excellente réponse, beaucoup de sagesse pour les futurs chefs déquipe.

Réponse

Tout dabord, vous devez montrer que toute organisation mesurable doit adopter les meilleures pratiques du secteur. Dire que « ça marche juste pour nous! » ne peut être mesuré ni en temps ni en ressources car il 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.

  1. the 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 en pratique.

  2. Lors de la conférence Google IO de 2009 , ce sujet a été partiellement expliqué lorsque le MVP motif a été expliqué. Cela peut ne pas être pertinent pour lobjet Dieu, mais peut vous donner des munitions.

  3. De plus, lutilisation de cet anti-motif enfreint la 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é par la classe. Tous ses services doivent être étroitement alignés sur cette responsabilité.

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

  5. Nous ne pouvons pas parler du principe de responsabilité unique sans parler dobjet couplage .

    […] le couplage ou la dépendance est le degré auquel chaque module de programme sappuie sur chacun lun des autres modules.

    Là où le fait davoir 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 dobjets signifie moins de cohésion, et vice versa. Les objets de Dieu sont un bon exemple de couplage serré car ils en savent plus quils ne devraient, donc les surchargent de responsabilité, limitant ainsi considérablement la réutilisabilité du code.

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

    Avec cet argument, nous retournons à largument anti-pattern, mais ce paradigme concerne les modèles, la représentation dobjets du monde réel et, finalement, les données encapsulation.

  7. Vous avez raison quand vous dites que ces «bonnes pratiques» sont plus présentes dans les salles de classe. Cependant, jai des expériences denseignement au collège (et dans certaines universités) et je nai vu ces principes enseignés que dans les universités, en particulier dans les facultés dingénierie. Ce qui est triste. Mais comme dans toute bonne pratique, ceux qui s’efforcent de s’améliorer apprennent généralement quelques modèles de conception de base et comprennent finalement comment jongler entre le couplage et la cohésion.

    Ce que jenseigne habituellement aux étudiants, cest que peut sembler exiger plus defforts pour adopter de bonnes normes de programmation, mais cela est toujours payant à long terme. Un bon exemple serait quelquun qui demande à 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 durable à mesure que la liste des éléments grandit, ou 2) écrire un algorithme de tri plus complexe (également optimisé) (tri rapide, etc.) qui évoluera mieux avec des listes plus grandes.

Commentaires

  • Les langages de programmation orientés objet exigent souvent que si deux assemblys sources indépendants sont responsables pour différents aspects du comportement dun objet ‘, des instances dobjet indépendantes devront être créées pour encapsuler ces comportements. Malheureusement, même si dans de nombreux cas les subdivisions les plus logiques des fonctionnalités entre les assemblys de code ne coïncident pas ‘ avec la subdivision la plus logique des fonctionnalités entre les instances dobjet, je ‘ je nai pas vu beaucoup de discussions sur la distinction des deux types de subdivision.
  • Je pense que cest un peu hors sujet pour cette question. Nous ‘ ne parlons pas ici de lanti-pattern God Object, mais du couplage et de la cohésion de code, qui est un sujet très large et très subjectif.

Réponse

Oh me voilà, 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 culturel

Vous êtes leur manager mais vous ne pouvez pas les remplacer et vous devez vous adresser à vos managers pour les amener à faire ce que vous pensez quils devraient faire, ce qui dans ce cas, je suppose, cest au moins le faire tomber avec les objets divins 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 de savoir comment fonctionne cette société. Vous voulez apporter des changements significatifs? Vous allez toujours au même endroit. finalement puisque toutes les décisions doivent apparemment être effacées en haut.

Ayant été p rivé à de multiples tentatives infructueuses de nettoyage du code hérité et de changements de politique de code Je suis maintenant davis que vous ne pouvez pas combattre la culture qui a rendu le code possible en premier lieu lorsque cette culture est encore fermement ancrée ou du moins, la lutte contre la culture est une tâche très difficile en montée où il est peu probable que quiconque puisse me payer assez ou me donner assez de pouvoir pour avoir limpression que cétait une entreprise qui en valait la peine et qui risquait de réussir à nouveau.

Avant quil puisse y avoir des changements, ils doivent être motivés pour changer et malheureusement en tant que programmeurs qui se donnent assez de peine pour lire Stack de temps en temps, il est difficile pour nous de comprendre que tout le monde nest pas motivé par les mêmes choses. Jai gagné beaucoup darguments rationnels dans mes expériences, mais en fin de compte, lentreprise souffre de développeurs intellectuellement paresseux pour une raison.

Peut-être que les préoccupations commerciales 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 lenfant dimmigrants dun pays qui a construit un coffre-fort dans lArctique en cas dapocalypse). Peut-être ont-ils peur du changement.Peut-être quils accordent trop dimportance à lancienneté au point que la chaîne de commandement na pas de sens, même lorsquils doivent embaucher de lextérieur pour faire appel à un chef déquipe de développement ou à un responsable, car ils reconnaissent que personne dans leur équipe à vie na suffisamment grandi en leur temps. là (ou parce que les condamnés à perpétuité ne veulent pas du risque associé à la responsabilité). Ou, et jai « vu cela, cest peut-être le phénomène très réel et déprimant de la médiocrité qui se défend parce quil sait au fond de lui quil le peut » t rivaliser avec la qualité et quand il ya assez de sottises pour contourner, il est impossible de savoir qui blâmer quand tout se détériore régulièrement.

Comment combattre les problèmes qui sont finalement enracinés dans la peur ou métriques brisées pour réussir? Je vais vous dire ceci, cela prend beaucoup plus que même une équipe de développement de qualité engagée et vous avez eu beaucoup moins que cela du son au moment où ce Q a été publié.

Dans lévénement pas impossible que ce nest pas un problème de culture intraitable …

En supposant maintenant que les gens sont au sommet sont très réceptifs au changement, et ils « sont vraiment prêts à vous faire confiance pour le faire, il vous suffit de ponctuer tous vos arguments avec de largent et des opportunités perdues.

Chaque fois que cela prend plus de temps pour former quelquun nouveau sur cette base de code ridicule, chaque fois quil faut plus de temps pour modifier ou ajouter une nouvelle fonctionnalité à quelque chose, chaque fois quil devient extrêmement difficile dexposer des points de terminaison à un autre système dune entreprise avec laquelle vous souhaitez établir un partenariat, cela coûte de largent. Plus important encore, cela laisse une fenêtre ouverte à un concurrent plus petit et plus agile, vous mettant dans une position où tout ce que vous pouvez faire est de réagir beaucoup trop lentement wly, et finalement vous arracher tout cela.

Reconnaissez simplement quune culture particulièrement têtue et stupide maintiendra le statu quo à tout prix, même si le toit physique réel de lentreprise est en fait en feu parce que

Commentaires

  • Jai quitté lentreprise peu de temps après. ils ont essayé de membaucher à plein temps et de me faire déménager de Seattle à New York afin daccepter loffre; Je leur ai essentiellement dit que  » Pas question, je ‘ ne déménagerai pas à New York lorsque l’équipe que je dirigerais sera à Bellevue, WA  » et à ce moment-là, jai traversé la rue et jai trouvé un emploi chez MSFT jusquà ce que je trouve quelque chose de mieux.
  • @honestduane Oui, cet ensemble dattentes seul en dit long. Tant mieux pour le GTFO.

Réponse

Vous pouvez citer certains des principes de POO les plus élémentaires tels que couplage lâche et cohésion élevée. Un « objet Dieu » donne limpression quil couple des classes sans rapport et a une faible cohésion.

Réponse

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

Le fait est que cest tellement évident pour les gens qui ont un sens quelconque quune fois que cest énoncé, il na pas besoin dêtre re-référencé par une multitude dauteurs. Il suffit dêtre une source.

Les autres termes avec lesquels vous voudrez peut-être commencer lorsque vous recherchez des sources sont:

  • SOLID
  • Loi de Demeter
  • Big Ball of Mud

Tous ces concepts liés expriment qui pourraient produire des sources de référence viables, même sils ne le nomment pas comme tel.

En fin de compte cependant, vous êtes le patron. La raison de le faire est 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 avez fait cela, et sil y a encore de la résistance, la bonne marche à suivre pour votre équipe est de faire ce quon lui dit.

Commentaires

  •  » sil y a encore de la résistance, la bonne marche à suivre pour votre équipe est de faire ce quelle ‘ dit  » Peut-être que la bonne marche à suivre est de quitter plutôt que de rendre votre équipe misérable.?
  • Le responsable ‘ s la décision a été suffisamment justifiée, et si l’équipe ‘ n’est pas d’accord, alors le problème vient de l’équipe. LOP a été embauché pour son expertise et pour ne pas être autorisé à lutiliser au profit de lentreprise car les collègues ne ‘ ne se comportent pas raisonnablement ‘ t acceptable. Laissons ‘ s renverser votre affirmation – pourquoi ‘ t les membres résistants de l’équipe quitteraient si leur vision du travail est incompatible avec celui de lentreprise?
  • Bon point. Cela dépend de la manière dont vous souhaitez diriger léquipe. Mais daprès mon expérience, forcer les gens à faire des choses contre leur volonté ne fait que conduire à la misère. Je préférerais voir des objets de Dieu dans toute la base de code quune équipe de développement misérable. Peut-être que la réponse est de les envoyer suivre une formation. Tout le monde aime un cours de formation. Gagnant-gagnant.
  • Le développeur / gestionnaire principal / quoi que ce soit devrait absolument prendre toutes les mesures raisonnables pour sassurer que léquipe conserve une bonne relation de travail les uns avec les autres. Si une formation supplémentaire est utile, alors considérez-la comme une option – mais cela semble être comme un cas dignorance volontaire, et dire à quelquun quil doit être formé pour comprendre votre idée quand ce quil pense ‘ avoir fait est en désaccord, plutôt que de ne pas comprendre, pourrait se retourner contre vous. Jai du mal à imaginer des moyens de traiter avec des personnes qui ‘ ne veulent pas apprendre.

Réponse

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

Vous ne pouvez pas.

Ce type de conjecture ne se prête pas à une 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 émotif « faux » avec des mesures quantifiables des effets de lutilisation dobjets divins, vous constaterez que:

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

Et cela ignore la question de savoir quand un objet particulier est un objet « dieu ».

Au mieux, ces types détudes ne pourraient démontrer quune corrélation empirique. Ce n’est pas une véritable preuve.

En fait, vous débattez des avantages et des inconvénients d’objets «divins» en vue de changer les opinions des autres «  … et ensuite la pratique de votre organisation.

Nutilisez pas de mots comme «preuve» ou les personnes avec lesquelles vous discutez risquent de vous rire au nez.

Réponse

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

Extrait:

(Major) Il isole fonctionnalité potentiellement indépendante à lintérieur dune classe […] (mineur) Cela peut décourager lextension de la classe avec de nouvelles fonctionnalités […]

Réponse

Je ne suis pas sûr que votre équipe sintéresse vraiment à la preuve académique que « les objets de Dieu sont faux ».

Dun 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 est de faire face aux effets secondaires négatifs du « code spagetti » et des « objets Dieu »: les coûts explosifs pour ajouter de nouvelles fonctionnalités en raison de laugmentation des bogues causés par les effets secondaires.

Beeing very Des questions spécifiques et poser des questions au lieu de fournir des réponses peuvent être plus utiles: 

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

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *