Comment puis-je demander à mon patron (de manière polie) de commenter son code?

Mon patron m'enseigne (je viens de terminer mes études et il cherchait quelqu'un avec un peu d'expérience en programmation. Il m'a donc choisi pour me former à ce que cette entreprise se spécialise) et a commencé à travailler avec des applications ASP.NET MVC , du HTML et du CSS. . Je suis d'accord avec les éléments de conception de sites Web qu'il me donne (c'est assez simple à comprendre sans clarification).

Mais par exemple, il me confie une tâche avec ASP.NET MVC, il l'explique très bien. Mais il n'explique rien dans le code qu'il vient de me donner. (Nous utilisons le contrôle de source dans Visual Studio 2013 ). Il s'agit donc littéralement de centaines de lignes de code, sans aucune information sur ce qu'il est censé faire. Le type de code que je vois est un code que je n'ai jamais vu auparavant, il est donc très difficile d'essayer de le comprendre.

J'essaierais de lui poser plus de questions, mais il travaille toujours (c'est sa propre affaire) et j'ai l'impression qu'il risque de se fâcher de toutes ces questions que j'ai entre les mains.

Alors, juste quelque chose qui m'aidera jusqu'à ce que je comprenne bien, comment puis-je demander à mon chef d'insérer des commentaires dans son code qu'il me donne, mais poliment?

Vous êtes dans la partie profonde et, à mon avis, c'est la meilleure façon d'apprendre. Non pas parce que vous regardez des choses dont vous n'avez pas la moindre idée, mais parce que cela vous oblige à faire preuve de plus de ressources et à découvrir quels composants jouent quel rôle dans un système dans lequel vous êtes nouveau.

