Comment dire (avec tact) à mon chef de projet ou développeur principal que la base de code du projet nécessite un travail sérieux?

Je viens de rejoindre une équipe de développement (relativement) petite qui travaille sur un projet depuis plusieurs mois, voire un an. Comme la plupart des développeurs se joignant à un projet, j'ai passé mes premiers jours à examiner la base de code du projet.

Le projet (une application métier interne ASP.NET WebForms de taille moyenne à grande) est, faute d'un terme plus descriptif, un désastre. Il y a trois problèmes immédiatement perceptibles avec les normes de codage:

1. La norme est très lâche. Il décrit plus ce qu'il ne faut pas faire (n'utilisez pas la notation hongroise, etc.) que ce qu'il faut faire.
2. La norme n'est pas toujours respectée. Il y a des incohérences avec le formatage du code partout .
3. La norme ne suit pas les directives de style de Microsoft. À mon avis, il ne sert à rien de s'écarter des directives énoncées par le développeur du cadre et le plus grand contributeur à la spécification du langage.

Quant au point 3, il me dérange peut-être davantage parce que j'ai pris le temps d'obtenir mon MCPD en mettant l'accent sur les applications Web (en particulier, ASP.NET). Je suis également le seul Microsoft Certified Professional de l'équipe. En raison de ce que j'ai appris dans toutes mes études, mon auto-apprentissage et mon apprentissage en cours d'emploi (y compris ma préparation aux examens de certification), j'ai également repéré plusieurs cas dans le code du projet où les choses ne sont tout simplement pas faites dans le meilleur moyen.

Je ne fais partie de cette équipe que depuis une semaine, mais je vois tellement de problèmes avec leur base de code que j'imagine que je passerai plus de temps à me battre avec ce qui est déjà écrit pour faire les choses à leur manière que je ne le ferais si j'étais travailler sur un projet qui, par exemple, a suivi des normes de codage, des modèles d'architecture et des meilleures pratiques plus largement acceptés. Cela m'amène à ma question:

Dois-je (et si oui, comment dois-je) proposer à mon chef de projet et à mon chef d'équipe que le projet doit être rénové en profondeur?

Je ne veux pas entrer dans leur bureau, agitant mes certificats MCTS et MCPD, disant que la base de code de leur projet est de la merde. Mais je ne veux pas non plus avoir à me taire et à écrire du code kludgey au-dessus de leur code kludgey, car je veux en fait écrire des logiciels de qualité et je veux que le produit final soit stable et facilement maintenable.

Vous pourriez passer votre temps à plaider votre cause; ou vous pourriez passer votre temps à nettoyer au fur et à mesure.

Choisissez des principes, des modèles et des pratiques de code propre et de développement logiciel agile et appliquez ce que vous y apprenez pendant que vous travaillez sur le système. Finalement, les gens remarqueront (pour le meilleur ou pour le pire).

Modifier Consultez également Travailler efficacement avec le code hérité

D'après ce que vous décrivez, il semble que les problèmes concernent principalement le non-respect des normes de codage et les problèmes de dénomination. Ce n'est pas un désastre , de loin. Pour une comparaison, c'est une catastrophe, pour de vrai.

Peut-être êtes-vous habitué et exigez-vous des normes élevées? Dans ce cas, tout écart par rapport à la perfection pourrait être considéré comme un échec. C'est un piège dans lequel il est facile de tomber lorsque vos demandes sont élevées, mais il est important de garder une perspective sur les choses.

Je vous suggère de parler de cela comme d'une amélioration et d'aider l'équipe à mettre à jour ses directives et de les coacher pour commencer à les utiliser pour de vrai. J'aime vraiment utiliser une Définition de Terminé comme référence de qualité et en créer une est une excellente équipe à elle seule. Mais je ne pense pas que vous devriez en faire beaucoup plus que cela, du moins pas en tant que nouveau membre de l'équipe.

Décidément, n'allez pas agiter votre MCSD, les gens se moqueront de vous franchement, les certificats MS sont agréables à avoir mais ils ne sont en aucun cas une qualification professionnelle!

Rejoignez légèrement une nouvelle équipe, recherchez des opportunités pour suggérer des changements au fur et à mesure.

