Dix choses qui agacent les programmeurs

Les programmeurs sont un groupe assez particulier. Comme ils travaillent longtemps avec des ordinateurs, ils ont tendance à développer des personnalités et des tempéraments similaires. Bien sûr, puisqu'ils sont humains, ils ont naturellement un caractère et un tempérament. Maintenant, laissez-moi vous montrer dix choses qui peuvent agacer les programmeurs. D'une part, nous pouvons voir ce que les programmeurs ont en commun ; d'autre part, nous pouvons aussi voir leurs défauts. Quoi qu'il en soit, j'espère que cela pourra vous être utile dans votre travail quotidien.

Dixième place : les commentaires de code

Les commentaires de code sont à l'origine une bonne habitude. Lorsque des programmeurs expérimentés encadrent des débutants, ils leur disent toujours d'écrire des commentaires de code. Alors, bien sûr, les débutants suivent les conseils des programmeurs expérimentés. Cependant, ils peuvent mal comprendre à quoi servent les commentaires de code, et c'est pourquoi l'on voit souvent ce genre de commentaires dans les programmes :

Chaque fois que vous voyez de tels commentaires — qui ne commentent que le quoi, pas le pourquoi —, vous serez sûrement agacé. Qui a écrit ces commentaires ? Vous ne vous sentirez pas mieux tant que vous ne les aurez pas trouvés et que vous ne leur aurez pas dit leurs quatre vérités. Les commentaires doivent indiquer aux autres votre intention et vos pensées, pas expliquer la syntaxe du programme. C'est pour la lisibilité et la maintenabilité du code. De tels commentaires faits pour commenter ne sont pas vraiment des commentaires — c'est de la provocation, et il va sans dire qu'ils agaceront les autres.

r = n/2;  //r是n的一半
 
 //循环，仅当r- n/r不大于t
 while ((r-n/r) <=t){
     //… …
     r = 0.5 * (r-n/r); // 设置r变量
 }

Neuvième place : les interruptions

Au moment même où un programmeur est plongé dans la réflexion sur un algorithme ou ressent une inspiration soudaine en écrivant du code, être interrompu par autrui est une chose très douloureuse. Si les interruptions se poursuivent, cela peut instantanément rendre quelqu'un irritable. La personne qui interrompt est très grossière dans une telle situation. La personne interrompue est comme un appel de fonction — lorsqu'il retourne, elle doit restaurer le contexte au point d'interruption. Bien sûr, les humains ne sont pas des ordinateurs, et restaurer le contexte est généralement un processus douloureux. Dans les cas extrêmes, elle peut devoir repartir de zéro pour retrouver le fil de sa pensée, puis revenir lentement jusqu'au point d'interruption.

Par conséquent, j'ai vu certains programmeurs, lorsqu'ils ont besoin de calme sans être dérangés, soit aller dans un endroit où personne ne peut les trouver, soit accrocher une banderole au-dessus de leur bureau pour avertir tout le monde — « Je suis actuellement en train d'exécuter le programme noyau, je ne peux pas être interrompu, veuillez ne pas déranger, merci ! » Cela montre à quel point il est coûteux pour un programmeur plongé dans son travail d'être interrompu. Naturellement, beaucoup de gens sont agacés d'être interrompus.

Huitième place : changements d'exigences

Cela n'a probablement pas besoin d'explication. Du moment que vous êtes programmeur, vous vous sentez souvent impuissant face aux changements d'exigences. Une ou deux fois peuvent être acceptables, mais vous ne supportez pas les changements constants. On dit que le développement agile dispose d'une méthodologie qui permet aux programmeurs d'apprécier les changements d'exigences — qui sait si c'est vrai. Mais aujourd'hui on vous demande de fabriquer un bureau, demain on vous demande de transformer le bureau en table à manger, après-demain en lit double, le jour suivant en cabane, puis de transformer la cabane en gratte-ciel. Soupir, n'importe qui serait agacé. Ces gens peuvent prendre n'importe quelle décision en une réunion de 30 minutes, mais les dizaines de programmeurs derrière eux doivent fournir des centaines d'heures de dur labeur. Si c'était moi, j'aurais peut-être aussi besoin d'un mythique « cheval d'herbe et de boue » pour évacuer ma colère.

Cependant, cela montre aussi que les programmeurs ne savent pas communiquer avec les utilisateurs, et que les utilisateurs ne savent pas communiquer avec les programmeurs. Si un projet n’a pas d’intermédiaire (comme un PM) pour coordonner, alors tout le projet peut ressembler à « une poule qui parle à un canard » — utilisateurs comme programmeurs finiront par s’agacer mutuellement. Si l’on devait lister quelques choses qui agacent les utilisateurs, la façon de penser unique et purement technique du programmeur figurerait probablement dans le top cinq.