Cela n'aide pas que votre patron soit trop occupé pour traiter quelqu'un qui est curieux (et vous avez tout à fait le droit de le faire; vous avez envie d'apprendre, ce qui est bien). Mais, malheureusement, demander à votre aîné de modifier son style et son approche dans l’intérêt de votre apprentissage n’est peut-être pas très utile, d’autant plus que vous avez affaire à une personne que vous dites occupée.

Être assis devant des milliers de lignes de code que vous ne connaissez pas est la norme. Vous ne pouvez pas toujours l'expliquer en noir et blanc avec des commentaires. Cependant, pour apprendre tout en débutant, si vous sentez que vous devez absolument lui demander des commentaires, expliquez peut-être pourquoi. Expliquez que c'est parce que vous ne voulez pas le déranger car il est souvent occupé. Non seulement cela vous semblera moins comme si vous lui demandiez de faire quelque chose, mais cela ouvrait également la discussion aux discussions sur la façon dont il pourrait plutôt préférer laisser de côté la question.

Tout d'abord, parcourir des milliers de lignes de code non familier et se sentir perdu, voilà comment se trouve chaque projet de logiciel, partout dans le monde, depuis le début des temps.

La plus grande différence entre vous et un programmeur expérimenté est que vous n'êtes pas habitué.

Quelques points à garder à l'esprit:

1. Avec suffisamment d'effort, chaque morceau de code est compréhensible. Beaucoup de gens se sentent frustrés s'ils n'arrivent pas à trouver une solution en quelques minutes. Sois plus patient que ça.

2. Un bon patron est aussi ouvert que possible aux interruptions et aux questions. Un bon employé s'efforce autant que possible de minimiser les interruptions et les questions. Soyez conscient de cela.

3. Les interruptions sont plus coûteuses que les questions. Vous pouvez mieux utiliser votre temps et celui de votre chef en consolidant vos discussions et en ne mettant jamais fin à une conversation avec confusion.

4. Votre patron est un meilleur programmeur que vous. (Probablement.) Cela ne veut pas dire que vous ne pouvez pas être plus fort dans certains domaines, mais dans l'ensemble, son expertise est plus grande. Jusqu'à ce que vous ayez beaucoup d'expérience, assurez-vous de tirer le meilleur parti de son expertise.

5. Si vous êtes certain que plus de commentaires aideraient considérablement le code, demandez à votre patron. "Il m'est difficile de comprendre ce qui se passe à certains endroits. Lorsque je découvre des choses, cela ne vous dérange-t-il pas d'ajouter des commentaires?" Peut-être qu'il déteste les commentaires. Peut-être qu'il va l'aimer. Peut-être qu'il sera indifférent.

À la fin, cependant, il est possible que dans quelques mois, vous vous souveniez avoir posé cette question et réfléchi: "Euh, je me demande avec quoi j'ai eu un problème? Ce n'est pas si grave. Hm, eh bien, peu importe."

Si votre patron n'a pas le temps de répondre à toutes vos questions, pourquoi pensez-vous qu'il aura le temps de commenter son code hérité? Et d'ailleurs, qu'est-ce qui vous fait penser que ses commentaires décriraient vraiment les éléments que vous ne comprenez pas pour l'instant? D'après mon expérience, essayer de changer le style de programmation de vos patrons en leur demandant simplement ne fonctionnera pas, que ce soit poli ou non.

La meilleure chose à faire dans une telle situation: commentez les parties du code que vous devez comprendre pour faire votre travail par vous-même. - Une fois que vous avez compris ces éléments, bien sûr, et après avoir obtenu l’engagement de votre patron que tout ira bien. Si vous ou votre patron craignez de perdre quelque chose en ajoutant des commentaires, ajoutez-les dans une branche distincte et demandez à votre patron s'il prendra le temps de revoir vos commentaires avant qu'ils ne soient fusionnés avec le coffre. Étant donné que votre chef n’a qu’un budget de temps limité, essayez de déterminer ce que vous faites d’abord en investissant un laps de temps raisonnable. Si vous êtes vraiment bloqué, écrivez votre question dans une liste et demandez à votre patron, par exemple, une fois par jour au lieu de le déranger 30 minutes. D'après mon expérience, cette approche fonctionne avec la plupart des gens, même s'ils sont très occupés, à condition qu'ils soient disposés à vous aider - ce qui est sûrement le cas dans votre cas.

De cette façon, vous êtes sûr d'obtenir les commentaires dont vous avez besoin et votre supérieur hiérarchique verra où vous avez besoin d'informations supplémentaires et si vous avez les choses bien. Et tant que vous vous limitez à ne commenter que les choses non évidentes, il y a de bonnes chances que vos commentaires augmentent la qualité générale de la base de code, ce qui pourrait, non seulement être profitable pour vous, mais aussi pour tous les autres qui doit traiter avec le code, y compris votre patron.

Premièrement, laissez ceci être un exemple pour vous afin de commenter votre code correctement, sauterelle!

Ensuite, je dois le faire tout le temps. Je vérifie ma copie locale, je la parcoure et la commente moi-même. (Je peux les effacer tous si je vais y revenir ou les laisser entrer si personne ne le fait.) Alors quand je ne peux vraiment pas voir plus loin, je peux demander à quelqu'un, ici, je pense que oui. ça (ce que j'ai commenté), ai-je raison? Donc, vous avez peut-être fait les commentaires, mais c'est fait et c'est le but.

C'est plus qu'une simple demande personnelle. Vous essayez de changer les habitudes / la culture, et ce n'est pas facile. Ce n'est certainement pas quelque chose qui peut être accompli par une conversation de couloir ou un courrier électronique. Cela va demander un effort de votre part.

Soyez le changement que vous souhaitez voir dans le monde.

La citation peut être faussement attribuée au Mahatma Gandhi, mais c'est un conseil applicable. Pendant que vous essayez de déchiffrer la base de code, écrivez les commentaires que vous aimeriez voir le mieux possible et validez-les, après avoir été revus par votre patron. Avantages:

• Vous êtes proactif plutôt que harcelant.
• Vous donnez un bon exemple. Dans le meilleur des cas, votre patron / équipe verra les avantages et suivra.
• Certains commentaires diront probablement /* Mystery parameter 3 */ou /* 2015-02-09 AidanQuinn: Is this code ever called? */- c’est une opportunité pour vos collègues de documenter correctement le code ou de corriger des bogues cachés.
• Si, lors de l'examen préalable à la validation, il s'avère qu'un commentaire que vous avez écrit est inexact, vos collègues savent maintenant que le code n'était pas clair.