Attendez d'avoir la configuration du terrain avant de supprimer un code d'équipe.

Vous pourriez considérer que le problème est vous. AUCUNE des trois choses que vous avez mentionnées ne mérite une refonte complète d'une application. Ce ne sont que des détails épineux.

N'oubliez pas que le but de l'application n'est pas d'avoir un beau code, c'est de résoudre un problème métier. Bien sûr, il est agréable d'avoir un code cohérent et conforme à un bon standard, mais son absence n'est pas une raison pour jeter la totalité de la base de code. Ce n'est pas parce que le moteur est huileux qu'il doit être reconstruit.

Écoutez, tout le monde déteste chaque base de code qu'ils n'ont pas écrite. En fait, si vous attendez trois ans et regardez votre propre code, vous le détesterez aussi et penserez qu'il a besoin d'une réécriture complète. La vérité est que non. À moins que vous ne puissiez prouver que passer des mois à rendre le code agréable pour vous au lieu de créer des fonctionnalités pour ajouter de la valeur commerciale, vous aboyez probablement le mauvais arbre.

Rien ne dit que vous devez écrire du code kludgy juste parce qu'il pourrait y en avoir dans la base de code. Et rien ne dit que le code EST kludgy juste parce qu'il n'adhère pas au style de votre animal de compagnie. Il suffit de remanier au fur et à mesure les parties sur lesquelles vous travaillez et d'écrire du bon code lorsque vous travaillez sur de nouvelles choses.

Ces choses sont inquiétantes, mais si vous êtes nouveau dans l'équipe, ne secouez pas le bateau pour le moment, jusqu'à ce que vous ayez acquis une certaine crédibilité avec eux.

Il semble que vous ayez choisi trois choses (relativement) mineures pour vous inquiéter. Il y a d'autres choses qui me préoccuperaient davantage:

• Le code est-il bien documenté?
• Le code respecte-t-il les spécifications / documents de conception?
• Le code fonctionne-t-il?
• Est-il facile de comprendre ce que fait le code?
• Envisagez-vous de soumettre de gros morceaux de cette base de code à TheDailyWTF?

Tu es là depuis une semaine? Je ne suis pas sûr que vous en sachiez encore assez pour faire des propositions au chef de projet. Même si vous pensez que le code et les pratiques de cette équipe sont "mauvais", la meilleure façon d'influencer ces choses au fil du temps est de gagner progressivement leur confiance et leur respect. Entrer dans un projet et après une semaine dire à l'équipe que leur code doit être réécrit n'est pas un bon moyen de gagner la confiance et le respect.

Pendant vos premiers mois, concentrez-vous sur un meilleur exemple et posez des questions sur les raisons pour lesquelles ils ont fait les choses de certaines façons. Faites attention à votre ton lorsque vous posez ces questions. Si vous apparaissez comme le nouveau mec qui sait tout, personne n'écoutera vos opinions plus tard lorsque vous serez vraiment en mesure d'influencer la façon dont les choses sont faites.

Au fil du temps, si votre code est vraiment "meilleur", les autres développeurs le verront. Ils commenceront à vous contacter en tant que ressource pour les aider à réparer le leur, puis vous demanderont vos conseils sur la façon dont ils devraient faire les choses. À ce stade, vous serez en bonne position pour dire à l'équipe (et à la direction) vos opinions sur les normes de codage et autres. La durée de ce processus varie selon l'organisation. Ce pourrait être quelques semaines dans un environnement très adaptable, ou des mois à des années dans une culture plus stoïque. Développez votre influence une personne à la fois.

Vous n'entrerez jamais dans un nouveau travail où vous penserez que la base de code est parfaite et que tout a été fait de la "bonne" manière. Apprenez à l'accepter. Tout ce que vous pouvez faire avec le code hérité, c'est refactoriser et avancer petit à petit. Certaines choses que vous ne voulez pas refactoriser avant d'avoir mieux compris pourquoi ils ont fait ce qu'ils ont fait. De plus, personne dans les affaires ne vous paiera pour réparer le code de travail, vous devrez donc faire une analyse de rentabilisation pour savoir pourquoi il a besoin de travailler avant d'intensifier et de passer du temps. Vous feriez mieux d'attendre de refactoriser le code lorsqu'il y a un changement que vous devez apporter de toute façon. Vous n'avez peut-être pas choisi la méthode utilisée pour certaines choses, mais si cela fonctionne, faites très attention à la changer et à introduire de nouveaux bogues. Surtout quand on ne vous a pas demandé de le changer.

