Comment réagiriez-vous si quelqu'un vous disait que votre code est un gâchis?

86

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?

teamwork code-reviews maintenance

— débutant
source

51

"Mais il semble que je ne sois pas un programmeur de génie comme dans les films" . Votre erreur est de croire ce que vous voyez dans les films sur les développeurs de logiciels, les pirates et à peu près tout ce qui concerne la technologie du monde réel.

— Stephen C

160

Toutes nos félicitations! A partir d'aujourd'hui, vous êtes officiellement un vrai programmeur! Se faire dire que tu es terrible est l’une des étapes les plus importantes de ce métier. Je ne peux pas sous-estimer ceci: chaque programmateur professionnel s'est vu dire que quelque chose qu'il avait écrit était affreux à un moment ou à un autre, et ça vous gêne quand vous débutez, mais c'est vrai et vous l'entendrez encore plus souvent dans le cours de votre carrière! Bouclez-vous, vous venez de rejoindre la profession Les bons programmeurs prennent ces jabs et apprennent à ne pas faire les mêmes erreurs (au lieu de cela, ils en font différentes à chaque fois!)

— Jimmy Hoffa

15

@ newbie lorsque vous êtes nouveau et que vous avez construit un peu d'ego et que vous n'avez pas assez foiré pour réaliser que vous êtes mauvais, je suis mauvais, nous sommes tous mauvais à cela parce que c'est vraiment difficile. Si vous avez encore un ego, il ira au passage après avoir commis plus d'erreurs. Sérieusement, levez la main si vous êtes un ingénieur et avez accidentellement soufflé une base de données avant de lever la main

— Jimmy Hoffa

14

Déçu? Pourquoi diable seriez-vous déçu? Mon ancien directeur technique m'a appelé dans un article qu'il a écrit (il ne m'a pas nommé en particulier, mais tous les membres de notre équipe savaient de qui il parlait), et dès que j'ai eu la chance de le savoir, j'ai cité l'article dans l'une de mes réponses ici . De plus, je suis le développeur pervers décrit dans cette question . J'ai encouragé le PO à poster la question et j'y ai même répondu;)

— yannis

19

N'oubliez pas les gens, juste parce que quelqu'un a dit que le code était mauvais ne le rend pas vrai. Après avoir entendu "votre code est un gâchis", le PO mérite "et voici pourquoi." Ensuite, l' analyse peut commencer.

— Tony Ennis

175

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.

— onlineapplab.com
source

27

Vous avez raison! Je ris de mon code il y a 2 ans. Donc, je suppose que je vais aussi rire de mon code dans deux ans. Je suis juste devenu un peu émotif à ce sujet. Quoi qu'il en soit, je vais essayer de devenir meilleur.

— novice

5

@newbie: Voilà. C'est ce que vous devez vraiment savoir. Ma devise était: "Je ne suis jamais aussi bon que dans deux ans" depuis plus de dix ans maintenant. Et je ne me suis pas encore trompé. Je n'ai pas appris cela beaucoup plus loin dans ma carrière que vous. Votre collègue vous a rendu un grand service.

— pdr

27

Je pense que six mois devraient suffire à haïr votre code. Je crains qu'un jour je trouve le code que j'ai écrit six mois auparavant sans trouver quelque chose que je déteste à ce sujet. Ce serait un signe que je n'ai pas grandi en tant que programmeur.

— zzzzBov

37

2 ans! Je peux rire l'après-midi au code que j'ai écrit le matin.

— dan_waterworth

9

Je dirais également que la révision de code est un processus extrêmement utile. Comme l'indique cette réponse, si vous êtes un bon programmeur, vous penserez aussi qu'il s'agit d'un code terrible - c'est naturel. Cependant, je dirais aussi que votre réviseur de code n’aborde pas correctement le processus de révision. C'est censé être un processus de critique constructive où les connaissances sont transférées, pas un processus pénal négatif où le programmeur en cours de vérification se sent insignifiant. Cela annule beaucoup de bien qui peut provenir d'un examen.

— Mattygabe

68

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.

— billy
source

bel article. :) donc je traite juste avec mon ego.

— novice

2

@ newbie exactement. Lorsque vous recevez des critiques de votre code, cela ne peut vous contrarier que si votre ego est lié à la qualité de ce code. Divorcez votre ego du code et le problème disparaîtra.

— btilly

5

Je suis d’accord pour être fier de la qualité de votre apprentissage, mais vous devriez également être fier de la façon dont vous codez. Si vous n'êtes pas fier de la façon dont vous codez, vous ne serez pas amené à devenir meilleur.

— Bryan Oakley

1

Et vous devez également faire attention à ne pas être fier d'apprendre, car cela peut entraîner les mêmes problèmes si vous n'êtes pas très bon en apprentissage.

— Nico Burns