Abstenez-vous de toute réécriture ou refactorisation, et l'introduction de commentaires ne devrait présenter pratiquement aucun risque. Si vous réécrivez quoi que ce soit, conservez ces modifications séparément.

(Cependant, avant de vous lancer dans ce projet, assurez-vous que vos attentes en matière de commentaires sont raisonnables. Si votre idée de code bien commenté dépasse la norme ( Exemple 1 , Exemple 2 ), alors vous ne pourrez que vous ridiculiser. toi même.)

Je ne demanderais pas de commentaires supplémentaires, mais voici quelques idées pour vous:

1. Planifiez une réunion avec votre patron et demandez-lui de lire le code à un niveau élevé. Cela devrait vous aider à démarrer. Je m'attendrais à quelques heures à peut-être une demi-journée pour que vous puissiez vous mettre à niveau. Cela devrait inclure la conception générale, les modèles utilisés, etc.
2. Créez un projet de tests et commencez à écrire des tests unitaires par rapport au code. Cela vous aidera à le comprendre sans l’impacter. Vous pouvez également trouver des bugs aussi!
3. Déboguez le code selon vos besoins pour comprendre certaines zones.
4. Supprimez l'arriéré des améliorations ou des bogues et travaillez dessus.

Les commentaires sont OK, mais si le code est écrit d'une manière simple, il devrait être compréhensible après quelques jours.

Aussi, ne vous attendez pas à tout comprendre, il est préférable de se concentrer d'abord sur les domaines clés, puis d'étendre les connaissances de la base de code si nécessaire.

Je suis dans une situation très similaire à la vôtre il y a environ un an. J'ai commencé à travailler avec une petite expérience de la programmation (bien que je connaisse un peu le langage OO et quelques autres langues) et la personne qui m'a enseigné a eu très peu de temps. Il a toujours été utile, mais j'avais l'impression de ne pas vouloir poser toutes les questions que j'avais.

D'autres ont déjà suggéré des trucs extrêmement utiles ici (écrire des tests unitaires par exemple, mais d'après ma propre expérience, c'est quelque chose qui serait allé un peu trop loin pour moi à partir de zéro; ou commenter vous-même des parties du code, difficile en fonction du premier point / question que je vais vous poser dans une minute). Les points suivants résument ce que j’ai fait et ce qui m’a aidé, mais cela dépend en grande partie de vos problèmes.

De plus, je suis d'accord avec @AK_ pour dire que vous n'avez pas vraiment besoin de commentaires en C #. Cela n’est peut-être pas correct à 100% (j’estime qu'il existe des domaines dans lesquels les commentaires sont vraiment utiles, par exemple le code à réflexion intense), mais c'est en réalité le cas. Si vous écrivez vraiment du «code propre» avec des méthodes et des variables bien nommées et que vous avez beaucoup de petites «bites» de code, elles seront presque totalement inutiles. Chaque fois que j'ai ressenti le besoin de commenter en lisant le code jusqu'à présent, après avoir compris ce qu'il faisait, j'étais très mécontent de la façon dont cela était fait et pensais que cela aurait pu être beaucoup plus clair en premier lieu grâce à une bonne refactorisation. Edit: je parle spécifiquement de commentaires C # ici, pas de documentation (document séparé ou commentaires XML), car je pense que la documentation est toujours importante.

• Identifiez quels sont exactement vos problèmes et si vous pouvez les catégoriser. En d'autres termes, avez-vous toujours des problèmes avec le langage lui-même ou ne comprenez pas une syntaxe spécifique (par exemple, les expressions lambda et LINQ en général, ou Reflection)? Si vous ne comprenez pas les lignes de code, vous ne comprendrez pas ce que fait la méthode / le bloc dans son ensemble. Il sera donc difficile de le commenter vous-même. Procurez-vous plutôt un bon livre ("C # in a Nutshell" c'était pour moi, mais j'ai entendu dire que "C # in Depth" est également spectaculaire) et lisez ce qui se passe. La catégorisation préalable de ces problèmes facilite la tâche, car vous pouvez combler «de plus grandes lacunes» en même temps, ou même interroger votre supérieur à ce sujet, car il ne s'agit plus de beaucoup de questions, mais plutôt d'expliquer un seul sujet ou les constructions les plus couramment utilisées afin peut avoir un énorme 'boost'