Après une semaine, vous n'avez aucune crédibilité pour faire des suggestions majeures sur la façon dont ils font des affaires. Si vous abordez les choses maintenant, les gens se moqueront de vous et ne vous prendront jamais au sérieux. Prouvez-vous d'abord avec du bon code, puis les gens seront plus enclins à écouter.

Et franchement, personne ne se soucie que vous soyez un professionnel certifié Microsoft. Quiconque a beaucoup d'expérience a vu autant de mauvais programmeurs qui avaient cette certification que de bonnes personnes. Je ne dis pas que cela vous fait mal paraître d'avoir une certification, je dis que nous ne leur accordons pas beaucoup de crédit parce que nous n'avons pas vu où ils sont efficaces nous montre qui est un bon programmeur.

J'irais probablement dans la voie d'essayer de comprendre comment présenter la proposition dans l'intention de ne pas pouvoir justifier votre position de manière adéquate. Quelques questions à méditer lors de la création de cette proposition:

• Quelle valeur commerciale gagne-t-on en apportant les types de changements que vous décrivez ici?
• Avez-vous envisagé des options telles que la réécriture de l'application à partir de zéro, la modification du code existant pour le mettre à jour, ou tout simplement faire de petits changements au fil du temps?
• Savez-vous quelles fonctionnalités et quels bogues sont recherchés maintenant qui vous empêcheraient d'apporter les modifications que vous souhaitez?

Bien que je puisse apprécier vouloir corriger la mauvaise base de code, cela doit être pesé afin qu'il soit logique d'un point de vue commercial de le faire.

Vous n'êtes actuellement pas en mesure d'empêcher le mauvais code, vous devrez donc trouver comment le contenir.

Les PM et les chefs d'équipe ne s'en soucieront que si cela ne fonctionne pas. Leur prochaine préoccupation sera quand ils vous demanderont d'apporter des changements et se demander pourquoi les choses «simples» prennent autant de temps. C'est là que vous entrerez.

Commencez maintenant avec le problème de cohérence. Quelle que soit la méthode potentiellement standardisée actuellement, essayez de l'identifier et voyez si vous ne pouvez pas la faire appliquer. Si vous commencez avec une méthodologie que personne d'autre ne connaît, vous obtiendrez une tonne de recul.

D'autres membres de l'équipe voudront peut-être obtenir une certification et vous serez une excellente ressource. J'espère qu'ils voudront au moins s'améliorer et se tourneront vers vous pour leur montrer le chemin.

Se plaindre de la notation hongroise ne vous apportera aucune sympathie et est probablement l'une des dernières batailles sur la liste des priorités.

