Comment convaincre mon équipe d'utiliser des classes / méthodes plus petites?

27

Avertissement: je suis un nouveau venu (c'est mon troisième jour de travail) et la plupart de mes coéquipiers sont plus expérimentés que moi.

Quand je regarde notre code, je vois des odeurs de code et de mauvaises pratiques d'ingénierie, comme les suivantes:

  • Consignes de dénomination quelque peu incohérentes
  • Propriétés non marquées comme étant en lecture seule lorsque cela est possible
  • Grandes classes - J'ai remarqué une classe utilitaire composée de centaines de méthodes d'extension (pour de nombreux types). Il faisait plus de 2500 lignes!
  • Grandes méthodes - J'essaie de refactoriser une méthode de 150 lignes.

Les deux derniers semblent être un vrai problème. Je veux convaincre mes coéquipiers d'utiliser des classes et des méthodes plus petites. Mais dois-je faire ça? Si oui, alors comment?

Mon équipe a obtenu un mentor de l'équipe principale (nous sommes une équipe satellite). Dois-je aller le voir en premier?


MISE À JOUR : Étant donné que certaines réponses ont posé des questions sur le projet, sachez qu'il s'agit d'un projet fonctionnel. Et à mon humble avis, d'énormes classes / méthodes de cette taille sont toujours mauvaises.

Quoi qu'il en soit, je ne veux jamais faire chier mon équipe. C'est pourquoi j'ai demandé - Dois-je faire cela, et si oui, alors comment je le fais doucement?

MISE À JOUR : J'ai décidé de faire quelque chose en fonction de la réponse acceptée: parce que je suis un nouveau venu, donc je vois tout de "nouveaux yeux", je prendrai note de toutes les odeurs de code que j'ai trouvées (position, pourquoi il est mauvais, comment pouvons-nous le faire mieux, ...), mais pour le moment, j'essaie juste de rassembler les respects de mon équipe: écrire "un meilleur code", connaître les gens, savoir pourquoi avons-nous fait ça ... Quand le moment sera venu, j'essaierai pour demander à mon équipe de nouvelles politiques de code (directives de nommage, classes plus petites, méthodes plus petites, ...), et si possible, refactoriser un ancien code. Cela devrait fonctionner, à mon humble avis.

Merci.

Vimvq1987
la source
11
Une recommandation que je ferais est de regarder le code source dans lequel ils se connectent maintenant, pas ce qui est actuellement dans le projet. Il est possible que la majeure partie du code actuel n'ait pas été écrite par vos collègues, mais plutôt par vos gestionnaires actuels il y a 10 ans.
earlNameless
14
Vous allez probablement faire chier les gens car vous n'êtes au travail que depuis 3 jours. Apprenez à connaître l'équipe en premier et gagnez du respect. Apportez des choses dans une conversation décontractée pour sentir les eaux sortir. Vous avez la bonne idée, mais vous pouvez être un cheval de course dans une écurie de chevaux de ferme.
kirk.burleson
4
Bienvenue dans le monde réel :)
fretje
Avec des fonctions plus petites, le compilateur JIT sera plus heureux et le code sera plus rapide. Article C # Second Effect effectif
Travail
3
Je n'ai pas pu m'empêcher de rire quand j'ai vu à quel point vous vous sentiez horrifié en voyant une classe utilitaire de 2 500 lignes. J'ai vu plus d'une classe de 25 000 lignes au cours de ma carrière. Ne vous méprenez pas, cependant, je pense qu'une classe devient trop longue après 500 lignes.
PeterAllenWebb

Réponses:

19

Vous avez l'avantage de voir le code avec des yeux neufs. Prenez des notes pour documenter ce que vous découvrez des mauvaises pratiques. Ensuite, pendant que vous vous installez avec l'équipe, sortez vos notes à un moment opportun, comme quand il est temps de refactoriser.


la source
Vraiment une bonne idée. Notez les choses maintenant, proposez quelques changements plus tard.
Roman Grazhdan
3
Cela fonctionne en théorie, mais en pratique, ils vont juste battre le sac hors de lui.
Job
15