• Parallèlement à ce qui précède, j'ai essayé de me familiariser avec le «codage propre» et les meilleures pratiques générales (non spécifiques à une langue). L'effet de ceci peut ne pas être immédiat, mais cela rapportera tôt ou tard, que ce soit pour étendre des éléments existants ou se demander pourquoi quelqu'un a créé autant de petites méthodes au lieu d'une méthode où tout est contenu ;-)

• Découvrez les modèles de conception courants. Ils peuvent apparaître ici et là dans le code que vous lisez, et si vous les reconnaissez, cela vous donnera immédiatement un moment a-ha. Même si vous comprenez ce que le code que vous voyez là-bas fait, vous pouvez vous demander pourquoi il est fait de cette façon, et trouver tout cela par vous-même n'est souvent pas si facile.

S'il vous plaît, ne prenez pas le texte ci-dessus comme une hypothèse sur votre "compétence", je passe souvent par hasard entre parler de mes expériences et parler "avec vous". C'est surtout ce que j'ai rencontré et ce que j'ai fait . Comme d’autres l’ont déjà dit, cela peut être une très bonne expérience et c’est plutôt la norme dans ce travail de lire du code qui n’est pas le vôtre et que vous ne connaissez pas très bien à l’avance. Mais il peut être très satisfaisant de comprendre enfin ce qui se passe là-bas et de reconnaître que vous vous améliorez grâce à cette "compétence" particulière. Profitez-en pour apprendre beaucoup en très peu de temps, bonne chance! :)

Vous n'allez probablement pas le faire changer de style.

Ce que vous pouvez faire, c'est poser beaucoup de questions et noter les réponses.

Lors de mon dernier travail, j'ai hérité d'une base de code énorme, de peu de documentation et peu de commentaires. Donc, j'essayerais pendant une demi-heure sur le même problème, puis si je ne pouvais toujours pas le résoudre, j'irais demander à quelqu'un qui l'écrivait ou savait comment l'utiliser. Ensuite, je documenterais tout ce qu'il m'a dit. La plupart sont allés dans notre documentation, certains dans le code en tant que commentaires. Au bout d’un an, j’avais pratiquement écrit une grande partie de notre documentation et je connaissais beaucoup de choses sur le code de base.

Bonne chance!

J'avais le même problème. Im étudiant de phyzist et avoir une bonne expérience de programmation. Je programmais dans de nombreuses langues mais rien pour une application premium.

J'ai postulé pour un poste de développeur Web et ils m'ont instantanément mis au service de la programmation Web. Lorsque le patron m’a montré l’API de base pour l’application de nœud REST, je pensais que je jetterais. Je n'ai jamais vu de fonctions avec callback et une syntaxe si étrange. Et je demande à mon chef si j'ai un problème si je ne comprends rien dans le code. Il est triste non, il est triste que j’aie un mois pour le découvrir et que je prépare un CMS pour me tester avec un autre frontender.

Eh bien, j’ai lu une ligne de code à la fois et j'ai tout mis en évidence sur Google. Donc, 1 semaine a été passée et je connaissais suffisamment le code pour pouvoir collaborer avec FrontEnder. Mon code au début était de la merde mais me voir 3 mois après ça! Je code mieux et plus vite que notre architecte logiciel!

Je suppose que vous n'arrêtez jamais d'apprendre! Ma devise -> Continuez à apprendre et gardez votre calme :) Ne vous fiez pas au chef, soyez indépendant et posez-lui des questions directement, mais seulement sur les problèmes les plus difficiles. Parce que vous serez heureux après l’avoir déterminé par votre propre recherche. Et rappelez-vous quand vous arrêtez d'apprendre quelque chose qui ne va pas, apprenez chaque jour comment devenir un bon programmeur.

