Comment réagiriez-vous si quelqu'un vous disait que votre code est un gâchis?
Je suis un bon programmeur, du moins je le pensais avant. J'adore toujours programmer. Et je veux apprendre beaucoup de choses sur la programmation pour faire de moi un meilleur programmeur. J'ai étudié la programmation pendant 1 an et maintenant je travaille comme programmeur depuis presque 2 ans. Bref, j'ai près de 3 ans d'expérience en programmation.
Notre équipe est composée de 5 programmeurs, et 4 d'entre nous sont nouveaux, 1 a plus de 3 ans d'expérience. Nous travaillons pour un programme depuis près d'un an maintenant et personne n'a jamais révisé mon code et on m'a donné une page avec laquelle travailler. Nous n'avons jamais eu de révision de code et nous sommes tous nouveaux, donc nous ne savons pas à quoi ressemble un code propre. Je pense que les programmeurs apprennent par eux-mêmes?
Nous avons déployé notre programme sur le programme sans tests approfondis. Maintenant, c'est serré et nous avons besoin d'une approbation et d'une révision du code avant de faire des changements avec le code. Pour la première fois, quelqu'un examine mon code et dit que c'est un gâchis.
Je me sens si triste et blessé. J'adore vraiment la programmation et les faire dire quelque chose comme ça me fait vraiment mal. Je veux vraiment m'améliorer. Mais il semble que je ne suis pas un programmeur génial comme dans les films. Pouvez-vous me donner des conseils sur la façon d'être meilleur? Avez-vous déjà rencontré quelque chose qui critiquait votre code et vous vous sentez vraiment blessé? Que faites-vous sur ces événements.
La vérité est que probablement dans 2 ans, lorsque vous verrez votre code actuel, vous conviendrez que c'était un gâchis. L'apprentissage de la programmation est un processus sans fin et il y aura toujours quelqu'un de meilleur que vous.
Donc, si une personne qui a dit que votre code est un gâchis n'est pas seulement méchante et qu'il ne s'agit pas d'un autre cas de maladie "je le ferais mieux" commun aux programmeurs, vous devriez lui demander ce qui ne va pas exactement avec votre code et comment pouvez-vous l'améliorer.
Ne soyez pas fier de la façon dont vous codez. Soyez fier de la façon dont vous apprenez. Apprendre ensuite que votre code doit être amélioré vous donne l'occasion de démontrer à quel point vous êtes bon à apprendre, au lieu de vous présenter comme une critique de la qualité d'un programmeur.
Lisez http://www.perlmonks.org/?node_id=27008 si vous ne savez pas de quoi je parle.
Après plus de 20 ans, je sais que certains de mes propres codes sont toujours en désordre. Cela revient à prendre une décision entre l'écriture du meilleur code possible et l'écriture de ce qui est nécessaire pour faire le travail. Faire le travail dans un délai convenu l'emporte sur la quête sans fin de la perfection technique de tous les jours.
L'astuce est d'apprendre à l'accepter. Apprenez à accepter que vous pourriez faire mieux. Apprenez à vivre avec les défauts. Apprenez à accepter que vous n'allez pas le perfectionner cette fois, et probablement la prochaine fois aussi, et que c'est un choix délibéré parce que l'alternative n'est pas efficace. Et c'est pire.
Avertissement: rien de tout cela ne doit être lu comme "un mauvais code est OK".
Le code de tout le monde est un gâchis et il n'y a pas de bons programmeurs.
Il y a:
- les programmeurs qui expédient rapidement,
- des programmeurs qui livrent toujours du code sémantiquement correct,
- des programmeurs qui trouvent toujours la solution optimale et l'algorithme le plus rapide,
- programmeurs dont le code est facile à regarder.
Ils finissent à peine, sinon jamais, par être la même personne.
Et il y a des programmeurs qui ont besoin de grandir et:
- demandez ce qui ne va pas,
- ne pas faire de commentaires personnels, pour mesurer leur valeur en tant qu'être humain;
- se rendre compte qu'il existe des directives de syntaxe dans les équipes, et elles doivent être suivies, et elles sont arbitraires, donc elles ne sont pas censées être discutées ad nauseam , car il n'y a pas de solution optimale, ni de mot final;
- mieux commenter leur code;
- mieux commenter leur code; (sic)
- trouver des solutions plus faciles à déboguer, moins intelligentes à des tâches simples et banales;
- prendre une classe en SQL
(J'enverrais la moitié de la population mondiale pour suivre un cours en SQL, juste pour être sûr)
Ce n'est pas de l'art, c'est un métier.
Nous donnons pour acquis que vous êtes intelligent: vous programmez des ordinateurs, bon sang.
Encore AMD64 et x86 ne sont pas contraints par la puissance de votre prose. Gardez les choses simples.
Eh bien, une personne qui dit que votre code est un gâchis n'est pas constructive, même si elle a raison. Vous ont-ils expliqué pourquoi c'était un gâchis? Par exemple, les méthodes sont trop longues, les responsabilités mélangées, trop de branchements, etc. Honnêtement, tout code que j'ai écrit il y a un an, je dirais que c'est de la merde complète parce que j'ai appris une tonne depuis lors. Alors ne vous sentez pas mal à ce sujet. Je serais plus inquiet si vous aimiez toujours lire le code que vous avez écrit il y a longtemps.
Plus votre base de code est propre, moins vous passez de temps à combattre la base de code pour résoudre un problème donné. Une année est un bon point à aborder car vous pouvez ressentir les douleurs de toutes les décisions de conception que vous avez prises plus tôt dans le projet.
Sur mon projet actuel, nous avons refactorisé plusieurs fois car nous sommes devenus plus à l'aise avec notre pile technologique. Cela devrait être encouragé et vous devriez noter les tâches qui prennent plus de temps qu'elles ne le devraient en raison de la base de code actuelle.
Avez-vous parcouru certaines des parties les plus anciennes du code que vous avez écrit? Vous pouvez probablement voir les choses que vous voudriez faire différemment maintenant ou refactoriser.
De plus, lorsque vous mentionnez un manque de tests, c'est toujours quelque chose à regarder. Sur notre projet, nous n'avons eu aucun test automatisé et, par conséquent, beaucoup de code fortement couplé. Même si vous n'écrivez pas régulièrement des tests unitaires/d'intégration/quoi que ce soit, le faire pendant un petit moment vous donnera l'habitude de rendre votre code plus modulaire (et par conséquent, moins de gâchis).
Je me sens si triste et blessé. J'adore vraiment la programmation et les faire dire quelque chose comme ça me fait vraiment mal. Je veux vraiment m'améliorer.
Ça c'est bon. C'est un beaucoup mieux que d'avoir une réaction comme "mon critique n'a aucune idée de ce dont il parle", "mon critique est trop pointilleux" ou simplement "mon critique ne m'aime pas" et les ignorer. Cette attitude est une bonne chose.
Mais il semble que je ne suis pas un programmeur génial comme dans les films.
Je ne sais pas quel genre de films vous regardez, mais 90% des programmeurs dans les films sont si faux que j'ai des larmes à la fin de la séquence.
Pouvez-vous me donner des conseils pour être meilleur?
Lisez et pratiquez. Consultez des livres comme Code Complete ou The Pragmatic Programmer . Regardez sur Amazon pour des livres similaires.
Avez-vous déjà rencontré quelque chose qui critiquait votre code et vous vous sentez vraiment blessé? Que faites-vous sur ces événements ..
Pourquoi te sens-tu blessé? Je me sens déçu en moi-même d'être un tel débile en premier lieu. J'utilise cette motivation pour nettoyer mon code et m'assurer de ne pas refaire la même erreur . La dernière chose [~ # ~] i [~ # ~] je veux le faire sans en tirer des leçons. Vous avez été réprimé une fois, ne le laissez pas se reproduire pour la même raison.
Aucun programmeur n'est né parfait, ni même proche. Plus vous écrivez de code, plus vous obtenez d'avis et d'avis - fournissez, vous ferez un meilleur programmeur complet.
L'une des meilleures choses pour moi en tant que développeur est que chaque jour est un processus d'apprentissage. Il y aura toujours quelqu'un là-bas qui ne sait pas quelque chose que vous faites, et il y aura toujours quelqu'un qui sait quelque chose que vous ne savez pas. Je ne me considérerais certainement pas ailleurs qu'à un niveau d'entrée/junior, mais j'apprécie toutes les critiques que je peux recevoir tant qu'elles sont à la fois justifiées et données avec respect.
Une analogie qui pourrait convenir concerne une période de temps pendant laquelle j'étais professeur d'écriture dans une université, ainsi que lorsque j'ai participé à des cours d'écriture créative. L'écriture de code, à toutes fins utiles, ressemble beaucoup à l'écriture d'un poème, d'un essai, d'une nouvelle ou d'un roman. Chaque individu a sa propre façon de procéder, mais en même temps, même les meilleurs écrivains (ou, dans ce cas, les développeurs) font des erreurs ou laissent les choses passer entre les mailles du filet. Nous pouvons souvent ne pas remarquer ces choses parce que nous nous habituons tellement à notre propre voix (ou encore, dans ce cas, au style de code).
Comme dans n'importe quel domaine, il y a ceux qui sont considérés comme des experts. Si ces gens n'existaient pas, nous n'aurions personne pour apprendre. En supposant que cette personne en question est vraiment un expert, j'écouterais ce qu'il dit et je demanderais ce qu'il vous suggérerait de faire pour améliorer votre code. N'oubliez jamais, cependant, qu'il n'est pas le seul à pouvoir apporter son aide; nous avons la chance qu'une pléthore de ressources telles que SE/SO existent.
Le désordre est plutôt subjectif. La meilleure chose que vous puissiez faire est de demander à cette personne (ou au rapport d'examen): pourquoi est-ce compliqué? (de leur point de vue, c'est-à-dire)
Ils sont tenus de vous répondre et vous pourrez soit:
- Argument contre (si vous avez une bonne raison de le faire, bien sûr)
- Soyez très heureux, car vous venez d'apprendre quelque chose de nouveau et votre futur code sera forcément plus génial puisque vous savez maintenant comment le rendre moins compliqué grâce à leurs conseils.
Le fait que vous vous inquiétiez est un bon signe. Commençons par ça. Vous mentionnez que vous aimez programmer, mais aimez-vous être un programmeur professionnel? Il y a une grande différence entre un passionné et un professionnel. En tant que professionnel, vous serez constamment surveillé pour votre produit de travail.
Our team is composed of 5 programmers, and 4 of us are new
Le fait que vous ayez travaillé deux ans sans aucune confrontation me dit que vous travaillez dans un emploi très décontracté, ce qui n'est pas si bon si vous voulez vraiment avancer en tant que professionnel. Attention, certains des meilleurs programmeurs du monde travaillent pour la fondation Linux et soyez assurés qu'ils ne sont pas traités avec bonté lorsqu'ils font des erreurs marginales ... beaucoup moins de 'code désordonné'.
Pour un examen rapide de quelques directives de codage assez standard, les Linux Community Contributors Standards devraient vous donner une idée du niveau de responsabilité auquel aspirer pour votre produit. Reportez-vous à OBTENIR LE CODE DROIT.
Pour approfondir cette affirmation, vous devez apprendre à adopter la révision, car la plupart des bons logiciels sont soigneusement examinés. Cela prend en charge Loi de Linus indiquant ...
"S'il y a suffisamment de relecteurs, tous les problèmes sont faciles à résoudre."
Personnellement, j'ai vu des développeurs hautement qualifiés, responsables et fiables obtenir la hache pour quelque chose d'aussi simple que d'oublier de laisser des commentaires ... donc si quelqu'un vous dit vos codes un gâchis alors c'est probablement ... Refactoring. Ça fait partie du concert.
I feel so sad and hurt.
Allez faire une application de tristesse pour évaluer à quel point vous êtes contrarié lorsque vous ne vous appliquez pas.
Vous avez répondu à votre problème ... Vous ne testez pas!
Après avoir vu un commentaire, vous avez déclaré que votre développeur a Java, j'étais presque bouleversé. Donc, si je vous comprends bien, vous dites que vous et votre équipe de développement travaillez dans un Java faites du shopping et n'avez pas de framework de test pour vos applications ...
Là réside le hic
"Nous avons déployé notre programme sur le programme sans tests approfondis."
Cribbing UML Creator Grady Booch ...
L'ingénieur logiciel amateur est toujours à la recherche de magie, d'une méthode ou d'un outil sensationnel dont l'application promet de rendre le développement logiciel trivial. C'est la marque de l'ingénieur logiciel professionnel de savoir qu'il n'existe pas une telle panacée.
Alistair Cockburn fournit une multitude d'informations sur son site sur l'utilisation de méthodologies agiles pour augmenter les performances et la qualité pour vous et votre équipe.
L'un des aspects les plus importants de la programmation {et de la vie} est de connaître vos forces et vos faiblesses. Si vous ne travaillez pas sur vos faiblesses, vous n'aurez pas un ensemble de compétences bien équilibré.
Outro ... Vous vous débrouillez bien - ne pleurnichez pas. Avancez dans le développement de votre métier et laissez votre passion pour la programmation vous faire avancer. Bonne chance :-)
Ne laissez pas vos émotions nuire à l'amélioration de votre code. Le but d'une révision de code est de trouver des problèmes, vous ne devriez donc pas être trop surpris s'il y en a. Cela dit, ils ne sont pas non plus censés être une session de dénigrement de codeurs.
Ils ne devraient pas non plus simplement dire "Ewwww" et en rester là. Il y a toujours une raison pour laquelle quelque chose ne va pas dans la programmation. Par exemple, il est faux de laisser beaucoup de code commenté partout, mais c'est faux parce qu'il encombre le code et le rend plus difficile à lire, pas parce que quelqu'un l'a dit dans un livre.
Votre code n'est pas vous. N'oubliez pas cela.
Je vais être la bite ici et conseiller sur la base de .. eh bien, l'évidence. Évidemment, votre code IS un gâchis ou la question que vous poseriez est "POURQUOI quelqu'un dit que mon code est un gâchis?" Mais vous ne contestez pas la supposition. Vous êtes juste agissant mal et très franchement, il pourrait y avoir des pleurs, mais il n'y a aucun sentiment quand il s'agit de justifier la programmation.
Mais vraiment, pourquoi demandez-vous? Vous savez que votre code est nul ou vous poseriez une question différente. Si quelqu'un me disait que mon code web back-end puait, je ris et je disais "ok, qu'est-ce qui ne va pas?" S'ils me disaient que mon JavaScript puait, je leur donnerais l'équivalent de programmeur social d'une grosse lèvre et je ne demanderais jamais de conseils sur la façon de réagir parce que les petites chiennes sont clairement! @ # $ Ing mal.
Possédez ce que vous êtes bon. Et je veux vraiment dire en prendre la responsabilité. car il ne faut qu'une gaffe pour un twit pour vous deviner. Ne demandez pas la permission d'être bon. Connaissez juste vos affaires. La fin.
Rappelez-vous ceci: le pire code que vous verrez sera le vôtre!
Jeff Atwood de codinghorror.com a beaucoup écrit sur le sujet, vous voudrez peut-être commencer ici: http://www.codinghorror.com/blog/2009/07/nobody-hates-software-more-than-software -developers.html
Si vous souhaitez vous améliorer, commencez à lire des informations sur le style de codage, les modèles, les flux de travail, essentiellement tout ce que vous pouvez mettre la main sur. Apprenez également plus de langages de programmation, voyez comment ils font les choses. Si vous faites de la POO, lisez ceci: http://en.wikipedia.org/wiki/Design_Patterns
Parlez également à d'autres programmeurs et faites de la programmation en binôme ou regardez d'autres codes.
Faire des erreurs est inévitable, les répéter l'est.
La plupart du temps, vous devez dire "merci" à la personne qui vous a dit cela.
Les chances sont qu'ils se soucient de leur profession, qu'ils se soucient de leur travail, qu'ils se soucient de leur équipe et qu'ils se soucient de vous.
Il peut être difficile d'accepter les critiques. Ne vous fâchez pas. Pensez à ce qu'ils essaient de vous dire et ne laissez pas vos émotions prendre le dessus sur vous.
Je programme depuis longtemps (30 ans) et mon style et mon code s'améliorent tout le temps (j'espère). La seule façon dont je sais que son amélioration est lorsque d'autres personnes me le disent ou si je reviens en arrière et revois mon code.
Essayez de regarder le code que vous avez écrit au début de votre carrière. À quoi cela ressemble-t-il maintenant? Est-ce que ça a l'air aussi bien que vous le pensiez quand vous l'avez écrit;)
Tout d'abord, vous devez comprendre que la programmation est un processus itératif, un peu comme écrire un article ou un livre. D'abord, vous écrivez un "brouillon" de votre programme, juste pour le faire fonctionner. À ce stade, votre code sera un gâchis. Donc vous refactorisez pour rendre le code propre. Ensuite, vous profilez et voyez ce que vous devez optimiser pour le rendre rapide. L'astuce consiste à refactoriser en continu, sinon le gâchis augmentera. Vous devez nettoyer votre code régulièrement, tout comme vous devez nettoyer votre maison.
Les révisions de code sont absolument essentielles. Vous devez faire examiner votre code par au moins une autre paire d'yeux. Lorsque vous passez d'innombrables heures à regarder votre code, vous vous y habituez et vous pouvez facilement manquer un bug ou une odeur de code que votre collègue pourrait remarquer instantanément.
De plus, le fait d'expliquer votre code à quelqu'un d'autre est un excellent moyen de voir si vous avez oublié quelque chose. C'est comme lire un document que vous écrivez à haute voix. Votre cerveau traite les informations audio et visuelles de différentes manières, et vous pouvez trouver des failles dans votre raisonnement en changeant de modalité. De plus, si vous expliquez votre code à un collègue et que quelque chose n'a pas de sens pour elle, c'est une bonne indication que vous devez refactoriser votre code.
Lors de la révision d'un code, il est très important que l'auteur et le réviseur vérifient leurs ego à la porte. L'objectif est d'améliorer le code. L'évaluateur doit donc être respectueux et l'auteur doit garder l'esprit ouvert. N'oubliez pas que ce sont vos collègues qui devront maintenir votre code, il doit donc être clair pour eux. Si le réviseur ne comprend pas ce que fait une variable, renommez-la. Si le réviseur ne peut pas comprendre ce que fait un bloc de code, refactorisez-le en une fonction avec un nom descriptif. Indépendamment de ce que vous pensez, si vos collègues ne peuvent pas comprendre votre code, ce n'est pas bon.
En parlant de refactoring, vous devez absolument avoir un framework de test unitaire, car sans lui, vous ne pouvez pas refactoriser.
Enfin, je recommande fortement de lire "Clean Code" de Robert C. Martin. Il vous dira pourquoi votre code est un gâchis et ce que vous pouvez faire pour le nettoyer.
Pouvez-vous me donner des conseils pour être meilleur?
La réponse de Jay qui recommande les livres est bonne, mais il semble que vous soyez déjà à un tournant au travail.
Passé:
Notre équipe est composée de 5 programmeurs, et 4 d'entre nous sont nouveaux, 1 a plus de 3 ans d'expérience. Nous travaillons pour un programme depuis près d'un an maintenant et personne n'a jamais révisé mon code et on m'a donné une page avec laquelle travailler.
Présent:
Maintenant, c'est serré et nous avons besoin d'une approbation et d'une révision du code avant de faire des changements avec le code.
Il semble que votre entreprise/équipe/service apprenne dans son ensemble, en termes de gestion de projet et d'équipe ainsi que de programmation. Commencer à réviser le code est une excellente occasion de s'améliorer dans presque tous les domaines si on lui accorde une attention appropriée.
Utilisez cela comme une opportunité; en supposant que vous effectuez des évaluations par les pairs (avec les autres développeurs de votre équipe), suggérez-leur que ce processus est important et que tout le monde peut en tirer des leçons.
À la base, ce sera un examen rapide avec le résultat "oui, ça va". Avec un effort un peu plus concentré, vous pouvez faire rebondir les idées les unes sur les autres, "oui ça marche, mais vous auriez pu l'aborder de cette façon, ce qui aurait rendu votre objectif plus clair ...". Prenez des notes pour l'avenir même si le code est jugé correct à déployer.
Si cela doit réussir, vous devez obtenir votre équipe et votre manager, ce qui signifie souvent leur expliquer les avantages. Pour les autres développeurs, c'est l'occasion d'apprendre. Pour votre manager, c'est l'occasion de perfectionner l'équipe à peu de frais, créant ainsi des sorties a) avec plus de valeur ou b) plus rapidement c) avec moins de coûts de maintenance (généralement un gros problème!).
Il s'agit d'un changement de culture que vous ne pouvez pas forcer par vous-même, mais vous pouvez aider à pousser les choses dans la bonne direction!
N'oubliez pas que ce type de changement de culture peut être extrêmement bénéfique pour les organisations; les bons managers reconnaîtront que vous travaillez pour améliorer l'ensemble de l'équipe, quelque chose qui mérite d'être récompensé.
Pouvez-vous me donner des conseils sur la façon d'être meilleur? Avez-vous déjà rencontré quelque chose qui critiquait votre code et vous vous sentez vraiment blessé? Que faites-vous sur ces événements.
La réponse à cette question se trouve dans les entreprises de nouvelle génération. Je suis allé dans des entreprises comme Google et FaceBook et je vois que si vous suivez religieusement le processus Agile/Scrum, vous pouvez écrire un meilleur code et l'améliorer à chaque sprint.
How to be better?
La réponse est une refactorisation continue. Les outils de développement modernes comme Visual Studio ont beaucoup d'outils qui vous aident dans ce processus. Si vous suivez le processus de développement du logiciel Scrum, puis dites par exemple que vous avez écrit du mauvais code dans le cycle de sprint 1 et que quelqu'un a souligné lors de la révision que c'est mauvais, puis dans le sprint 2, vous avez la possibilité de refactoriser le code.
Ces problèmes se produisent en premier lieu en raison d'un manque de bon processus. La solution est donc de proposer un bon processus de développement logiciel pour votre équipe et de pratiquer une refactorisation continue.
Tout d'abord, quelqu'un disant que votre code est un désordre est très vague et subjectif. Cela peut signifier différentes choses pour différentes personnes. Voici pourquoi; il y a deux choses différentes à considérer.
Structure
La structure de votre code est régie par la langue, les normes de l'industrie et les normes de l'entreprise pour n'en nommer que quelques-unes. De toute évidence, il existe également d'autres facteurs.
Ce sont les types d'erreurs que les peluches, les outils de test et les produits similaires sont conçus pour identifier. Ils sont bien définis et vous ou vos outils pouvez prendre des décisions objectives quant à leur validité/exactitude.
Style
Malgré une structure/règles normalisées pour le code, chaque développeur a un certain style dans la façon dont il écrit et aborde un problème ou une tâche. Faites la maintenance du code dans n'importe quel environnement d'équipe et au fil du temps, vous serez en mesure de deviner qui a écrit le code en fonction du style. Vous développerez également votre propre style et il changera à mesure que vous acquérez de l'expérience et apprenez votre métier.
Donc, chaque fois que quelqu'un dit que votre code est un gâchis , vous devez comprendre s'il parle de la structure ou le style . Ce sont deux choses très différentes; la structure est objective tandis que le style est absolument subjectif.
Cela étant dit, tout commentaire constructif d'autres programmeurs peut vous être très utile. Tout dépend de vous et de la façon dont vous prenez la critique. Au fil du temps, vous apprendrez qui est à prendre à cœur par rapport à qui prendre avec un grain de sel.
Au fur et à mesure que vous progressez dans votre carrière, vous examinerez votre propre code et verrez des choses que vous pourriez faire différemment, mieux, plus propre et plus rapidement. Tout cela fait partie du processus d'apprentissage et voir vos propres erreurs passées est une véritable indication que vous perfectionnez et améliorez votre métier.
Ne laissez pas un peu de critique vous refroidir. Prenez ce que vous pouvez et si c'est significatif et précieux, ajoutez-le à votre réserve de connaissances.
Je les remercierais pour les commentaires, puis leur demanderais d'expliquer ce qui les rend mauvais et comment ils devraient être améliorés.
Si vous convenez que la personne qui donne la rétroaction a du sens, envisagez d'apporter des changements à l'avenir. Mais rappelez-vous, ce n'est pas parce que quelqu'un dit que cela est vrai.
Pouvez-vous donner des exemples spécifiques de ce que l'on a appelé "un gâchis"?
Bien qu'il soit important de reconnaître quand votre propre code est un gâchis (sentiment très typique parmi les programmeurs, surtout lorsqu'ils deviennent plus expérimentés et que leur ancien code vieillit), il est même plus important d'écouter quand d'autres personnes le disent vous donc.
Il n'y a que tant de problèmes que vous pouvez reconnaître dans votre propre code, car il a été produit dans les contraintes de vos connaissances actuelles en programmation.
La révision du code est une opportunité d'apprentissage essentielle car elle vous expose probablement à nouvea connaissances que vous n'aviez pas en travaillant sur le code (sinon vous l'utiliseriez et il n'y aurait pas de gâchis).
Je pense qu'il y a deux parties au traitement des commentaires négatifs.
1. Déterminez la nature des problèmes soulevés et ce que vous devez en tirer
Lorsque je passe en revue ou fais réviser mon code, je trie les informations sur les problèmes de code dans à peu près de tels compartiments:
- viole des exigences technologiques strictes
- tout simplement faux (ne fonctionne pas ou ne fonctionne pas conformément aux exigences)
- échouera dans d'autres circonstances (changement d'environnement/configuration)
- utilise des fonctionnalités obsolètes et se brisera dans un avenir prévisible
- viole les meilleures pratiques de l'industrie, manque de choses comme
- en utilisant une approche éprouvée à un problème spécifique
- performance
- rétrocompatibilité
- facilité d'entretien
- style de codage
- documentation
- enfreint les meilleures pratiques en milieu de travail
- identique à l'industrie, mais plus spécifique à l'entreprise/collègues et peut différer de l'industrie dans les détails
- ne correspond pas à l'expertise personnelle
- peut être améliorée d'une manière ou d'une autre, selon la personne qui examine
Notez que cela va de choses très objectives ("cela cassera lors du déploiement sur notre serveur de production") à des choses très subjectives ("je n'aime pas comment vous avez nommé les variables").
2. Déterminez quelles (le cas échéant) les modifications du code seront apportées comme résultat de l'examen
Une fois les informations traitées, il est décidé si elles peuvent donner lieu à une action et si le code doit être modifié. Ce n'est pas nécessairement votre décision, votre opinion peut ou non avoir de l'importance selon les parties impliquées et les spécificités de votre situation (ancienneté, etc.). Mais les résultats possibles sont grosso modo:
- résoudre le problème dans son intégralité
- réparer cassé
- format au style de codage requis
- etc
- arriver à un compromis si la question doit être traitée en tout ou en partie, car il pourrait y avoir
- aucune ressource (comme le temps ou le budget)
- pas besoin (n'obtiendra qu'une amélioration insignifiante, compromettra la stabilité, etc.)
- comprendre que le problème soulevé n'est pas valide
- la rétroaction (en particulier de la catégorie d'opinion subjective) peut très bien être carrément nuisible et ne doit pas être utilisée à l'aveuglette
Vous avez appris qu'il est douloureux d'obtenir des commentaires négatifs et cela pourrait très bien être douloureux à chaque fois à l'avenir. Cependant, vous avez laissé savoir en quoi il s'agit d'une opportunité d'apprentissage importante et comment le processus vous aide à vous améliorer professionnellement et votre lieu de travail pour obtenir une meilleure base de code.
Eh bien, ne vous sentez pas brisé. Finalement, vous apprendrez des erreurs. Une fois que vous avez terminé avec le problème, vous pouvez parler à un gars pour lui faire sentir que vous voulez vous améliorer. Essayez d'écouter plus et d'argumenter moins.
J'ai vécu cette situation et je peux comprendre.
TL; DR
Comment réagiriez-vous si quelqu'un vous disait que votre code est un gâchis?
Mon simple, "trop longtemps n'a pas lu (toutes les réponses - excuses, j'espère trouver le temps de plus tard et éditer/modifier si nécessaire)" réponse/astuce:
- Bon vieux examen par les pairs. Demandez à différents équipages avec différentes mentalités collectives, niveaux d'expertise et/ou niveaux d'agressivité de revoir votre code.
- Juste pour développer un peu ce que j'entends par "différents" groupes de pairs: la diaspora StackExchange est probablement le groupe le plus instruit, professionnel et estimé en raison de la difficulté relative à en faire partie par rapport, par exemple, à Reddit. Reddit a tendance à être très agressif dans les sous-reddits les plus populaires - mais assez étrangement, les sous-programmes de programmation sont assez conviviaux (d'après ce que j'ai vécu).
Un bon exemple, peut-être le meilleur, du type agressif de mentalité de clique de type gangsta est la foule des forums XDK, et le pire du pire trophée que je remets au CyanogenMod pour Android forums/canal IRC Android populace.
C'était un peu plus long que je ne le pensais; mon point de vue était censé être - obtenir des critiques variées, mais se concentrer sur l'obtention d'une critique honnête de la part des personnes qui connaissent leur métier, et savoir ce qu'est la critique constructive. Oh, et être capable de prendre n'importe quelle forme de critique sans vous laisser abattre. Règle générale: si vous commencez à entendre des commentaires similaires concernant une chose qui peut être mutuelle par rapport aux commentaires, faites une introspection plus approfondie.