Code Complete, par Steve McConnell, a des tonnes de bonnes statistiques sur le sujet même dont vous parlez. Je ne me souviens pas de tous les chiffres, mais il parle de la façon dont le nombre de bogues augmente avec des méthodes / classes plus longues, combien de temps il faut pour déboguer, etc.

Vous pourriez acheter une copie du livre et montrer à vos pairs certaines des études ... les statistiques (bien qu'elles mentent tout le temps) ont tendance à convaincre les gens.

Esteban Araya
la source
1
+1 pour Code complet. Recherchez également le terme «dette technique». Je trouve très utile d'expliquer aux autres pourquoi parfois (mais pas toujours) il vaut la peine d'investir pour simplifier le code. Cependant, la première règle consiste à créer des tests. Tests unitaires, tests système, tests d'intégration, etc. Avant de refactoriser, créez des tests. Test, test, test. Tests.
Ben Hocking
@Ben aucun manque de respect, mais je pense que le terme «dette technique» est largement utilisé. Dès que quelqu'un commence à utiliser cela comme raisonnement derrière une décision, j'ai tendance à cesser d'écouter. C'est peut-être un défaut de ma part, mais quand j'entends que mes pensées vont vers "cette personne lit beaucoup de blogs mais ne comprend pas vraiment les coûts réels de l'équilibrage du code de retravail par rapport à d'autres tâches"
Gratzy
3
@Gratzy: Je suis sûr que cela dépend de votre expérience personnelle. Je ne veux pas entrer dans les détails, mais quand on voit des projets en «dette technique» jusqu'au cou, l'expression devient très appropriée. Les codeurs peuvent consacrer 90% de leur temps à «payer les intérêts» sur la dette. Dans ces cas, il n'est pas surprenant de découvrir que personne dans l'équipe n'a entendu parler du terme.
Ben Hocking
Clean Code contient également de nombreuses informations à ce sujet (mais pas beaucoup de statistiques).
Steven Evers
Si vous jetez un œil à la page 173, McConnell présente des preuves statistiques en faveur des tailles de routine qui inciteraient probablement la plupart des défenseurs agiles. Il met 150 lignes assez clairement dans la colonne OK (mais pas idéal), mais donne une forte recommandation personnelle contre le
Dan Monego
13

Avertissement: je suis un nouveau venu (c'est mon troisième jour de travail) et la plupart de mon équipe est plus expérimentée que moi.

Vous voudrez peut-être ralentir un peu, écouter et apprendre de votre équipe avant d'aller suggérer trop de changements. Il peut y avoir ou non de bonnes raisons pour lesquelles le code est structuré tel quel, mais dans les deux cas, prendre le temps d'écouter et d'apprendre en premier ne peut que vous aider.

Après cela, toutes les suggestions que vous pourrez faire seront très certainement perçues de manière plus positive et rencontreront moins de résistance.

Vos chances d'introduire des changements avec succès sont considérablement améliorées si vous gagnez le respect, ou du moins ne perdez pas le respect, de vos collègues en premier.

Comment ça marche? "Mesurer deux fois couper une fois .." Quelque chose comme ça.

Gratzy
la source
1
Je suis d'accord. qui peut dire qu'ils savent que c'est une mauvaise pratique mais où dans un délai très serré? Ou peut-être qu'ils avaient un groupe de personnes avant eux qui ont fait une partie du code, et n'ont pas eu le temps de refactoriser? Comme vous êtes nouveau, gardez l'esprit ouvert lorsque vous leur faites savoir
Spooks
12

Sauf si vous avez été embauché avec l'intention spécifique de réviser la façon dont votre équipe écrit le code, vous souhaiterez peut-être modérer votre enthousiasme pour les révisions radicales. La plupart des codes de travail fonctionnent pour une raison :), peu importe la façon dont ils sont, et des révisions parfois drastiques rendent ces cas de coin ennuyeux encore plus laids.

Je pense que le levier le plus simple pour écrire du code plus petit serait de demander aux développeurs de se concentrer sur les tests unitaires . Rien ne force un code concis comme si on lui demandait de le tester ; C'est incroyable de voir comment les développeurs ont soudainement une aversion pour les structures de données globales, passant trop d'objets trop de couches en profondeur, quand ils savent qu'ils doivent écrire des tests pour tout cela.

Je ne suis pas un grand fan de TDD mais je n'aime le fait qu'il oblige les développeurs à se demander comment ils écrirait tests. Et c'est souvent la raison pour laquelle le code est meilleur, pas une magie d' avoir réellement les tests. (Bien que cela soit utile lorsque vous apportez des modifications ultérieurement.)

Bonne chance.

sarnold
la source
++ pour "modérer votre enthousiasme". À mon humble avis, la véhémence avec laquelle ces principes sont promulgués est inversement proportionnelle à leur justification. (Les religions sont comme ça.)
Mike Dunlavey
11

Vous ne devez pas convaincre votre équipe. En tant que nouveau venu, vous ne serez pas pris au sérieux - ce qui fait perdre du temps.

Au lieu de cela, allez-y et écrivez vous-même du code compact et propre. Avec un peu de chance, après un certain temps et quelques révisions de code, certains coéquipiers pourraient commencer à imiter votre style.

Sinon, vous serez toujours plus productif et votre travail acharné vous amènera éventuellement à une position plus élevée où vous pourrez commencer à appliquer certaines de ces règles.

Et oui, par tous les moyens, montrez des choses de Code Complete à tout le monde.

Jas
la source
3
+1 pour "Au lieu de cela, allez-y et écrivez vous-même du code compact et propre". Il est souvent préférable de donner l'exemple. Et nettoyer une base de code établie ressemble plus à un marathon qu'à un sprint; cela demande de la patience et de la persévérance.
JeremyDWill
8

Voici quelques astuces:

  • Apprenez l'état actuel et l'histoire de l'équipe - on dirait qu'ils ont un mentor, quelle est l'influence du mentor? De plus, à quel point le mentor est-il nouveau et y a-t-il longtemps sans mentor? Quand est-ce que le code de problème provient? Critiquer le bébé de l'équipe actuelle peut être très différent de critiquer un ancien code que personne ne se souvient d'avoir écrit.

  • Une chose à la fois - ne laissez pas tomber la bombe sur toutes vos pensées lors d'une réunion d'équipe. Commencez par quelques questions provisoires qui viennent de votre point de vue spécifique. Par exemple - "Hé, en tant que nouveau gars, j'ai remarqué que certaines des classes utilitaires sont vraiment grandes, y a-t-il une raison à cela?"

  • Suggérez des étapes pour bébé - il n'est presque jamais possible de faire une révision totale immédiate, alors déterminez quelques étapes de départ à suggérer au cas où tout le monde conviendrait qu'il s'agit d'un bon plan.

  • Suggérez de futurs mécanismes de prévention - par exemple, l'équipe pourrait convenir d'un objectif qui ne s'ajoutera jamais aux quelques classes les plus importantes, mais qui sera remanié lorsqu'il sera nécessaire de les développer davantage.

  • Écoutez les préoccupations concernant le risque. S'il s'agit vraiment d'un code hérité, il peut y avoir suffisamment d'inconnues et de dépendances pour que le refactoring soit extrêmement risqué. Ce n'est peut-être pas une raison pour éviter la refactorisation, mais cela peut signifier que vous avez besoin de meilleures stratégies de test ou d'une autre manière de réduire les risques avant de vous attaquer au vrai remaniement.

  • Soyez conscient du langage corporel et allez lentement. Vous soulevez un problème dans une base de code avec laquelle vous n'avez pas beaucoup d'expérience. Vous avez une nouvelle fenêtre de type en ce moment, où vous pouvez poser des questions naïves et obtenir des réponses utiles, et vous pouvez utiliser ces questions pour sonder l'équipe afin d'examiner ses propres choix de conception. Mais cela va dans les deux sens - en tant que nouveau gars, vous n'avez pas encore une tonne de "crédibilité", alors allez-y lentement et soyez conscient des visages fermés ou des postures. Si les gens commencent à fermer, suggérez un moyen de retarder toute décision et cherchez des moyens de les gagner.

Je peux dire qu'en tant que manager et membre de l'équipe, je suis content pour New Guy Insights. Je n'ai pas accepté chaque commentaire constructif qu'un nouveau membre de l'équipe m'a donné, mais j'étais généralement disposé à écouter si la critique était exprimée comme une préoccupation et une curiosité honnêtes et non pas comme une conférence. La marque de respect envers le nouveau gars va quand il peut fournir des informations, puis prendre du recul et gérer tout ce qui vient - il est facile de se sentir bien lorsque vos décisions sont entendues et prises, c'est plus difficile lorsque l'équipe vous dit "non". Vous avez peut-être encore raison, l'astuce consiste à déterminer ce qu'il faut faire ensuite ... généralement attendre un peu et rechercher plus d'informations est une bonne étape dans ces cas.

Bethlakshmi
la source
6

Comment convaincre mon équipe d'utiliser des classes / méthodes plus petites?

Non.

Achetez-vous une licence Resharper et montrez l'exemple. [S'appuyer fortement sur la refactorisation de la « méthode d'extraction ».]

Au fil du temps, d'autres devraient apprécier votre code plus lisible et être persuadés de faire de même. *


  • Oui - il y a une chance qu'ils ne soient pas convaincus; mais c'est toujours votre meilleur pari.

IMO - Cela ne vaut pas la peine de chercher à convaincre vos coéquipiers de devenir de meilleurs programmeurs, lisez « Code complet », suivez @ Oncle Bob. des principes SOLIDES et devenez de meilleurs programmeurs s'ils ne sont pas déjà convaincus.

Rappelez-vous: vous ne pouvez pas utiliser la logique pour convaincre quelqu'un d'une position dans laquelle il n'a pas utilisé la logique en premier lieu.

Jim G.
la source
4
+1 et accord. Votre deuxième point est ce que j'ai trouvé le plus vrai; les bons programmeurs savent déjà ces choses ou sont prêts à commencer immédiatement à les apprendre et à les appliquer, les mauvais programmeurs prétendent s'en soucier ou ne comprennent tout simplement pas pourquoi ces choses sont bonnes (s'ils avaient compris, ils l'auraient déjà fait). Il y a de fortes chances que vous meniez une bataille perdue. Il est triste de voir combien de "programmeurs" ne comprennent rien au développement logiciel approprié.
Wayne Molina
4

Cela semble être plus une question de gestion qu'une question technique. Tout ce que vous avez dit est valide, ce dont votre équipe a vraiment besoin, c'est d'un bon architecte qui puisse s'assurer que tout le monde s'adapte à un modèle de conception unique et le faire appliquer, l'équipe doit constamment et régulièrement refactoriser le code.

Cependant, il existe un autre principe "vous n'en aurez pas besoin", si ce qui a existé fonctionne pendant assez longtemps, peu importe à quel point il est laid, le changer n'est toujours pas une bonne idée. Au lieu de cela, si votre équipe a besoin de reconstruire le tout ou d'en reconstruire une partie, accumulez un document de mauvaises pratiques et de problèmes avant d'effectuer le codage.

user658991
la source
3
Et sûrement, vous devriez approcher le mentor de l'équipe, mais avant de le faire, vous devriez consulter et discuter poliment avec vos collègues, ne les faites pas se sentir exclus. Ça va vous rendre la vie difficile à l'avenir.
4

Certaines équipes ne font aucun type de contrôle de qualité pour le code car elles ne connaissent pas les bons outils pour cela. Il existe de nombreux outils qui peuvent aider à mieux coder une équipe.

Visual Studio a une "analyse de code" qui peut aider avec les conventions de dénomination.

Des mesures de code pourraient également être utilisées, comme la complexité cyclomatique. Cela permet de mettre en évidence des classes et des méthodes trop complexes.

Tenir des registres est également une bonne idée. Si les membres de l'équipe expriment simplement verbalement ce qui doit être fait, alors les gens sont tenus d'oublier. Les humains ont des souvenirs très fragiles! =)

Je ne ferais pas beaucoup de bruit à ce sujet ... L'équipe de développement d'un programmeur est comme sa propre famille ... Si vous signalez des erreurs, les gens peuvent se mettre en colère contre vous. Ce type de changement de culture nécessite non seulement beaucoup de codage, mais il nécessite également un contact délicat avec les êtres humains.

Miguel Angelo
la source
3

En tant que manager, je veux juste ajouter que je veux que mon équipe écrive du bon code la première fois. Revues de code, TDD et tout ça. Mais une fois qu'il est en production et que cela fonctionne, il vous faudra présenter des arguments solides pour que nous y revenions.

Je ne fais que suivre les conseils de l'oncle Bob de toujours laisser le code mieux que vous ne l'avez trouvé. Donc, si nous avons des bogues à corriger ou de petites améliorations, j'espère que nous faisions une partie du nettoyage à ce moment-là.

Mais en l'état, l'entreprise regarde vraiment son argent. Je devrais leur expliquer que le refactoring leur profite suffisamment pour donner à mon équipe le temps et les ressources. Il ne suffit pas de ne pas aimer l'apparence du code.

Donc, si cela fonctionne, autant que vous le détestiez, vous devrez peut-être le laisser tranquille.

Maintenant, le nouveau code, c'est différent. Cela devrait être un bon code.


la source
2

Des méthodes qui font 150 lignes ... J'ai vu des méthodes avec 10 000 lignes de code.

Deux de vos problèmes peuvent être résolus avec des outils externes :

  • Consignes de dénomination quelque peu incohérentes
  • Les propriétés ne sont pas marquées comme étant en lecture seule lorsque cela est possible

En C # Resharper peut vérifier les deux problèmes. Les noms qui ne suivent pas vos directives sont marqués comme des erreurs. Les propriétés non marquées comme étant en lecture seule sont également des erreurs. FxCop pourrait également être une aide.

Ces outils peuvent également aider à diviser d'énormes méthodes en plusieurs plus petites grâce à sa refactorisation.

Carra
la source
2

Je ne sais pas que les grandes classes sont toujours si mauvaises si elles sont bien structurées avec des méthodes bien nommées. J'utilise Eclipse comme mon IDE donc il a quelque chose appelé la vue "contour", qui est quelque chose que tous les IDE ont juste avec un nom différent, très probablement, qui fournit le nom et le lien vers chaque méthode dans la classe, vous pouvez le trier par ordre alphabétique , etc. Lorsque vous l'utilisez, il est facile de naviguer dans une grande classe, plus il serait mauvais d'avoir des méthodes très longues, je pense parce qu'il est plus difficile de naviguer intelligemment dans cette méthode à moins que vous ne soyez vraiment familier avec elle. Je ne préconise pas les classes longues mais je pense qu'elles sont gérables dans certains cas et n'ont pas nécessairement besoin d'être divisées en plusieurs classes.

programmx10
la source
1

Abordez le sujet avec certains des membres de votre équipe et obtenez leur avis sur la taille des méthodes. Vous pourriez être surpris de constater qu'ils sont d'accord avec vous. Ce que vous voyez pourrait être le résultat de mauvaises pratiques antérieures, d'anciens développeurs ne faisant plus partie de l'entreprise, ou cette partie était un travail précipité et maintenant ils ont embauché quelqu'un avec du temps pour le refactoriser;)

JeffO
la source
1

Tu es toujours le nouveau mec. Construisez une certaine réputation en assumant des tâches difficiles et en les remplissant rapidement et sans bugs. Si vous essayez de commencer à changer les choses avant de gagner le respect de vos pairs, vous aurez peut-être beaucoup plus de mal à adhérer (et peut-être à aliéner vos collègues).

Si vous pouvez trouver des façons d'introduire les meilleures habitudes de codage dans votre propre travail qui démontrent efficacement comment elles réduisent le temps de développement et aboutissent à des solutions plus robustes, vous pourriez même les voir venir vous voir pour voir comment vous y êtes parvenu.

Mayo
la source
1

En plus de toutes les autres bonnes réponses, vous pouvez peut-être tuer deux oiseaux avec une pierre et effectuer un nettoyage de code en tant que projet visant à mieux comprendre la base de code. Vous pouvez le vendre à votre équipe / manager comme une opportunité d'apprentissage pour vous, et vous obtiendrez des commentaires de vos pairs lorsqu'ils examineront vos changements, ce qui vous guidera dans votre meilleure approche pour résoudre le problème de la mauvaise conception.

dma
la source
comment cela répond-il à la question posée?
moucher