Comment puis-je demander à mon patron (de manière polie) de commenter son code?
Mon patron m'apprend (je viens de terminer mes études et il voulait quelqu'un avec une petite expérience en programmation, alors il m'a choisi pour me former sur les spécialités de cette entreprise) et a commencé à travailler avec ASP.NET MVC = applications, certains HTML et CSS. Je suis très bien avec le design web qu'il me donne (c'est assez simple à comprendre sans clarification).
Mais par exemple, il me donne une tâche à faire 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 code source dans Visual Studio 201 ), 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 pourrait être agacé par tous ces questions que j'ai sur mes mains.
Donc, juste quelque chose qui m'aidera jusqu'à ce que je comprenne les choses, comment puis-je demander à mon patron de mettre des commentaires dans son code qu'il me donne, mais poliment?
Vous êtes dans le "fin profond" et, à mon avis, c'est la meilleure façon d'apprendre. Non pas parce que vous regardez des choses dont vous n'avez aucune idée, mais parce que cela vous oblige à être plus ingénieux et à découvrir quels composants jouent quel rôle dans un système que vous êtes nouveau.
Cela n'aide pas que votre patron soit trop occupé pour gérer quelqu'un qui est curieux (et vous avez totalement le droit d'être curieux; vous êtes désireux d'apprendre, ce qui est bien). Mais, malheureusement, demander à votre personne âgée de changer de style et d'approche pour le bien de votre apprentissage peut ne pas aller trop bien, d'autant plus que vous avez affaire à quelqu'un que vous dites occupé.
Ê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 le plaisir d'apprendre pendant que vous êtes nouveau, si vous sentez que vous devez certainement lui demander des commentaires - peut-être expliquer pourquoi. Expliquez que c'est parce que vous ne voulez pas le déranger avec des questions car il est souvent occupé. Non seulement cela apparaîtra beaucoup moins comme si vous lui dites de faire quelque chose, mais cela ouvre également la parole à des discussions sur la façon dont il pourrait plutôt préférer poser une question en réservant du temps.
Tout d'abord, parcourir des milliers de lignes de code inconnu et se sentir perdu est la façon dont chaque projet logiciel est, partout, depuis le début des temps.
La plus grande différence entre vous et un programmeur expérimenté est que vous n'y êtes pas habitué.
Quelques points à retenir:
Avec suffisamment d'effort, chaque bit de code est compréhensible. Beaucoup de gens se sentent frustrés s'ils ne parviennent pas à comprendre quelque chose en quelques minutes. Soyez plus patient que ça.
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.
Les interruptions sont plus coûteuses que les questions. Vous pouvez mieux utiliser votre temps et celui de votre patron en consolidant vos discussions et en ne mettant jamais fin à une conversation confuse.
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 d'apprendre autant que possible de son expertise.
Si vous êtes sûr que plus de commentaires aideraient considérablement le code, demandez à votre patron. "Il m'est difficile de comprendre ce qui se passe à certains endroits. Quand je fais les choses, ça vous dérange si j'ajoute des commentaires?" Peut-être qu'il déteste les commentaires. Peut-être qu'il va l'adorer. Peut-être qu'il sera indifférent.
En fin de compte, cependant, il est possible que dans quelques mois vous vous souveniez d'avoir posé cette question et que vous pensiez: "Huh, 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 morceaux que vous ne comprenez pas pour l'instant? D'après mon expérience, essayer de changer le style de programmation de votre patron en lui demandant simplement ne fonctionnera pas, poli ou pas.
La meilleure chose que vous puissiez 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 parties, bien sûr, et après avoir obtenu un engagement de votre patron que ce sera ok. Si vous ou votre patron craignez de pouvoir casser 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 de les fusionner dans le coffre. Étant donné que votre patron n'a qu'un budget de temps limité, essayez de comprendre ce qu'une certaine partie fait d'abord par vous-même en investissant un temps raisonnable. Si vous êtes vraiment coincé, écrivez votre question sur une liste et demandez à votre patron, par exemple, une fois par jour au lieu de le déranger pendant 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, tant qu'ils sont prêts à vous aider - ce qui est sûrement le cas dans votre situation.
De cette façon, vous êtes sûr d'obtenir les commentaires dont vous avez besoin, et votre patron verra où vous avez besoin d'informations supplémentaires et si vous avez bien fait les choses. Et tant que vous vous limitez à ne commenter que les choses non évidentes, il y a de fortes chances que vos commentaires augmentent la qualité globale de la base de code, ce qui pourrait non seulement vous apporter des avantages non seulement pour vous, mais aussi pour tous ceux qui doit gérer le code, y compris votre patron.
Tout d'abord, laissez-vous un exemple pour commenter correctement votre code, Grasshopper!
Ensuite, je dois faire ça tout le temps. J'ai extrait ma copie locale et je la passe en revue et la commente moi-même. (Je peux tous les retirer à nouveau si je vais le vérifier à nouveau - ou les laisser, si personne n'y fait attention.) Ensuite, quand je ne peux vraiment pas voir plus loin, je peux demander à quelqu'un, ici, je pense que c'est le cas ceci (ce que j'ai commenté), ai-je raison? Donc, vous avez peut-être fait le commentaire, mais c'est fait et c'est le point.
Je ne demanderais pas de commentaires supplémentaires, mais voici quelques idées pour vous:
- Planifiez une rencontre avec votre patron et demandez-lui de parcourir 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 au courant. Cela devrait inclure la conception globale, les modèles utilisés, etc.
- Créez un projet de tests et commencez à écrire des tests unitaires par rapport au code, cela vous aidera à le comprendre sans le modifier. Vous pouvez également trouver quelques bugs!
- Déboguez le code au besoin pour comprendre certaines zones.
- Retirez une amélioration ou un bug du backlog et travaillez dessus.
Les commentaires sont corrects, mais si le code est écrit de manière simple, il devrait être compréhensible après quelques jours.
Ne vous attendez pas non plus à 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.
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 dans le couloir ou un e-mail. Cela va prendre un certain 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. Tandis que vous essayez de comprendre la base de code, écrivez les commentaires que vous aimeriez voir, au mieux de vos capacités, et validez-les, après en cours d'examen 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 emboîtera le pas.
- Certains des commentaires diront probablement
/* Mystery parameter 3 */ou/* 2015-02-09 AidanQuinn: Is this code ever called? */- ce sont des opportunités pour vos collègues de documenter le code correctement ou de corriger des bogues latents. - Si, lors de l'examen préalable à la validation, on découvre 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 ce faisant, et l'introduction de commentaires devrait être presque sans risque. Si vous réécrivez quoi que ce soit, conservez ces modifications en tant que validations distinctes.
(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é est en dehors de la norme ( exemple 1 , exemple 2 ), alors vous ne ferez que vous ridiculiser.)
Je suis dans une situation très similaire à la vôtre il y a environ un an. J'ai commencé à travailler avec peu d'expérience en programmation (même si je connaissais un peu OO et quelques autres langues pour commencer) et la seule personne qui m'enseignait avait très peu de temps. Il était toujours utile, mais je senti que je ne voudrais pas poser toutes les questions que j'avais.
D'autres ont déjà suggéré des choses 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 des parties du code vous-même, mais cela peut être 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 beaucoup de l'endroit exact où se trouvent vos problèmes.
De plus, je suis d'accord avec @AK_ qui a dit que vous n'avez pas vraiment besoin de commentaires en C #. Ce n'est peut-être pas correct à 100% (je pense qu'il y a des domaines où les commentaires aident vraiment, par exemple le code lourd de réflexion), mais c'est essentiellement 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 "piqûres" de code, elles seront presque totalement inutiles. Chaque fois que je ressentais le besoin de commentaires lors de la lecture du code jusqu'à présent, puis 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 par une bonne refactorisation. Edit: Je parle spécifiquement des commentaires C # ici, pas de la documentation (que ce soit une documentation séparée ou des commentaires XML), car je pense que la documentation est toujours importante.
Identifiez quels sont exactement vos problèmes et si vous pouvez les classer. Autrement dit, 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 l'ensemble de la méthode/du bloc, donc le commenter vous-même sera difficile. Au lieu de cela, procurez-vous un bon livre ("C # in a Nutshell", c'était pour moi, mais j'ai entendu que "C # in Depth" est également spectaculaire) et lisez ce que vous rencontrez. Le classement préalable de ces problèmes facilite la tâche, car vous pouvez combler des `` lacunes plus importantes '' à la fois, ou même demander à votre patron à ce sujet, car ce n'est plus beaucoup de questions, mais plutôt expliquer un seul sujet ou les constructions les plus couramment utilisées pour que vous peut obtenir un énorme "coup de pouce" dans ce domaine rapidement.
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 au langage). L'effet de cela n'est peut-être pas immédiat, mais cela sera payant tôt ou tard, soit lorsque vous devez étendre des choses existantes, soit vous demander pourquoi quelqu'un a créé autant de petites méthodes au lieu d'une où tout est contenu ;-)
Obtenez une compréhension des 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 ha. Même si vous comprenez ce que fait le code que vous y voyez, cela peut vous faire vous demander pourquoi il est fait de cette façon, et il n'est souvent pas si simple de le comprendre par vous-même.
S'il vous plaît ne prenez pas le texte ci-dessus comme moi faisant des suppositions sur votre "compétence", je passe souvent accidentellement entre parler de mes expériences et parler "à vous". Cela signifie principalement ce que j'ai rencontré et ce que j'ai fait . Comme d'autres l'ont dit, cela peut être une très bonne expérience et c'est à peu près la norme dans le travail pour lire du code qui n'est pas le vôtre et que vous ne connaissez pas beaucoup à l'avance. Mais il peut être vraiment satisfaisant de finalement comprendre ce qui se passe là-bas et de se reconnaître s'améliorer dans cette "compétence" particulière. Profitez-en pour apprendre un beaucoup en très peu de temps, bonne chance! :)
Vous n'allez probablement pas lui faire changer de style.
Ce que vous pouvez faire, c'est poser beaucoup de questions et noter les réponses.
J'ai hérité d'une énorme base de code lors de mon dernier travail, peu de documentation et peu de commentaires. J'essayais donc pendant une demi-heure sur le même problème, puis si je ne pouvais toujours pas le comprendre, j'irais demander à quelqu'un qui l'a écrit ou savait comment l'utiliser. Ensuite, je documentais toutes les choses qu'il m'avait dites. La plupart sont allés dans notre documentation, certains sont allés dans le code sous forme de commentaires. Après un an, j'avais pratiquement écrit une grande partie de notre documentation et j'en savais beaucoup sur la base du code.
Bonne chance!
J'avais le même problème. Im étudiant de phyzist et ai une bonne expérience de programmation. Je programmais dans de nombreuses langues mais rien pour une application premium.
J'ai postulé pour un emploi de développeur web et ils m'ont instantanément mis en back-end de la programmation web. Quand le patron m'a montré l'api de base pour le nœud REST je pensais que je jetterais. Je n'ai jamais vu de fonctions avec rappel et syntaxe si étrange. Et je demande à mon patron si j'ai un problème Si je ne comprends rien dans le code. Il est triste non, il est triste que j'ai 1 mois pour le comprendre et en attendant je ferai un CMS pour me tester avec un autre frontender.
Eh bien, je suis allé 1 ligne de code à l'époque et google tout ce que je ne sais pas. Une semaine s'est donc écoulée et je connaissais suffisamment le code pour pouvoir collaborer avec Front Ender. 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 moto -> Continuez à apprendre et restez calme :) Ne dépendez pas du patron soyez indépendant et demandez-lui directement mais seulement les problèmes les plus difficiles. Parce que vous serez heureux après l'avoir découvert par votre propre chercheur. Et rappelez-vous quand vous arrêtez d'apprendre que quelque chose ne va pas, apprenez chaque jour comment être un bon programmeur.
Si vous apprenez du patron, vous n'irez jamais mieux que lui définir votre propre norme, apprenez à taper en aveugle, VIM ou VIM pour votre IDE, Linux wmii , alors vous iriez un jour au-delà du patron, et seriez meilleur que lui!
Comme d'autres l'ont mentionné, c'est assez courant, mais cela ne signifie pas qu'il suffit de le sucer et de le labourer. Vous n'avez pas besoin de comprendre autant de code en profondeur que vous le pensez, et il existe des stratégies concrètes pour rendre le "deep end" beaucoup moins profond:
- Trouvez quelque chose dans le code lié à la tâche à accomplir. Habituellement, le plus facile à rechercher est quelque chose visible par l'utilisateur, comme l'étiquette du bouton sur l'interface graphique. Notez où vous l'avez trouvé. Ce sera votre point d'ancrage.
- Maintenant, recherchez le code à une étape et notez-le. Qui crée le bouton? Quel code est appelé lorsque le bouton est cliqué?
- Le contrôle de code source est souvent utile pour trouver du code à une étape. Trouvez quand le code que vous regardez a été ajouté ou modifié, et regardez ce qui a été archivé en même temps et pourquoi.
- Répétez jusqu'à ce que vous compreniez juste assez pour effectuer votre changement, plus un niveau plus profond pour vous assurer de ne rien manquer.
- Si vous êtes bloqué à un moment donné, vous avez maintenant une question très précise à poser. Par exemple, "Je n'arrive pas à comprendre d'où ce bouton est instancié".
Été dans la même situation, je dirais
Votre patron voudra peut-être que vous appreniez la sale façon (en parcourant le code dont vous n'avez aucune idée) pour une raison. C'est ainsi que nous apprenons plus en un mois au travail qu'en un an au collège, comme mentionné dans d'autres réponses.
C'est "la norme" comme mentionné dans d'autres réponses. Vous devriez être plus inquiet par où commencer et comment aborder et sur quoi vous concentrer que d'essayer de comprendre chaque ligne de code immédiatement. Demandez à votre patron quels sont les bons outils et les bonnes façons de déboguer/parcourir le code. Ce genre de questions vous rapportera des points.
Régulièrement, continuez d'approcher votre patron pour obtenir des commentaires sur la façon dont vous faites, vous aurez donc une idée de votre position en termes de centile en supposant que votre patron a vu un bon nombre de personnes dans la même situation et avoir une idée de la façon dont elles l'ont fait.
Saisissez cela comme une opportunité 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 suggérerais de trouver du code que vous devez modifier qui pourrait vraiment utiliser certains commentaires (la plupart sont explicites) et de poser la question sur comme ceci "Je regardais ce code ici et j'essaie de comprendre [le problème que vous rencontrez] et je n'ai trouvé 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 bénéficier des commentaires.
Probablement 90% du code bien écrit n'a pas besoin de commentaires. Vous voulez seulement vraiment documenter les parties de code qui ont été optimisées et qui sont devenues plutôt tendues. J'ai travaillé dans une entreprise une fois qui vous obligeait à documenter chaque élément de code que vous avez modifié.En gros, les commentaires ont fini par nuire activement à la lisibilité du code, car ils faisaient souvent référence à du code qui avait été supprimé ou modifié au-delà de la reconnaissance. Méfiez-vous des mauvais commentaires J'ai passé une semaine à déboguer une fonction et à la fin j'ai trouvé que le commentaire que je continuais à lire sur la définition de tel ou tel indicateur sur "faux" était en fait tout le problème. comme il était censé le faire.
Même s'il existe un moyen de le demander poliment, il y a deux possibilités quant à ce que votre patron pensera des commentaires dans son code:
Soit ces commentaires dans son code seraient une bonne chose, soit
Ces commentaires dans son code ne seraient pas une bonne chose.
Si votre patron pense que les commentaires dans son code ne seraient pas une bonne chose (et il y a de très bons arguments pour cela, c'est-à-dire le code est censé être la documentation , et aucune documentation ne stipulera jamais quelque chose d'aussi précisément et sans ambiguïté que 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, alors il y a de fortes chances qu'il vous dise d'étudier son code, de comprendre comment il fonctionne et d'ajouter des commentaires à son code vous-même . (Il y a aussi de très bons arguments pour cela, 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 à le faire, vous feriez mieux de ne rien dire.
Donc, juste quelque chose qui m'aidera jusqu'à ce que je comprenne les choses, comment puis-je demander à mon patron de mettre 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, cela rend la compréhension d'un code très difficile. Mais si les noms et les fonctions ou même l'organisation du programme (classes, méthodes, propriétés ...) sont de nature à rendre le code compréhensible, alors le code vous parlera en lui-même.
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.
Si vous souhaitez que les commentaires du code comprennent pourquoi quelque chose a été écrit, il est fort probable (étant donné que vous êtes nouveau) que vous ne comprenez pas encore les besoins de l'entreprise. Je suis sûr que vous connaissez toute la syntaxe et pouvez lire le code, mais à moins que vous ne connaissiez le but de certains codes, vous vous sentirez un peu perdu.
Une chose qui me vient à l'esprit est la programmation par paires. Vous dites que votre patron est impressionné par vos progrès, 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 tient pour acquises et vous en saurez plus sur l'entreprise.
Voici mes 0,02 $ sur la question. Je ne suggère pas une réponse exclusive, une grande partie de ce qui a été dit ici est tout à fait pertinente.
J'essaierais un peu d'ingénierie sociale pour arranger les choses afin que votre patron trouve plus facile/moins de temps à 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 latérale: vous pourriez tout simplement ne pas pouvoir faire quoi que ce soit sans qu'il écrive ou dicte des commentaires à vous, vous insistez et le harceliez sans cesse, etc.)
Quelle est alors l'alternative? Quelques idées, selon les circonstances.
Option 1
- Prenez le temps de comprendre qu'un morceau de son code fait X.
- Pensez maintenant à un moyen raisonnable de Y malentend.
- Dites au patron (par e-mail ou dites pendant le petit-déjeuner ou autre) que vous essayez actuellement de le comprendre.
- Ajoutez un commentaire disant que ce que le code signifie n'est pas clair, mais vous le comprenez comme Y; essayez de lui rendre ce commentaire visible - mais n'essayez pas trop fort!
- Agissez en supposant que Y - et faites sûr votre patron remarque votre action (donc vous ne perdez pas votre temps à travailler longtemps sur une fausse hypothèse).
- Le patron devrait prendre l'initiative de vous corriger. À ce stade, dites-lui quelque chose comme "Je souhaite vraiment que ce code ait quelques commentaires pour m'empêcher de faire la mauvaise hypothèse. Je corrigerai le commentaire que j'ai ajouté moi-même. Pensez-vous que vous pourriez m'aider avec une description générale de ceci et cela? Je n'ai pas assez d'expérience pour comprendre l'intention exacte, et je suis juste quelques phrases qui feraient l'affaire. " Ou quelque chose..
Option 2
Vous êtes en formation. Essayez d'organiser une réunion hebdomadaire (supplémentaire?) À fréquence fixe avec lui. Lors de cette réunion, passez en revue un certain code - mais vous devez vous préparer suffisamment pour qu'il n'ait pas à expliquer chaque ligne. À un moment donné - j'espère - il se rendra compte 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 approchez tous les deux le patron à des moments différents pour lui poser les mêmes questions. C'est une façon infaillible de lui faire réaliser qu'il ne fait rien ... mais tout le monde n'a pas le luxe de collègues utiles sur le même projet.
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 soit d'un codeur amateur autodidacte qui n'a jamais appris à faire le travail correctement, soit d'un ingénieur inexpérimenté. Ou peut-être un ingénieur qui n'a tout simplement pas le temps - les délais et l'opportunité peuvent faire des choses horribles à votre code! ;) C'est certainement un anti-modèle pour tout ingénieur logiciel compétent.
Votre patron est peut-être un très bon codeur, mais il semble qu'il ne soit pas un bon ingénieur logiciel. Un ingénieur utilise l'expérience collective du groupe pour éviter les pièges par lesquels d'autres personnes ont déjà été prises. Les commentaires efficaces font partie de cette expérience collective de groupe pour les logiciels, de la même manière que l'analyse des contraintes fait partie de l'expérience collective de groupe pour le génie mécanique. Ce qui compte comme un commentaire efficace est cependant plus fluide, et c'est certainement quelque chose que vous obtenez de l'expérience.
La chose la plus fondamentale est que les commentaires ne doivent pas dire ce que fait une ligne de code. Il y a des moments où les commentaires pour dire ce que fait une fonction sont également superflus (surtout 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 travaillez peut-être encore sur le "quoi" du code, et pour cela, vous avez juste besoin 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, où cela pourrait ne pas être évident. Avez-vous besoin de configurer le module X avant le module Y? Est-il important de vérifier un code retour pour voir si un fichier était déjà ouvert, ou ignorons-nous consciemment le code retour parce qu'il a été vérifié ailleurs? Le "pourquoi" du code sera pertinent pour tout le monde, quelle que soit l'expérience - et il le sera aussi pour lui dans 6 mois, quand il aura oublié la bonne raison de faire quelque chose d'une manière particulière. Les commentaires ne sont pas uniquement destinés à d'autres personnes, ils vous aident également à l'avenir.
Si vous voulez éviter d'énerver votre patron, posez des questions intelligentes. Concentrez-vous sur le "pourquoi" et essayez de trouver le "quoi" vous-même (à moins qu'il ne soit vraiment obscur). Aucun bon patron ne voudra qu'on vous pose des questions si ce n'est pas le genre de choses que vous auriez pu trouver avec R-ing TFM. Et aucun bon ingénieur ne voudra qu'on lui demande de faire quelque chose qui facilitera considérablement la vie d'un autre ingénieur, à peu de frais pour eux. (Ne lui demandez pas de remplir les commentaires sur la base de code entière!;)