code sentimental [fermé]

Question

Je suis tombé sur un article traitant de "l'admiration du code". En gros, l'auteur explique comment les développeurs devraient être plus sceptiques à propos du code qu'ils écrivent. Comment nous pouvons "admirer" notre code, nous nous y attachons trop, ce qui nous rend plus vulnérables aux bugs et autres malheurs qui pourraient se trouver devant nous.

Que pensez-vous de ce problème? Et avez-vous plus de conseils pour éviter / être plus au courant de ce problème?

Answer 1

Il y a quelques années, je travaillais avec un autre sur un petit "passe-temps". projet, et je me suis rendu compte que nous devions réévaluer les choses. Nous avions écrit beaucoup de code mais ce n’était pas du tout bon code.

Nous ne voulions pas vraiment "jeter". Tout le travail que nous avions fait. Mais j’ai réalisé quelque chose: ce qui importait le plus, c’était la quantité de travail que nous devions mettre à maintenant .

Nous ne pouvions pas changer le fait que nous avions déjà mis beaucoup de travail dans le projet. Le seul moyen de minimiser la somme totale dont le projet aurait besoin serait donc de minimiser la quantité de travail que nous n'avions pas encore fait .

Depuis ce jour, j'ai cessé d'être attaché à mon code. Si je suis convaincu que le jeter et partir de zéro signifie moins de travail que de le conserver et de l'adapter à mes besoins, je le jetterai.

Answer 2

Mon professeur d’art secondaire nous encourageait à prendre ce que nous considérions être nos meilleurs dessins et à les déchirer; il a appelé cela "nettoyer l'âme". Son raisonnement était que, en tant qu’artistes, nous étions motivés à créer des œuvres d’art. Chaque fois que nous produisions quelque chose qui nous plaisait et qui nous procurait de la satisfaction, notre motivation à continuer de créer diminuait.

J'ai donc suivi ses conseils et j'ai déchiré mes meilleures affaires, et cela a fonctionné. Au lieu de passer mon temps à admirer mon ancien travail, j'ai créé de nouvelles choses et je me suis amélioré. J'ai essayé de suivre le même principe avec mon code, mais cela ne fonctionne pas vraiment: mon ordinateur est doté d'une coque en plastique robuste qui est presque impossible à déchirer.

Answer 3

Je publie un fragment du blog de Jeff Atwood, Sucer moins chaque année . et je suis d'accord à 100%.

  

J'ai souvent pensé que sucer moins   chaque année est comment humbles programmeurs   améliorer. Vous devriez être mécontent de   code que vous avez écrit il y a un an. Si vous   ne sont pas, cela signifie soit A) vous   n'ont rien appris en un an, B)   votre code ne peut pas être amélioré, ou C) vous   ne revisitez jamais l'ancien code. Tous ces   sont le baiser de la mort pour les logiciels   développeurs.

Answer 4

Nous aimons bien admirer notre beau code, mais il n’est pas toujours facile de savoir quoi admirer. Un code compliqué et élaboré est parfois confondu avec un code admirable, tandis que l’élégance et la simplicité devraient plutôt être ce qu’il faut rechercher.

Deux citations me viennent à l’esprit:

  

"Le débogage est deux fois plus difficile que l'écriture   le code en premier lieu.   Par conséquent, si vous écrivez le code en tant que   intelligemment que possible, vous êtes, par   définition, pas assez intelligent pour déboguer   il. & # 8221;

     

- Brian Kernighan

et

  

" Rendre tout aussi simple que   possible, mais pas plus simple. "

     

- Albert Einstein

Answer 5

Jonathan Edwards a écrit un magnifique essai sur ce sujet, à la suite des travaux sur le livre O'Reilly Beautiful Code . Voici le dernier paragraphe, mais le reste de l'essai mérite également d'être lu.

  

Une autre leçon que j'ai apprise est de se méfier de la beauté . Il semble que l’engouement pour un design mène inévitablement à la déchirure du cœur, alors que les laides réalités négligées s’imposent. L’amour est aveugle, mais les ordinateurs ne le sont pas. Une relation à long terme & # 8211; maintenir un système pendant des années & # 8211; enseigne à apprécier davantage de vertus domestiques, telles que la franchise et la conventionalité. La beauté est un fantasme idéaliste: ce qui compte vraiment, c’est la qualité de la conversation sans fin entre programmeur et code, car chacun apprend et s’adapte l’autre. La beauté n'est pas une base suffisante pour un mariage heureux.

D'autres versions de cette même sagesse existent dans d'autres domaines. Samuel Johnson, à propos de l'écriture:

  

Relisez vos compositions et, partout où vous rencontrerez un passage que vous jugez particulièrement bon, biffez-le.

La version de William Faulkner était bien plus succincte: "Tuez vos enfants chéris".