Je pensais que l'orgueil était l'un des 7 péchés capitaux? Qu'est-ce qui se passe avec tout le monde qui le recommande ces jours-ci? Que diriez-vous juste de vous sentir satisfait d'avoir fait du bon travail?

40

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".

— Maximus Minimus
source

2

Vouloir «faire le travail», c'est lutter pour la médiocrité. Vous avez raison, cela fonctionne et peut être efficace - il suffit de regarder les produits chinois. Mais ce qui rend 20 ans de programmation vaut la peine d’être un ami, c’est la volonté d’améliorer les choses. Regardez en arrière sur 20 ans, qu'est-ce que cela révèle - faire le travail ou le faire avec fierté?

— Kingdango

9

Il s'agit toujours de "faire le travail", sauf si vous écrivez une sorte de projet artistique étrange basé sur du code. Écrire «bon code» contre «code médiocre» est un compromis entre l’achèvement de la tâche immédiate et l’amélioration de la maintenance du code pour que le travail soit effectué à l’avenir. Ignorer cela conduit au perfectionnisme, ce qui conduit à ne rien faire. Un code médiocre écrit rapidement vaut mieux qu'un bon code écrit lentement pour un script unique.

— Gort le robot

8

À l'instar des dettes monétaires, la dette technique augmente rapidement et apprendre à gérer une dette technique est l'une des compétences principales d'un programmeur dans le monde réel. Toute personne qui a suffisamment de temps pour faire un travail parfait à chaque fois est incroyablement bonne, sérieusement sous-utilisée ou se fait des illusions.

— Mark Booth

1

Il peut être difficile de trouver le bon équilibre, d'autant que le fait d'aller de l'avant avec un design médiocre est souvent beaucoup plus visible que de perdre trop de temps à affiner un design alors qu'un médiocre se serait révélé parfaitement adéquat tout au long de sa vie utile.

— Supercat

1

Cela m'attriste vraiment car "faire le travail" et "perfection technique" n'ont pas besoin d'être les mondes à part que vous décrivez. Personnellement, je ne prends pas beaucoup de satisfaction pour une partie de mon code qui a été publiée qui est totalement louche et qui le soit en raison de contraintes de temps et, comme vous le dites, pour "faire le travail" .

— Crmpicco

39

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,
les programmeurs qui envoient toujours du code sémantiquement correct,
les programmeurs qui trouvent toujours la solution optimale et l'algorithme le plus rapide,
programmeurs dont le code est facile à regarder.

Ils finissent à peine par être la même personne.

Et il y a des programmeurs qui doivent grandir et:

demander ce qui ne va pas,
ne prenez aucun commentaire personnellement, en tant que mesure de leur valeur en tant qu'être humain;
Réalisez qu'il existe des directives de syntaxe dans les équipes, et qu'elles doivent être suivies et qu'elles sont arbitraires, elles ne doivent donc pas être discutées ad nauseam , car il n'y a pas de solution optimale, ni de dernier mot;
s'améliore en commentant leur code;
s'améliore en commentant leur code; (sic)
trouver des solutions plus faciles à déboguer, moins intelligentes, à des tâches simples et banales;
prendre un cours en SQL
(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 AMD64et x86ne sont pas obligés par le pouvoir de votre prose. Gardez les choses simples.

— ZJR
source

3

Rire littéralement à haute voix. tellement bon. roflcopters

— kingdango

1

AMD64 et x86 ne sont pas obligés par la puissance de votre prose. - absolument génial.

— Sam Brinck

+1 pour prendre un cours en SQL

— HLGEM

28

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é).

— Kryptic
source

26

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.

Ç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.

Mais il semble que je ne sois pas un programmeur de génie comme dans les films.

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.

Pouvez-vous me donner des conseils sur comment être meilleur?

Lire et pratiquer. Découvrez des livres comme Code Complete ou The Pragmatic Programmer . Rechercher sur Amazon pour des livres similaires.

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 ..

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.

— Geai
source

2

+1 pour le réassembler et 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é.

— Jimmy Hoffa

2

"90% des programmeurs dans les films sont tellement faux que j'ai des larmes à la fin de la séquence." 90%? Quels films regardez- vous ? : PI n'a pas vu un film qui décrit avec précision ce que nous faisons. Et puis il y avait "Espadon" et "Jour de l'Indépendance" ...

— Nik Bougalis

Bien mis et succinctement!

— Kingdango

16

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.

— Paul
source

9

" 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 " - génial; +1

— Maximus Minimus

Oui, et je veux apprendre tout ce que je peux

— novice

@ mh: J'ajouterais qu'une personne sage apprendra généralement beaucoup plus à se tromper que d'avoir raison. Cela ne veut pas dire qu'il faille essayer de se tromper, mais plutôt que de ne pas se décourager à ce sujet, à condition de profiter de l'occasion d'apprendre.

— Supercat