Si vous apprenez de la part du patron, vous n'irez jamais mieux que de définir votre propre standard, apprenez à taper à l'aveugle, au plug-in VIM ou VIM pour votre IDE, Linux wmii, afin que vous dépassiez un jour votre réputation de patron et soyez meilleurs que lui!

En tant qu’ingénieur logiciel depuis 20 ans, travaillant principalement sur des sujets liés à la sécurité (SF-PD), je dois dire que votre patron n’est peut-être pas la personne que vous voulez être votre exemple. Le manque de commentaires est le signe d’un programmeur amateur autodidacte qui n’a jamais appris à bien faire son travail ou d’un ingénieur inexpérimenté. Ou peut-être un ingénieur qui n'a tout simplement pas le temps - les délais et les délais peuvent faire des choses horribles pour votre code! ;) C'est cependant un anti-modèle pour chaque ingénieur logiciel compétent.

Votre patron est peut-être un très bon codeur, mais on dirait qu'il n'est pas un bon ingénieur en logiciel. Un ingénieur utilise l’expérience d’un groupe pour éviter les pièges qui ont déjà attiré d’autres personnes. Des commentaires efficaces font partie de cette expérience collective collective de logiciels, de la même manière que l'analyse de stress fait partie de l'expérience collective de groupe en génie mécanique. Ce qui compte comme commentaire efficace est plus fluide, et c’est certainement quelque chose que vous obtenez par expérience.