Septième place : Les managers qui ne comprennent pas la technologie

Les exemples de profanes dirigeant des experts sont-ils rares ? Un mot du leader — qu’il soit juste ou faux — est toujours juste, et nous devons obéir, même s’il s’agit de la décision la plus stupide et la plus erronée. Les programmeurs ne craignent pas réellement les managers qui ne comprennent pas la technologie ; ils craignent surtout les managers qui ne comprennent pas la technologie mais prétendent la comprendre en profondeur. Le plus exaspérant, c’est lorsque vous contestez l’autorité du leader avec un raisonnement solide, et que le leader vous traite comme un marginal. Soupir, en pensant à un tel leader, sans parler de l’insulter, l’envie de le frapper monte.

En fait, un manager n’est qu’un soutien de l’équipe ; il devrait aider l’équipe et résoudre ses problèmes, plutôt que de donner des ordres. Le management est vraiment simple : si vous comprenez, aidez à le faire ; si vous ne comprenez pas, faites confiance à vos subordonnés et laissez-les le faire. Le pire, c’est un manager qui ne comprend pas la technologie et ne fait pas confiance à ses subordonnés. Soupir, c’est vraiment la douleur d’un programmeur.

Sixième place : La documentation utilisateur

La documentation utilisateur ne devrait vraiment pas être si effrayante. Ces documents couvrent toutes sortes de sujets liés aux logiciels que nous développons. Comme nous ne savons pas quel niveau de compétence informatique nos utilisateurs possèdent, lorsque nous rédigeons de tels documents, nous devons supposer que l'utilisateur ne sait rien. Nous devons donc rédiger le document le plus complet possible dans la langue la plus claire et la plus belle. Même une opération de copier-coller peut devoir être décomposée en cinq ou six étapes ; même une opération de configuration d'adresse IP doit être décrite étape par étape depuis le menu Démarrer. Pour les programmeurs, ils utilisent presque tous les jours, pendant le développement, les logiciels qu'ils développent, et au final, ils peuvent en être lassés, mais ils doivent quand même rédiger ces documents à partir des parties les plus simples. Naturellement, cela les irrite facilement, et confier la rédaction de cette documentation à des programmeurs peut donner de très mauvais résultats. Par conséquent, ce type de documentation utilisateur devrait être rédigé et maintenu par du personnel de documentation dédié.

Cinquième place : aucune documentation

Comme mentionné dans l'élément précédent, les programmeurs n'aiment déjà pas écrire de documentation, et comme les personnes techniques ne sont généralement pas très douées pour l'expression et l'écriture, la documentation qu'ils rédigent est également médiocre. Vous pouvez probablement le constater d'après la documentation de la communauté open source. Cependant, d'un autre côté, nos chers programmeurs sont surtout agacés par le manque de documentation. Bien sûr, le précédent concernait la documentation utilisateur ; ici, nous parlons de documentation de développement, comme les documents de conception, les spécifications fonctionnelles, les documents de maintenance, etc. Mais au fond, ils se ressemblent tous. Quoi qu'il en soit, d'un côté, nos programmeurs n'aiment pas écrire de documentation ; de l'autre, nos programmes sont critiqués parce qu'ils n'ont pas de documentation, en ont trop peu, ou ont une documentation difficile à comprendre. Hé, on dirait que la récursion existe aussi dans les plaintes. On dit que le développement agile peut réduire la documentation dans le développement logiciel ; ils disent qu'ils peuvent écrire du code qui ressemble à de la documentation et à des diagrammes — qui sait si c'est vrai. Cependant, j'ai entendu trop de programmeurs se plaindre d'un manque de documentation ou d'une documentation médiocre. À cet égard, les programmeurs ne peuvent s'en prendre qu'à eux-mêmes.

Quatrième place : environnement de déploiement

Bien que les programmeurs développent des logiciels, nous ne savons pas dans quel environnement notre programme sera déployé ou installé — par exemple, des différences de réseaux, des différences de RAID, des différences de BIOS, des différences de systèmes d'exploitation (WinXP vs. Win2003), la présence ou non d'un antivirus, la compatibilité avec d'autres programmes, la présence éventuelle de logiciels malveillants ou de virus sur le système, etc. Bien sûr, dès que votre logiciel présente une erreur, que ce soit un problème de votre programme ou un problème d'environnement, c'est votre problème, et vous devez tout résoudre. Par conséquent, les programmeurs ne font pas que coder simplement ; bien souvent, ils doivent aussi être un administrateur système convenable. Chaque fois qu'il est finalement confirmé que la cause du problème est l'environnement, les programmeurs peuvent ressentir du ressentiment.