10

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:

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 que votre futur code sera forcément plus impressionnant puisque vous savez maintenant comment le rendre moins compliqué grâce à leurs conseils.

— Oméga
source

Il n'a pas commenté :( Mais voici mon code -> codereview.stackexchange.com/questions/18719/…

— novice

pourquoi pensez-vous qu'il est en désordre?

— novice

7

@newbie: Alors cet auteur n'est pas très bon. Comment un codeur est-il censé améliorer quelque chose sans savoir quel est le problème (pas même un indice!)?

— Omega

1

Ok merci ... je ne suis pas un programmeur JQuery non plus. Je suis un programmeur Java ....

— novice

1

Seul mon code est disponible pour lui cette fois. Quoi qu'il en soit, vous avez raison, je vais demander plus de détails à ce sujet. Merci :)

— novice

8

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.

Our team is composed of 5 programmers, and 4 of us are new

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 ...

"S'il y a suffisamment de réviseurs, tous les problèmes sont faciles à résoudre."

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.

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 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 ...

C'est là que réside le frottis

"Nous avons déployé notre programme au programme sans procéder à des tests approfondis."

Créateur UML Cribbing Grady Booch ...

L’ingénieur logiciel amateur est toujours à la recherche de la 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 de telle panacée.

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 :-)

— Eddie B
source

5

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.

— Michael Shaw
source

4

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.

— Erik Reppen
source

Amen. Et connaître vos affaires demande ... bien ... des efforts pour vous assurer de les connaître. Mais assurez-vous de faire sauter votre collier, c'est ce que tous les enfants d'élite font de nos jours. : /

— kingdango

Oui, je pense que je viens de donner des conseils ailleurs sur le fait que les développeurs les plus expérimentés soient les premiers à admettre qu'ils ont tort. Je peux avoir plusieurs personnalités.

— Erik Reppen

4

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.

— Lucas Hoepner
source

C'est un bon sentiment (le mien préféré est lié en ce que je commence toujours par supposer que le problème avec une application est de ma faute), mais malheureusement, il s'avère que non, le pire code que vous verrez ne sera peut-être pas le vôtre. Pas si vous êtes assez intelligent pour être ici et poser des questions à ce sujet en premier lieu ...

— Murph

4

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;)

— Fortyrunner
source

3

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.

— Dima
source

3

Pouvez-vous me donner des conseils sur comment être meilleur?

La réponse de Jay qui recommande les livres est bonne, mais on dirait que vous êtes déjà à un tournant au travail.

Passé:

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.

Présent:

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.

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é.

— Mat
source

3

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 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.

How to be better?

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.

— Avinash Kumar
source

3

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"?

— Tony Ennis
source

Les sentiments peuvent parfois être difficiles, mais c'est certainement ainsi que j'espère réagir.

— Thomas Padron-McCarthy

3

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.

— Stephen
source

3

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:

viole les exigences technologiques difficiles
- tout à fait faux (ne fonctionne pas ou ne répond pas aux exigences)
- échouera dans d'autres circonstances (changement d'environnement / de configuration)
- utilise une fonctionnalité obsolète et se cassera dans un avenir prévisible
viole les meilleures pratiques de l'industrie, manquant de choses telles que
- en utilisant une approche éprouvée à un problème spécifique
- performance
- rétrocompatibilité
- Facilité d'entretien
- style de codage
- Documentation
viole les meilleures pratiques en milieu de travail
- Identique à l'industrie, mais plus spécifique à l'entreprise / aux collègues et peut différer de l'industrie dans les détails
ne correspond pas à l'expertise personnelle
- peut être amélioré d'une manière ou d'une autre, selon l'opinion du réviseur

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:

régler le problème en entier
- réparer cassé
- format au style de codage requis
- etc
compromis si la question devait être traitée en tout ou en partie, car il pourrait y avoir
- pas de ressources (telles que le temps ou le budget)
- pas besoin (obtiendra seulement une amélioration insignifiante, compromettra la stabilité, etc.)
arriver à comprendre que la question soulevée est invalide
- les réactions (en particulier de la catégorie des opinions subjectives) peuvent très bien être nuisibles et ne doivent pas être prises à l'aveuglette

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.

— Rarst
source

1

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.

— Hisham
source

0

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 de modifier / modifier cela si nécessaire)" réponse / astuce:

Bonne vieille revue par les pairs. Demandez à différents équipages de mentalités collectives, de niveaux d’expertise et / ou d’ agressivité différents de réviser votre code.
Pour préciser un peu ce que j'entends par groupes de pairs "différents": la diaspora StackExchange est probablement le groupe le plus renseigné, professionnel et estimé en raison de la difficulté relative à en faire partie par rapport à Reddit, par exemple. Reddit a tendance à être très agressif dans les sous-reddits les plus populaires - mais curieusement, les sous-titres de programmation sont assez sympathiques (de ce que j'ai vécu).

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.

— skopp
source