Mon beau-père travaille comme monteur de film et il évite soigneusement le décor dans lequel le film est tourné. Lorsqu'il doit se rendre, il protège ses yeux autant qu'il le peut. En effet, lorsqu'il décide d'inclure ou non une scène dans le film final, il ne veut pas être influencé par les efforts qu'il a fallu pour tourner la scène. Ce qui compte, c'est le bon fonctionnement de la scène dans le film final.

Mon essai, "Mon évolution en tant que programmeur" (auquel je ferais un lien si je n'étais pas un nouvel utilisateur), consiste principalement à apprendre le scepticisme à propos du code que j'avais écrit: que cela fonctionne, qu'il soit utile ou non, qu'il soit compréhensible (la programmation en binôme a été un véritable réveil ici). C'est dur!

Answer 6

Je n’admire jamais mon code. J'admire le code des autres peuples que j'emprunte " et essayez de les imiter ou de les améliorer et je trouve que plus je sais, en particulier sur le codage, plus je trouve que je ne sais pas. La seule chose qui vaille la peine serait que les pairs programmeurs admirent mon code et l’empruntent.

Answer 7

Je pense qu'il a un bon point. C’est frustrant de travailler avec des personnes qui en ont trop, car cela nuit vraiment au travail d’équipe et à la recherche de la meilleure solution au problème.

Comme je peux être un peu délirant, j'essaie de mettre en place des pratiques qui me garderont ancré dans la réalité. Pour le code,

• Tests unitaires : ils me permettent de rester plus concentré sur ce que le code est censé faire, par opposition à toute "beauté" abstraite.

• Partage de la propriété du code : il existe deux camps: responsabiliser davantage les utilisateurs et espérer que l'orgueil prenne le dessus ou donner moins et laisser la pression de leurs pairs entrer en jeu. Je crois que donner plus de propriété aux gens peut conduire à cette admiration du code Nous pratiquons la propriété partagée de code, donc je suis constamment obligé de voir quelqu'un réécrire mon code parfait pour le rendre meilleur (dans leur esprit). J'ai vite réalisé que l'admirer était une perte de temps et une émotion difficile.

• programmation par paires : travailler côte à côte avec quelqu'un vous permettra de rester réaliste.

• Autres commentaires : ce sont toutes des boucles de commentaires, mais il y en a d'autres. Il n'y a pas de meilleur moyen de voir si quelque chose fonctionne que de regarder quelqu'un (essayer de) l'utiliser. Mettez votre travail devant autant de personnes que possible. Avoir des critiques de code. Lisez le code d'une autre personne . Exécutez les outils d'analyse de code statique .

Answer 8

Je suis avec PurplePilot - je n’admire pas mon propre code et, en tant que tel, je suis constamment à la recherche de nouvelles façons plus efficaces (plus faciles) de faire la même chose. J'aime le livre Effective c #, qui contient beaucoup de code utile que j’admire.

Je n'hésiterais pas à jeter le code et à recommencer, mais pas nécessairement à zéro, c'est-à-dire qu'en écrivant du code pour un scénario spécifique puis en le jetant, vous aurez probablement une meilleure compréhension du scénario. En d’autres termes, c’est un "problème épineux" ou vous avez trouvé un autre moyen qui ne fonctionne pas à la Edison.

Cela soulève une question plus générale: si le code n’est pas jeté, ou au moins revisité, le développement sur des bibliothèques qui stagnent devient-il une bonne chose?

Answer 9

Il n’ya rien de mal à admirer votre code ... cela fait partie du processus de renforcement positif qui vous incitera à écrire du code plus riche et de meilleure qualité à l’avenir.

Cependant, l'admiration égarée ou abusée peut être un problème. Si le code n'est vraiment pas bon, ou comporte des bogues qui n'ont pas été exposés par l'unité ou par d'autres tests, ou qui ont besoin d'être refactorisés / redessinés / remplacés, alors cet amiratoin égaré est un problème. Et utiliser l’admiration comme excuse pour ignorer une partie du processus, comme l’analyse de code ou le manque de scepticisme à l’égard du code, constitue un abus d’admiration.

Comme tout ce qui est bon, l'admiration du code peut être mal placée ou mal utilisée - cela ne veut pas dire qu'il est mauvais en soi. Cela reviendrait à dire que "la religion est une mauvaise chose, car elle provoque des conflits et des guerres entre les peuples".

Answer 10

Deux mots: révision du code.

Rassemblez deux développeurs ou plus et invitez-les à réviser / critiquer / commenter votre code. 'twill jette une lumière (certes dure) sur votre code.

Answer 11

Il est peut-être préférable d'avoir une perspective plus saine: nous ne sommes pas des spécialistes de la roquette, nous ne guérissons pas le cancer, c'est juste un travail.

(Oui, il est raisonnable d'être fier de tout un bâtiment que vous avez aidé à construire si vous êtes architecte, mais leur estime de soi est-elle en grande partie intégrée dans un projet individuel ou dans un placard au 3ème étage ils ont conçu par eux-mêmes?).