Comment puis-je communiquer à un collègue que son code ne fait rien?
Reste avec moi ici. Quand je dis que le code "ne fait rien", je veux dire quelque chose comme la fonction suivante:
void factorial(int n)
{
int result = 1;
for(int i = 1; i <= n; ++i)
{
result *= i;
}
}
Bien sûr, cette fonction crée une variable locale et calcule une valeur, mais elle ne fait rien pour faire avancer le programme; il n'y a aucun moyen d'utiliser le résultat du calcul et il n'a pas d'effets secondaires.
Gardez à l'esprit qu'il s'agit d'un exemple artificiel aux fins de la question, mais le code auquel je fais référence peut être plus compliqué.
Lorsque je rencontre un tel code, je passe souvent un peu plus de temps et je le revois plusieurs fois, car je crains de manquer quelque chose. Je pourrais simplement prendre la route haute, ou corriger le bug et en finir, mais je crains que ce ralentissement ne se répercute mal sur moi et mes performances.
Alors, dois-je prendre la route haute et supposer que l'équipe comprend, ou dois-je communiquer que le code ne fait pas grand-chose? Si ce dernier est la meilleure option, comment faire sans être condescendant ou irrespectueux?
La façon la plus simple est de demander à partir d'un point de non compréhension et de demander leur avis. Ce n'est pas bon de dire "votre code est nul", c'est tout autre de dire "euh, j'ai vu ça et je ne comprends vraiment pas ce qu'il fait, ni pourquoi il le fait. Qu'en pensez-vous?" ou similaire - vous pourriez dire quelle est votre préoccupation et leur demander de vous l'expliquer, ou leur demander si vous avez raison.
De cette façon, vous les intégrez à la solution et réalisez généralement le problème et le résolvez vous-même (ou vous pouvez proposer de le faire pour eux).
Je suis sûr que vous avez écrit du code comme ça vous-même, vous ne le voyez pas tant que quelqu'un ne l'a pas signalé et que vous n'avez pas un moment d'oh. Traitez un tel code non pas comme une énorme erreur flagrante, mais comme une autre légère bite que nous faisons tous de temps en temps et vous serez bon.
Le but de tout le code est finalement d'affecter le monde en dehors du programme d'une certaine manière. Personne ne se soucie du contenu des cellules de mémoire ou des registres CPU; ils ne se soucient que de la page imprimée ou des informations affichées sur un écran. Si le code n'entre/ne produit rien et ne modifie pas l'état du programme d'une manière qui pourrait éventuellement provoquer des E/S, il est par définition superflu.
Mais comment voir ça? Le moyen le plus simple consiste à effectuer des tests unitaires. Ce code ne peut satisfaire aucun test qui vérifie les valeurs factorielles réelles à calculer, car la seule valeur que est calculée ne sort jamais de la fonction. Écrivez simplement un cas de test qui codifie ce que le code devrait faire, et il devient trivial de démontrer qu'il ne le fait pas. (Certes, ce n'est pas la principale raison pour laquelle les gens préconisent généralement le développement piloté par les tests, mais cela fonctionne très bien à cette fin également.)
Reste avec moi ici. Quand je dis que le code "ne fait rien", je veux dire quelque chose comme la fonction suivante
Le terme correct pour ce type de code source est incomplete. Vous pourriez dire à un autre programmeur "Après avoir examiné votre code source, j'ai trouvé une fonction incomplète. Pouvez-vous clarifier son intention?"
Un travail incomplet fait son chemin dans les produits de production tout le temps. Il y a plusieurs raisons possibles à cela.
- Le développeur a poussé ces modifications par erreur.
- Le développeur avait besoin de mock fonctionnalité jusqu'à ce qu'elle puisse être terminée plus tard.
- Le développeur n'a pas pu terminer le travail, mais l'a quand même poussé.
Lorsque je rencontre un tel code, je passe souvent un peu plus de temps et je le revois plusieurs fois, car je crains de manquer quelque chose. Je pourrais simplement prendre la route haute, ou corriger le bug et en finir, mais je crains que ce ralentissement ne se répercute mal sur moi et mes performances.
Votre confiance en vous et votre efficacité au travail ont rien à voir avec le travail produit par d'autres personnes. Les processus, la qualité du code source, l'assurance qualité et le style de gestion d'une entreprise sont hors de votre contrôle (sauf si cela fait partie de votre travail de les modifier). Essayez de séparer ces éléments de la façon dont vous percevez vos propres performances et valeur.
Alors, dois-je prendre la route haute et supposer que l'équipe comprend, ou dois-je communiquer que le code ne fait pas grand-chose? Si ce dernier est la meilleure option, comment puis-je le faire sans être condescendant ou irrespectueux?
Ce que vous demandez ici n'a rien à voir avec la programmation informatique.
Je demanderais ceci sur le https://workplace.stackexchange.com/
Vous obtiendrez probablement des réponses sur la façon de travailler efficacement en équipe.
- Mettez 100% de vos efforts dans votre travail. Personne ne peut vous reprocher si vous avez fait de votre mieux. Attendre plus que ce que vous êtes capable de faire n'est qu'une gestion stupide. Essayer de travailler rapidement vous fait échouer plus vite.
- Communiquez de manière constructive avec les membres de votre équipe. Exprimez-vous et exprimez-vous.
- Écoutez ce que les membres de votre équipe ont à dire.
- Ne soyez pas un loup solitaire. Aidez l'équipe à résoudre les problèmes.
- Partagez ouvertement avec les membres de votre équipe. Partagez vos idées, vos pensées et vos préoccupations. N'attendez pas que quelqu'un vous le demande. Faites un effort pour partager.
- Proposer de l'aide. Si vous trouvez un travail incomplet. Offrez de le terminer.
- Soyez plus flexible. Plutôt que de se plaindre de problèmes. Réfléchissez à la raison pour laquelle ces problèmes existent et acceptez-les. La plupart des gens stressés par un projet le font pour des choses qu'ils ne peuvent pas changer.
- Soyez toujours respectueux, solidaire et honnête avec les autres membres de l'équipe. Vous n'obtiendrez peut-être pas la même chose en retour, mais vous apprendrez la valeur de ces traits.
Si rien ne sort ou n'est référencé en dehors de la portée du système que le code représente, cela n'a aucune utilité. Il vous suffit de tracer une ligne autour de l'ensemble du système et de mettre au défi le développeur obstiné de montrer où il est réellement traversé.
Demandez au développeur de vous guider à travers le code dans la session de révision de code et demandez-lui quel était son processus de réflexion autour de lui. Voyez s'il reconnaît le comportement superflu. S'il ne le fait pas, posez-lui des questions précises à ce sujet. Peut-être un peu plus détourné, mais pas aussi conflictuel.
Je crains que ce ralentissement ne se répercute mal sur moi et mes performances.
Si l'amélioration du code que vous trouvez vous fait du mal, alors vous avez un problème beaucoup plus important dans votre équipe que la façon exacte dont vous soulevez les problèmes que vous trouvez! OK, s'il n'est pas cassé, vous n'avez pas avoir pour le réparer, mais pour un code redondant authentique, c'est probablement une bonne idée de simplifier en le supprimant. Les estimations de temps devraient être basées sur la réalité pratique de la compréhension du code au fur et à mesure et de la résolution des problèmes que vous rencontrez. Si vous êtes en mode crise et que vous ne pouvez pas faire cela, alors la réponse serait "baissez la tête et espérez le meilleur", mais cela devrait être rare.
Le code redondant n'est pas le pire problème que vous puissiez trouver, mais il indique une erreur dans la pensée de celui qui l'a écrit (ou l'a modifié pour devenir redondant). Par conséquent, il mérite au moins autant d'attention que tout autre refactor potentiel que vous découvrez dans le code que vous visitez, et peut-être plus.
dois-je prendre la grande route et supposer que l'équipe comprend
Vous faites partie de l'équipe, vous ne comprenez pas, donc tout le monde ne comprend pas. Ne présumez pas qu'il existe un mystère plus élevé que tout le monde connaît. Beaucoup plus probable, personne ne voudrait que ce soit comme ça et tout le monde ne l'a pas remarqué ou n'a pas réussi à l'améliorer. Ou vous vous trompez. Dans ce dernier cas, vous bénéficierez d'une explication de votre erreur, dans le premier cas, quelqu'un d'autre en bénéficiera.
dois-je communiquer que le code ne fait pas grand-chose?
Selon ce que votre équipe pense de la "propriété" du code, il se peut que la bonne chose à faire soit simplement de le corriger et (si le changement ne parle pas de lui-même) d'en discuter lorsque vos modifications sont examinées. Alternativement, il peut y avoir quelqu'un dans l'équipe qui est la personne évidente à qui en parler avant d'aller de l'avant avec un changement, soit l'auteur ou quelqu'un d'autre avec une responsabilité particulière. Lorsque vous parlez à quelqu'un, que ce soit le propriétaire ou un réviseur de code, il ne vous reste plus qu'à décider quoi dire.
Si vous êtes à l'aise pour tirer directement de la hanche:
"Ce code ne fait rien"
"Vous avez oublié de retourner le résultat, dois-je le réparer?"
"Cette fonction void n'a pas d'effets secondaires, à quoi ça sert?"
Naturellement, cela peut être considéré comme impoli, cela dépend vraiment de votre relation avec la personne. Vous pouvez donc être plus diplomate:
"Que fait ce code?"
"Le résultat est-il nécessaire n'importe où ou pouvons-nous sauter cette partie?"
"Cela semble faux, donc je ne suis pas sûr d'avoir tout compris"
"Je suis terriblement désolé de vous déranger, mais je n'ai pas pu comprendre ces quelques lignes de code. Il me semble que cette fonction ne fait rien, alors je me demandais pourquoi. "Je l'ai mal compris, ou je suppose qu'il pourrait être là pour soutenir une direction future, auquel cas je me demandais si je pouvais utilement ajouter quelques commentaires pour expliquer quoi".
Naturellement, le dernier exemple trace une ligne fine entre poliment obséquieux et tout simplement condescendant. Certaines personnes parlent bien comme ça, d'autres ressemblent à des sarcastiques.
Personnellement, je choisis généralement "Est-ce censé ne rien retourner?". J'attends la réponse "non". C'est intentionnellement quelque peu impoli/plaisantant, parce qu'avec mes collègues actuels je peux l'être, mais je n'accuserais personne de quoi que ce soit au-delà d'un oubli. Et si la réponse est "oui" avec une raison, alors assez juste. Une autre option courante pour moi est "Je pense que cela devrait retourner quelque chose". Ce sont des choses que je serais heureux de me dire.
J'aurais préféré poster ceci comme un commentaire hélas, je suis à court de représentant.
Dans mon monde, si je ne peux pas directement tracer un morceau de code à une exigence documentée ou à une exigence dérivée, je le signale pour une révision d'équipe qui se produit toutes les deux semaines ou au besoin.
// REVIEW: 05/19/2015
// Can't find the need for this code. Perhaps it's been orphaned?
// Need to identify the requirement associated or remove it.
public static bool WouldYouLikeToDance(this Person you, Person dancePartner)
{
// determine minimum acceptable attractiveness
int minAcceptable = you.SelfWorthAndRespect - (you.CountDrinksConsumed() * 0.10);
return (minAcceptable <= dancePartner.Attractiveness);
}
Je trouve qu'il vaut mieux ne pas les confronter directement, simplement identifier les préoccupations de manière anonyme et s'attendre à ce qu'ils fassent de même pour vous. Pendant l'examen de groupe, vous pouvez peser avec l'équipe en tant que contrôle pour vous assurer que vous n'identifiez pas par erreur quelque chose de valide. L'objectif global est la qualité du code et, comme effet secondaire, l'amélioration des compétences de chaque développeur et de l'équipe dans son ensemble.
Si ce code est présenté lors de la révision du code, il semble que vous ayez peu de problèmes; indiquez simplement que vous ne savez pas exactement ce qu'il fait et demandez un test unitaire.
Si ce n'est pas lors de la révision du code, vous voudrez peut-être non seulement réfléchir à la façon de corriger le problème immédiat, mais également rechercher une solution plus approfondie en termes de changement de processus.
L'un des éléments suivants peut détecter ceci:
- Niveaux d'avertissement appropriés au moment de la compilation, associés à une exigence d'avertissement zéro sur le code.
- Un processus de révision du code
- Couverture suffisante des tests unitaires.
- Normes de commentaire
Maintenant, le simple fait que vous ayez ce problème me suggère que certains membres de votre équipe ne sont peut-être pas doués pour lire le code. Malheureusement, mais dans le monde réel, c'est très courant.
Je noterais que les pratiques ci-dessus sont utiles même dans une équipe très forte (les commentaires sont discutables).
Cependant, la chose utile sur les pratiques ci-dessus qui sont particulièrement utiles dans une équipe plus faible; ils fournissent un cadre pour aider à améliorer la qualité du code sans qu'il devienne personnel.