Je suis un bon programmeur, ou du moins le pensais-je. J'aime 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 en tant que programmeur depuis presque 2 ans. En bref, j'ai presque 3 ans d'expérience en programmation.
Notre équipe est composée de 5 programmeurs et 4 d'entre nous sont nouveaux, l'un d'eux a plus de 3 ans d'expérience. Nous travaillons pour un programme depuis presque un an maintenant et personne n’a jamais revu 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, nous ne savons donc pas à quoi ressemble un code propre. Je pense que les programmeurs apprennent par eux-mêmes?
Nous avons déployé notre programme dans le programme sans procéder à des tests approfondis. Maintenant, c'est serré et nous avons besoin d'une approbation et d'une révision du code avant d'apporter des modifications au code. Pour la première fois, quelqu'un passe en revue mon code et dit que c'est un gâchis.
Je me sens si triste et blessé. J'aime beaucoup programmer et leur faire dire quelque chose comme ça me fait vraiment mal. Je veux vraiment m'améliorer. Mais il semble que je ne sois pas un programmeur de génie comme dans les films. Pouvez-vous me donner des conseils sur comment être meilleur? Avez-vous déjà expérimenté quelque chose en critiquant votre code et vous vous sentez vraiment blessé? Que faites-vous sur ces événements?
la source
Réponses:
La vérité est que, probablement, dans 2 ans, lorsque vous verrez votre code actuel, vous conviendrez que c'était un gâchis. La programmation d'apprentissage est un processus sans fin et il y aura toujours quelqu'un qui y réussira mieux que vous.
Donc, si une personne qui dit que votre code est un gâchis n’est pas simplement méchante et que ce n’est pas un autre cas de "je ferais mieux", une maladie courante chez les programmeurs, vous devriez lui demander ce qui ne va pas avec votre code et comment l'améliorer.
la source
Ne soyez pas fier de la qualité de votre code. Soyez fier de la qualité de votre apprentissage. Puis, apprendre que votre code doit être amélioré vous offre la possibilité de démontrer votre qualité d'apprentissage, au lieu de critiquer votre mauvais programmeur.
Lisez http://www.perlmonks.org/?node_id=270083 si vous ne savez pas de quoi je parle.
la source
Après 20 ans et plus, je sais que certains de mes propres codes sont toujours un désordre. Il s’agit de décider entre écrire le meilleur code possible et écrire ce qui est nécessaire pour faire le travail. Réaliser le travail dans les délais convenus dépasse la quête incessante de la perfection technique chaque jour.
L'astuce consiste à apprendre à l'accepter. Apprenez à accepter que vous pourriez faire mieux. Apprenez à vivre avec les défauts. Apprenez à accepter que vous n'allez pas le rendre parfait cette fois-ci, et probablement aussi la prochaine fois, et que c'est un choix délibéré, car l'alternative ne donne pas les résultats escomptés. Et c'est pire.
Clause de non-responsabilité: rien de tout cela ne doit être lu comme "un code incorrect est correct".
la source
Le code de tout le monde est un gâchis et il n'y a pas de bons programmeurs.
Il y a:
Ils finissent à peine par être la même personne.
Et il y a des programmeurs qui doivent grandir et:
(j'enverrais la moitié de la population mondiale à un cours en SQL, par sécurité)
Ce n'est pas de l'art, c'est un métier.
Nous donnons pour acquis que vous êtes intelligent: vous programmez des ordinateurs, merde.
Encore
AMD64etx86ne sont pas obligés par le pouvoir de votre prose. Gardez les choses simples.la source
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 donné les raisons pour lesquelles c'est un gâchis? Comme, par exemple, les méthodes sont trop longues, les responsabilités mélangées, les branches trop nombreuses, etc. Alors ne vous en faites pas. 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 à la combattre pour résoudre un problème donné. Une année est un bon point, car vous pouvez ressentir les difficultés 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 afin de nous familiariser davantage 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 passé en revue 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 les refactoriser.
Aussi, lorsque vous parlez d'un manque de tests, c'est toujours quelque chose à regarder. Dans le cadre de notre projet, nous n’avions aucun test automatisé, ce qui a entraîné beaucoup de code hautement couplé. Même si vous n'écrivez pas régulièrement des tests unitaires / d'intégration / quelconques, vous devrez prendre l'habitude de rendre votre code plus modulaire (et par conséquent moins désordonné).
la source
Ça c'est bon. C'est beaucoup mieux que d'avoir une réaction du type "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.
Vous ne savez pas quel genre de films vous regardez, mais 90% des programmeurs sont tellement faux que j'en ai des larmes à la fin de la séquence.
Lire et pratiquer. Découvrez des livres comme Code Complete ou The Pragmatic Programmer . Rechercher sur Amazon pour des livres similaires.
Pourquoi te sens-tu blessé? Je suis déçu de moi-même d'être un tel imbécile. J'utilise cette motivation pour nettoyer mon code et m'assurer de ne pas refaire la même erreur . La dernière chose que je veux faire ne pas apprendre. Vous avez été réprimé une fois, ne laissez pas cela 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 des critiques et des critiques que vous fournissez , ce qui fait de vous un meilleur programmeur.
la source
reviews you provideparce que le fait de critiquer les autres peut être une pratique importante pour améliorer la critique de votre propre code afin d'améliorer la qualité.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 saura rien de ce que vous faites et il y aura toujours quelqu'un qui sait quelque chose que vous ne connaissez pas. Je ne me considérerais certainement pas ailleurs qu'au niveau débutant / junior, mais j'apprécie toutes les critiques que je peux recevoir à condition qu'elles soient à la fois justifiées et respectueuses.
Une analogie qui pourrait convenir concerne une période au cours de laquelle j’ai été tuteur en écriture dans une université, ainsi que celle où j’ai suivi des cours de création littéraire. Écrire un code, à toutes fins pratiques, 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 s'y prendre, mais en même temps, même les meilleurs écrivains (ou, dans ce cas, les développeurs) commettent des erreurs ou laissent passer des choses insensées. Nous pouvons souvent ne pas remarquer ces choses parce que nous nous habituons tellement à notre propre voix (ou encore, dans ce cas, à un style de code).
Comme dans n'importe quel domaine, il y a ceux qui sont considérés comme des experts. Si ces personnes n'existaient pas, nous n'aurions personne à qui apprendre. En supposant que cet individu soit vraiment un expert, j'écouterais ce qu'il dirait et lui 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’il existe une pléthore de ressources telles que SE / SO.
la source
Le mess est plutôt subjectif. La meilleure chose à faire est de demander à cette personne (ou au rapport d'examen): pourquoi est-ce compliqué? (de leur point de vue, c'est)
Ils sont tenus de vous répondre et vous pourrez soit:
la source
Le fait que tu sois concerné 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 soumis à un contrôle constant de votre produit de travail.
Le fait que vous ayez travaillé pendant deux ans sans aucune confrontation me dit que vous occupez un travail très décontracté, ce qui n’est pas si bon si vous voulez réellement aller de l’avant en tant que professionnel. Certains des meilleurs programmeurs du monde travaillent pour la fondation Linux et soyez rassurés, ils ne sont pas traités avec gentillesse lorsqu'ils commettent des erreurs marginales ... et encore moins du "code désordonné".
Pour un aperçu rapide de certaines directives de codage relativement standard, les normes des contributeurs de la communauté Linux doivent vous donner une idée du niveau de responsabilité à atteindre pour votre produit. Reportez-vous à OBTENIR LE CODE À DROITE.
Pour approfondir cette affirmation, vous devriez apprendre à accepter la révision, car la plupart des logiciels de qualité sont soigneusement examinés. Cela soutient la loi de Linus selon laquelle ...
Personnellement, j'ai vu des développeurs hautement compétents, responsables et fiables obtenir l'essentiel de quelque chose d'aussi simple que d'oublier de laisser des commentaires ... donc si quelqu'un vous dit que vos codes sont un gâchis, alors c'est probablement ... Laissez tomber ... Refactoring. Cela fait partie du concert.
Allez faire une application de tristesse pour évaluer à quel point vous êtes contrarié lorsque vous ne vous appliquez pas.
Après avoir vu un commentaire indiquant que vous étiez un développeur java, je me suis presque fâché. Donc, si je vous ai bien compris, vous dites que vous et votre équipe de développement travaillez dans un magasin java et que vous n'avez pas de cadre de test pour vos applications ...
Créateur UML Cribbing Grady Booch ...
Alistair Cockburn fournit sur son site une mine d'informations sur l'utilisation de méthodologies agiles pour améliorer 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 complet.
Outro ... Tout va bien - Ne te plains pas. Avancez dans le développement de votre art et laissez votre passion pour la programmation vous faire avancer. Bonne chance :-)
la source
Ne laissez pas vos émotions vous empêcher d'améliorer votre code. Le but d'une révision de code est de détecter les 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 codeur.
Ils ne devraient pas non plus se contenter de dire "Ewwww" et de s'en tenir à cela. 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 que cela 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. Souviens-toi de ça.
la source
Je vais être la bite ici et conseiller sur la base de .. bien, l'évidence. De toute évidence, votre code EST un gâchis ou la question que vous vous posez est "POURQUOI quelqu'un dit-il que mon code est un gâchis?" Mais vous ne contestez pas la supposition. Vous agissez juste blessé et très franchement, il y a peut-être des larmes, mais rien ne nous empêche de justifier la programmation.
Mais vraiment, pourquoi demandez-vous? Vous savez que votre code est nul ou que vous posez une question différente. Si quelqu'un me disait que mon code web était nul, je ris et disais "d'accord, qu'est-ce qui ne va pas?" S'ils me disaient que mon code JavaScript était mauvais, je leur donnerais l'équivalent d'une grosse lèvre pour programmeur social et je ne demanderais jamais de conseils sur la manière de réagir, car les petites garces ont clairement tort!
Posséder ce que vous êtes bon. Et je veux vraiment dire en prendre la responsabilité. parce qu’il ne faut qu’une gaffe pour un twit pour vous deviner. Ne demande pas la permission d'être bon. Sache juste tes affaires. La fin.
la source
Rappelez-vous ceci: le pire code que vous verrez jamais est le vôtre!
Jeff Atwood de codinghorror.com a écrit beaucoup sur le sujet, vous pouvez commencer ici: http://www.codinghorror.com/blog/2009/07/nobody-hates-software-more-than-software-developers.html
Si vous voulez vous améliorer, commencez à lire des articles sur le style de codage, les modèles, les flux de travail, en gros tout ce que vous pouvez maîtriser. Apprenez aussi 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 programmez en binôme ou regardez le code des autres.
Faire des erreurs est inévitable, il faut les répéter.
la source
La plupart du temps, vous devriez dire «merci» à la personne qui vous a dit cela.
Il est fort probable qu'ils se soucient de leur profession, de leur travail, de leur équipe et de vous.
Il peut être difficile de prendre des critiques. Ne t'énerve 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 ne cessent de s'améliorer (j'espère). Le seul moyen de connaître son amélioration est de le faire savoir par d'autres personnes ou de consulter mon code.
Essayez de regarder le code que vous avez écrit au début de votre carrière. Qu'est-ce que cela ressemble à vous maintenant? Cela a-t-il l'air aussi bon que vous le pensiez quand vous l'avez écrit;)
la source
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. A ce stade, votre code sera en désordre. Donc, vous refactor pour rendre le code propre. Ensuite, profilez et voyez ce que vous devez optimiser pour le rendre rapide. L'astuce consiste à refactoriser en permanence, sinon le désordre grandira. Vous devez nettoyer votre code régulièrement, tout comme vous devez nettoyer votre maison.
Les revues de code sont absolument essentielles. Votre code doit être examiné par au moins une autre paire d'yeux. Lorsque vous passez d'innombrables heures à examiner votre code, vous vous y habituez et vous pouvez facilement rater un bogue ou une odeur de code que votre collègue pourrait remarquer instantanément.
En outre, 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 papier 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 même, si vous expliquez votre code à une collègue et que quelque chose n’a aucun sens pour elle, cela indique que vous devez refactoriser votre code.
Lors de l'examen du code, il est très important que l'auteur et l'examinateur vérifient leur ego à la porte. Le but est d'améliorer le code. Le critique doit donc être respectueux et l'auteur doit garder l'esprit ouvert. Rappelez-vous que ce sont vos collègues qui devront maintenir votre code, donc ce doit ê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, reformulez-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 disposer d’un framework de tests unitaires, car sans celui-ci, 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.
la source
La réponse de Jay qui recommande les livres est bonne, mais on dirait que vous êtes déjà à un tournant au travail.
Passé:
Présent:
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 à peu près tous les domaines s’il ya suffisamment d’attention.
Utilisez cela comme une opportunité; en supposant que vous procédiez à des examens par les pairs (avec les autres développeurs de votre équipe), ils leur suggèrent que ce processus est important et que tout le monde peut en tirer des leçons.
Au départ, ce sera un examen rapide avec le résultat suivant: "Ouais, ça va." Avec un effort un peu plus ciblé, vous pouvez échanger des idées les unes sur les autres: "Ouais, ça fonctionne, mais vous auriez pu l'aborder de cette façon, ce qui aurait permis de clarifier votre objectif ...". Prenez des notes pour l’avenir même si le code est jugé bon à déployer.
Si cela réussit, vous devez convaincre votre équipe et votre responsable, ce qui implique souvent de leur expliquer les avantages. Pour les autres développeurs, c'est une opportunité d'apprendre. Pour votre responsable, c'est l'occasion de renforcer les compétences de l'équipe à moindre coût, 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!).
C'est un changement de culture que vous ne pouvez pas forcer seul, 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 gestionnaires reconnaîtront que vous travaillez à améliorer l’ensemble de l’équipe, ce qui mérite d’être récompensé.
la source
La réponse à cette question se trouve dans les entreprises de la nouvelle génération. Je suis allé chez des sociétés comme Google et FaceBook et je vois que si vous suivez le processus Agile / Scrum religieusement, vous pourrez alors écrire un meilleur code et l’améliorer à chaque sprint.
La réponse est une refactorisation continue. Les outils de développement modernes tels que Visual Studio comportent de nombreux outils qui vous aident dans ce processus. Si vous suivez le processus de développement du logiciel Scrum, dites par exemple que vous avez écrit un code incorrect dans le cycle 1 du sprint et que quelqu'un l'a fait remarquer lors de la révision, puis dans le cycle 2, vous avez la possibilité de le reformuler.
Ces problèmes se posent en premier lieu par manque de bonne procédure. La solution consiste donc à mettre au point un bon processus de développement logiciel pour votre équipe et à pratiquer le refactoring continu.
la source
Je les en remercie, puis leur demande d’expliquer ce qui le rend mauvais et comment il faudrait l’améliorer.
Si vous reconnaissez que la personne qui donne les commentaires a du sens, envisagez d’apporter des modifications à l’avenir. Mais rappelez-vous, ce n'est pas parce que quelqu'un dit que c'est vrai.
Pouvez-vous donner des exemples spécifiques de ce qui a été appelé "un gâchis"?
la source
Tout d'abord, quelqu'un qui dit que votre code est un gâchis 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 à prendre en compte.
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. Évidemment, il y a aussi 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 manière 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, avec le temps, vous pourrez deviner qui a écrit le code en fonction du style. Vous développerez également votre propre style et celui-ci changera à mesure que vous gagnerez de l'expérience et que vous apprendrez votre métier.
Ainsi, chaque fois que quelqu'un dit que votre code est un gâchis, vous devez comprendre s'il parle de la structure ou du style . Ce sont deux choses très différentes. la structure est objective tandis que le style est absolument subjectif.
Cela étant dit, tout retour d'information constructif d'autres programmeurs peut être très précieux pour vous. Tout dépend de vous et de la manière dont vous prenez les critiques. Avec le temps, vous saurez qui est l’opinion qu’il faut prendre à cœur contre qui doit prendre avec un grain de sel.
Au fur et à mesure que vous avancez dans votre carrière, vous examinerez votre propre code et des choses que vous pourriez faire différemment, de meilleure qualité, plus propres et plus rapides. Tout cela fait partie du processus d'apprentissage et voir vos propres erreurs passées est une indication réelle que vous perfectionnez et améliorez votre art.
Ne laissez pas un peu de critique vous décourager. Prenez ce que vous pouvez en tirer et si c'est significatif et utile, ajoutez-le à votre stock de connaissances.
la source
Bien qu'il soit important de reconnaître que votre propre code est un gâchis (sentiment très commun chez les programmeurs, en particulier à mesure qu'ils acquièrent de l'expérience et que leurs codes évoluent), il est encore plus important d'écouter lorsque d'autres personnes vous le disent.
Dans votre propre code, vous ne pouvez identifier qu'un nombre limité de problèmes, car celui-ci a été créé en tenant compte de vos connaissances actuelles en matière de programmation.
La révision du code est une opportunité d'apprentissage essentielle, car elle vous expose probablement à de nouvelles connaissances que vous n'aviez pas pendant que vous travailliez sur le code (sinon, vous l'utiliseriez et il n'y aurait pas de gâchis).
Je pense que le traitement des commentaires négatifs comporte deux parties.
1. Déterminez la nature des problèmes soulevés et ce que vous devriez en apprendre
Lors de l'examen ou de la révision de mon code, je trie des informations sur les problèmes de code dans ces compartiments:
Notez que cela va d’objectifs très objectifs ("cela se dissipera lorsqu’ils seront déployés sur notre serveur de production") à des éléments très subjectifs ("je n’aime pas la façon dont vous avez nommé les variables").
2. Déterminez quelles modifications (le cas échéant) seront apportées au code à la suite 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 pourrait ou non avoir de l'importance, en fonction des parties impliquées et des spécificités de votre situation (ancienneté, etc.). Mais les résultats possibles sont à peu près les suivants:
Vous avez appris qu'il est douloureux d'obtenir des commentaires négatifs et que cela pourrait très bien être douloureux à chaque fois dans le futur. Cependant, il ne vous reste plus à apprendre à quel point il est important d’apprendre et à apprendre comment le processus vous aide à améliorer votre professionnalisme et votre lieu de travail pour obtenir une meilleure base de code.
la source
Ne te sens pas brisé. Finalement, vous apprendrez des erreurs. Une fois que vous avez terminé avec le problème, vous pouvez parler à un gars, ce qui lui donne le sentiment que vous souhaitez vous améliorer. Essayez d'écouter plus et de discuter moins.
J'ai vécu cette situation et je peux comprendre.
la source
TL; DR
Mon simple, "trop longtemps n'a pas lu (toutes les réponses - excuses, j'espère trouver le temps de plus tard et de modifier / modifier cela si nécessaire)" réponse / astuce:
Un bon, peut-être le meilleur exemple de cette mentalité de clique agressive et gangsta, est la foule des forums XDK, et le pire des pires trophées que je remets à CyanogenMod pour les forums Android / foule de canaux IRC.
C'était un peu plus long que prévu Mon propos était censé être - obtenir des critiques variées, mais focaliser sur la critique honnête de la part des personnes connaissant leur métier et sachant ce que sont les critiques constructives . 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 sur une chose qui peut être commune aux commentaires, faites une introspection plus approfondie.
la source