Troisième place : Rapports de problèmes

« Mon logiciel ne fonctionne pas », « Le programme a une erreur. » Chaque fois que nous entendons des rapports de problèmes comme ceux-ci, les programmeurs ressentent toujours une souffrance, car de tels rapports ne disent rien du tout, et pourtant les programmeurs doivent quand même gérer l'erreur. Il n'y a pas de description claire du problème, pas d'explication sur la façon de reproduire le problème, et cela peut donner l'impression d'être un peu interrogé. Pire encore, parfois cela s'accompagne d'un ton condescendant et réprobateur. Bien sûr, les programmeurs sont généralement des personnes à forte volonté qui ne réagissent ni à la carotte ni au bâton, donc chaque fois que quelqu'un signale un problème sur ce ton, ils ont tendance à répondre du tac au tac, et il en résulte naturellement des désagréments. Ainsi, nous avons encore besoin d'un service client pour aider à faire le lien entre nos programmeurs et les utilisateurs.

Deuxième place : Les programmeurs eux-mêmes

Ce qui agace les programmeurs, ce sont peut-être encore les programmeurs eux-mêmes. Les programmeurs « se méprisent les uns les autres ». Ils sont fondamentalement arrogants et vaniteux, estimant toujours être les meilleurs. Entre programmeurs, ils se disputent presque tous les jours, et une fois qu'ils commencent, ils se disputent jusqu'à en avoir le visage rouge et le cou gonflé. Ils s'énervent constamment les uns les autres.

Des opinions techniques divergentes. Par exemple : Linux vs. Win, VC++ vs. VB, Vi vs. Emacs, Java vs. C++, PHP vs. Ruby, et ainsi de suite, et ainsi de suite. Ils se disputent sur tout.
Les programmeurs expérimentés méprisent les débutants. Il y a toujours des programmeurs qui méprisent les autres, en parlant avec arrogance et en réprimandant. Lorsque les débutants posent des questions, les expérimentés se montrent souvent indifférents et ne répondent pas.
Ils ne préservent pas la face des autres sur les questions techniques. Je ne sais pas pourquoi, mais les programmeurs ne laissent jamais la face aux autres. Chaque fois qu'ils entendent quelqu'un mal comprendre une certaine technologie, ils aiment le signaler bruyamment en public, en utilisant les « erreurs » des autres pour étaler leur propre « érudition » et prouver « l'ignorance » des autres.
Ils adorent mépriser. En fait, rien n'est parfait en ce monde ; il y a des avantages et des inconvénients, et trouver des défauts est trop facile. Les programmeurs aiment particulièrement mépriser les autres. Quoi que ce soit, ils préfèrent toujours voir les défauts des autres plutôt que leurs qualités. Leurs expressions courantes sont « trop nul », « pas bon », etc.

Les programmeurs, qui côtoient les ordinateurs depuis longtemps, écrivent du code que l'ordinateur exécute toujours sérieusement. Avec le temps, ils développent une personnalité qui méprise tout, sans se rendre compte que beaucoup de choses dans ce monde ne sont pas comme un ordinateur, où il suffit de donner l'instruction correcte pour qu'il fonctionne correctement. Quand les programmeurs mûriront-ils...

Première place : le code d'un programmeur

Peu importe à quel point vous pensiez que votre conception et votre code étaient beaux et classiques à l'époque, après un certain temps, lorsque vous regardez en arrière, vous vous sentirez inévitablement idiot. Bien sûr, lorsque vous devez maintenir le code de quelqu'un d'autre, vous devez maudire son code tout en le maintenant. Vous souvenez-vous encore avec quelle fierté vous discutiez de votre conception et de votre code avec les autres et à quel point vous affirmiez qu'il était parfait ? Pourtant, en deux ans, un jeune diplômé qui maintient votre code peut en pointer les défauts et vous faire complètement perdre la face. Héhé. Bien sûr, certaines personnes pensent toujours que leur propre conception et leur code sont les meilleurs, mais c'est regarder les choses d'un point de vue relativement statique. Le monde de la programmation évolue très rapidement. Beaucoup de choses ne nous deviennent familières qu'après les avoir faites, et ce n'est qu'après être devenu familier que l'on sait quelles sont les meilleures méthodes—c'est un processus graduel. Donc, lorsque vous devenez de plus en plus familier avec les choses, et que vous regardez en arrière les conceptions et le code que vous avez écrits auparavant, vous sentirez inévitablement à quel point ils étaient superficiels et idiots. Bien sûr, en regardant les conceptions et le code des autres, vous pouvez aussi commencer à maudire.