La chose la plus fondamentale est que les commentaires ne doivent pas dire ce que fait une ligne de code. Il arrive parfois que les commentaires expliquant ce que fait une fonction sont également superflus (en particulier en C #). Les commentaires excessifs peuvent être tout aussi inefficaces (et indiquer un manque d'expérience), car vous ne pouvez pas trouver les éléments importants dans les scories. En tant que novice, vous pouvez toujours essayer de déterminer le "quoi" du code, et pour cela, il vous suffit de lire et de comprendre ce qu'il a fait.

Cependant, l’important pour les commentaires est qu’ils disent POURQUOI une ligne de code ou une fonction fait ce qu’elle fait, là où cela n’est peut-être pas évident. Avez-vous besoin de configurer le module X avant le module Y? Est-il important de vérifier un code de retour pour voir si un fichier était déjà ouvert, ou ignorons-nous consciemment le code de retour parce que cela a été vérifié ailleurs? Le "pourquoi" du code sera pertinent pour tout le monde, quelle que soit l'expérience - et ce le sera aussi pour lui dans 6 mois, lorsqu'il aura oublié la bonne raison de faire quelque chose d'une manière particulière. Les commentaires ne concernent pas uniquement les autres, ils vous aident également à l'avenir.

Si vous voulez éviter d'ennuyer votre patron, posez des questions intelligentes. Concentrez-vous sur le "pourquoi" et essayez de déterminer vous-même le "quoi" (à moins que ce soit vraiment obscur). On ne posera pas de questions à un bon patron s’il n’est pas le genre de choses que vous auriez pu trouver dans R-ing TFM. Et aucun bon ingénieur ne voudra se faire demander de faire quelque chose qui facilitera considérablement la vie d'un autre ingénieur, à moindre coût. (Ne lui demandez simplement pas de renvoyer des commentaires sur l'ensemble du code!;)

Été dans la même situation, je dirais

1. Votre patron voudra peut-être que vous appreniez la mauvaise voie (en parcourant le code dont vous n’avez aucune idée) pour une raison. C’est ainsi que nous apprenons plus en un mois de travail qu’en un an au collège, comme indiqué dans d’autres réponses.

2. C'est "la norme" comme mentionné dans d'autres réponses. Vous devriez être plus préoccupé par où commencer et comment aborder et sur quoi vous concentrer que d'essayer de comprendre immédiatement chaque ligne de code. Demandez à votre patron quels sont les bons outils et les moyens de déboguer / de parcourir le code. Ce genre de questions vous rapportera des points.

3. Sur une base régulière, continuez de contacter votre patron pour savoir comment vous vous en sortez afin de vous donner une idée de la position en centile en supposant que votre patron a vu un bon nombre de personnes dans la même situation et en avoir une idée.

4. Prenez cela comme une opportunité et, au fur et à mesure que vous comprenez mieux le code, continuez à ajouter des commentaires que vous vous attendiez à l'origine à demander à votre patron.

Si vous voulez vraiment essayer de lui demander de mettre des commentaires dans son code (je ne le recommande pas), je vous suggérerais de trouver le code que vous devez modifier qui pourrait vraiment utiliser certains commentaires (la plupart s'expliquent d'eux-mêmes) et poser la question à propos de comme ceci "J'examinais ce code ici et j'essayais de comprendre [le problème que vous rencontrez] et je ne pouvais trouver aucun commentaire pour aider à l'expliquer". Essentiellement, essayez de montrer que vous avez fait des efforts pour le comprendre et expliquez pourquoi vous pourriez tous les deux profiter de la présence de commentaires.

Probablement 90% du code bien écrit n'a pas besoin de commentaires. Vous ne voulez vraiment que documenter les parties de code optimisées et devenues plutôt tendues. Une fois, j'ai travaillé dans une entreprise qui vous demandait de documenter chaque élément de code que vous avez modifié. Les commentaires ont été de manière à nuire activement à la lisibilité du code, car ils faisaient souvent référence à du code qui avait été supprimé ou modifié de façon totalement injustifiable. Méfiez-vous des commentaires médiocres J'ai passé une semaine à déboguer une fonction et à la fin, j'ai constaté que le commentaire que je continuais à lire sur la définition de "tel" et "tel drapeau" sur "faux" était en réalité le problème dans son ensemble. comme il était supposé.

Si vous voulez que les commentaires dans le code comprennent pourquoi quelque chose a été écrit, il est fort probable que vous ne compreniez pas encore les besoins de l'entreprise (étant donné que vous êtes nouveau). Je suis sûr que vous connaissez la syntaxe et que vous pouvez lire le code, mais à moins de connaître le but de certains codes, vous vous sentirez un peu perdu.

Une chose qui vient à l’esprit est la programmation en binôme. Vous dites que votre patron est impressionné par vos progrès et vous pouvez donc suggérer de travailler à ses côtés. Cela vous aidera tous les deux à long terme. Votre patron devra expliquer des choses qu'il prend pour acquis et vous en apprendrez plus sur l'entreprise.

Comme d'autres l'ont mentionné, c'est assez courant, mais cela ne signifie pas que vous devez simplement le sucer et le traverser. Vous n'avez pas besoin de comprendre le code avec autant de profondeur que vous le pensez, et il existe des stratégies concrètes pour rendre la "partie profonde" beaucoup moins profonde:

• Trouvez quelque chose dans le code lié à la tâche à accomplir. Le plus facile à rechercher est généralement quelque chose de visible par l'utilisateur, comme le libellé du bouton sur l'interface graphique. Notez où vous l'avez trouvé. Ce sera votre point d'ancrage.
• Maintenant, recherchez le code à un pas de distance et notez-le. Qui crée le bouton? Quel code est appelé lorsque le bouton est cliqué?
• Le contrôle de source est souvent utile pour trouver du code à une étape de distance. Recherchez à quel moment le code que vous avez regardé a été ajouté ou modifié, et déterminez ce qui a été ajouté en même temps et pourquoi.
• Répétez l'opération jusqu'à ce que vous en ayez compris assez pour effectuer votre changement, plus un niveau plus bas pour vous assurer de ne rien manquer.
• Si vous êtes bloqué à un moment donné, vous avez maintenant une question très spécifique à poser. Par exemple, "je ne peux pas savoir d'où ce bouton est instancié".

Voici mon 0.02 $ sur la question. Je ne suggère pas une réponse exclusive, beaucoup de ce qui a été dit ici est tout à fait pertinent.

J'essaierais un peu d'ingénierie sociale pour arranger les choses de manière à ce que votre patron trouve qu'il est plus facile / moins fastidieux de commenter une partie de son code que de ne pas le faire.

Maintenant, cela peut être assez facile si vous êtes prêt à prendre un gros risque et à l’ennuyer - mais nous ne voulons pas le faire. (note de côté: vous pourriez tout simplement ne pas pouvoir faire quoi que ce soit sans qu'il écrive ou dicte des commentaires à votre sujet, vous insistez et le harcelez à ce sujet sans fin, etc.)

Quelle est l'alternative, alors? Quelques idées, selon les circonstances.

Option 1

1. Prenez le temps de comprendre qu'une partie de son code est X.
2. Maintenant, réfléchissez à un moyen raisonnable de ne pas le comprendre .
3. Dites au patron (par courrier électronique ou dites au petit-déjeuner ou ce qui ne l'est pas) que vous essayez actuellement de le comprendre.
4. Ajoutez un commentaire indiquant que la signification du code n'est pas claire, mais vous le comprenez en tant que Y; essayez de lui rendre ce commentaire visible - mais n'essayez pas trop fort!
5. Agissez en supposant que Y - et assurez- vous que votre patron remarque votre action (pour ne pas perdre votre temps à travailler pendant longtemps sur une fausse hypothèse).
6. Le patron devrait prendre l’initiative de vous corriger. À ce stade, dites-lui quelque chose comme: "J'aurais vraiment aimé que ce code contienne quelques commentaires pour m'empêcher de formuler des hypothèses erronées. Je vais corriger le commentaire que j'ai ajouté moi-même. Pensez-vous que vous pourriez m'aider avec une description générale Je ne suis pas assez expérimenté pour comprendre l'intention exacte, et je ne ferais que quelques phrases qui feraient l'affaire. " Ou quelque chose..

Option 2

Vous êtes en formation. Essayez d'organiser une réunion hebdomadaire (supplémentaire?) Avec lui. Lors de cette réunion, passez en revue certains codes - mais vous devez être suffisamment préparé pour qu'il ne soit pas obligé d'expliquer chaque ligne. À un moment donné - espérons-le -, il réalisera qu'il peut sauter la réunion s'il ajoute simplement les commentaires.

Option 3

Demandez à un autre collègue de ne pas comprendre le même morceau de code que vous. Vous abordez tous les deux le patron à différents moments en posant les mêmes questions. C'est un moyen infaillible de lui faire comprendre qu'il ne réussit pas à faire quelque chose ... mais tout le monde n'a pas le luxe d'avoir des collègues de travail utiles sur le même projet.

Alors, juste quelque chose qui m'aidera jusqu'à ce que je comprenne bien, comment puis-je demander à mon chef d'insérer des commentaires dans son code qu'il me donne, mais poliment?

Si vous ne comprenez pas le code, pourquoi pensez-vous que les commentaires sont votre solution?

Je ne connais pas son style de programmation, mais j'avoue que si le nom des fonctions et des variables est trompeur, il est très difficile de comprendre un code. Mais si les noms et les fonctions ou même l’organisation du programme (classes, méthodes, propriétés ...) sont tels que le code soit compréhensible, alors le code vous parlera tout seul.

Vous feriez mieux de lui demander l'architecture du programme et si vous voulez lui demander quelque chose, demandez des noms plus significatifs pour les fonctions; c'est plus pratique pour lui.

Même s'il existe un moyen de demander poliment ceci, il y a deux possibilités quant à ce que votre chef va penser des commentaires dans son code:

1. Soit les commentaires dans son code seraient une bonne chose, soit

2. Ce commentaire dans son code ne serait pas une bonne chose à avoir.

Si votre patron pense que les commentaires dans son code ne seraient pas une bonne chose (et qu'il existe d'excellents arguments, c'est -à- dire que le code est censé être la documentation et qu'aucune documentation ne stipulera jamais quelque chose d'aussi précis et aussi clair. comme le code qui le fait réellement ), alors rien ne se passera.

Maintenant, si par hasard votre patron pense que les commentaires dans son code seraient une bonne chose à faire, alors il y a une chance considérable qu'il vous dise d'étudier son code, de comprendre comment cela fonctionne, et d'ajouter des commentaires à ses commentaires. code toi-même . (Il existe également de très bons arguments, c’est- à- dire que vous devez apprendre , et son temps est par définition beaucoup plus précieux que le vôtre .)

Donc, à moins que vous ne soyez prêt à faire cela, vous feriez mieux de ne rien dire.