Je suis d'accord que vous devez être prudent à ce sujet. Vous devez vous forger une réputation au sein de l'équipe avant de pouvoir formuler des critiques et proposer des modifications profondes du code ou des processus. Je prendrais simplement des notes sur mes conclusions et suggestions pour le moment, et saisirais les opportunités pour me familiariser avec les membres de l'équipe et la direction, entrer dans des discussions libres mais ne pas refuser si la conversation se tourne vers des problèmes de qualité, des questions de codage, etc., parfois même lancer certaines de mes propres questions dans l'étang (mais sous une forme générale, pas trop pointées vers un problème concret que j'ai vu dans cette base de code). De cette façon, je peux connaître l'opinion des membres de l'équipe et trouver des alliés potentiels.

Dans le meilleur des cas, vous pouvez constater qu'une partie importante de l'équipe (et / ou de la direction) voit les mêmes problèmes que vous, juste qu'il n'y a eu aucune initiative pour y remédier, ou aucune ressource ne lui a été accordée par la direction. Ensemble, vous avez plus à dire pour convaincre la direction si nécessaire.

Comme l'a suggéré @Mike, faire une partie du nettoyage vous-même est certainement nécessaire, mais encore une fois, mieux vaut être patient avec cela. Si vous commencez trop vite, vous pouvez aliéner les autres membres de l'équipe qui peuvent le considérer comme une critique personnelle. Entrer également dans le nettoyage / refactoring complet du code peut être considéré par votre responsable comme un signe que vous n'êtes pas suffisamment concentré sur la tâche réelle. Vous devriez donc obtenir un mandat de refactorisation avant de vous lancer dans un processus plus sérieux. Cependant, de petits changements locaux sont probablement OK.

De plus, pour convaincre la direction, vous avez besoin d'une justification commerciale. La direction est rarement émue par les descriptions de l'incohérence du style de codage. Vous devez leur montrer quelle valeur les changements proposés peuvent apporter à l'entreprise - l'essentiel est l'argent. Si vous pouvez faire un calcul convaincant sur le coût par rapport aux avantages à long terme des diverses modifications proposées et montrer que l'équilibre global est clairement du côté positif, vous avez sensiblement amélioré vos chances.

Fais le toi-même. Si vous appréciez certains styles de codage, travaillez sur du code qui viole les styles de codage . Extraire un morceau de code incriminé du contrôle de code source, reformater le code selon l'exigence d'espaces blancs du style (à titre d'exemple) et valider le code mis à jour avec le message «Conformez-vous à la règle du guide de style sur les espaces blancs».

Après une semaine, la pire chose que vous puissiez faire est de vous adresser directement à la direction. Selon toute vraisemblance, ils ont consacré beaucoup de temps au code et en sont fiers. Vous vous en sortiriez probablement comme un sévère «tout savoir».

Ce que je ferais si j'étais vous, c'est de l'améliorer au fur et à mesure. Au fur et à mesure que vous vous familiariserez avec lui et que vous en travaillerez davantage, vous aurez la possibilité de l'améliorer. C'est à ce moment-là que je commencerais à montrer les avantages de ce que vous faites à d'autres collègues. Après cela, lorsque les réunions de conception arriveront pour de nouveaux modules, présentez un argument pour ce que vous percevez comme la meilleure façon.

Et honnêtement, les normes existent pour une raison mais, si cela fonctionne et fonctionne bien, cela vaut 100 fois plus dans mon livre (surtout après une semaine). Je serais plus inquiet si vous ouvriez le code et voyiez des tonnes d'erreurs logiques ou quelque chose de ce genre.

Ne vous adressez pas directement à la direction avec ce «problème».

Tout d'abord, parlez à vos collègues et découvrez auprès d'eux pourquoi les choses sont comme elles sont. Ensuite, vous pouvez mieux évaluer s'il y a un problème ou non. Vous pourriez être surpris de ce que vous apprenez. Vous pouvez également trouver des alliés pour le nettoyer.

Si vous ne savez pas comment vous en êtes arrivé là où vous vous trouvez, cela rend la sortie beaucoup plus difficile.

Beaucoup de bonnes suggestions ici déjà, et je suis de l'avis de ne pas brûler vos ponts jusqu'à ce que vous ayez fait vos preuves comme les autres. Ce que j'ajouterais, c'est de discuter des choses avec vos coéquipiers bien avant de les aliéner en allant d'abord au chef de projet ou au chef d'équipe. Et certainement montrez-leur avant cela, que vous devez être pris au sérieux.

Il semble aussi que c'est plus un problème de style que vous rencontrez avec le code. Reprendre le code de quelqu'un d'autre et se tenir le nez tout en s'habituant à la façon dont il l'a écrit n'est qu'une partie du travail, même si c'est une chose triviale comme la façon dont il le formate. Remettre l'un de vos `` bébés '' à quelqu'un d'autre pour qu'ils le manipulent avec leurs mains sales est encore pire ...

Si c'est en fin de compte plus que cela - et que le problème est plus fonctionnel que simplement stylistique - si vous allez au chef d'équipe / pm, il est préférable d'exposer le besoin de retravailler en termes où cela permettrait d'économiser de l'argent et des efforts à l'avenir Projet de développement. Bon vieux refactoring.