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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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;)

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.

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.