Après avoir écrit du code, pourquoi ai-je l'impression que «j'aurais mieux écrit» après un certain temps? [fermé]


12

Je travaille sur mon projet hobby en C ++ depuis plus de 2 ans. Chaque fois que j'écris un module / une fonction, je le code avec beaucoup de réflexion. Maintenant, voyez le problème,

do {
  --> write the code in module 'X' and test it
  --> ... forget for sometime ...
  --> revisit the same piece of code (due to some requirement)
  --> feel that "This isn't written nicely; could have been better"
} while(true);

Voici 'X'n'importe quel module (qu'il soit petit / grand / moyen). J'observe que cela se produit, quel que soit l'effort que je consacre au codage. Donc, surtout, je m'abstiens de voir un code de travail. :)

Est-ce un sentiment commun à beaucoup de gens? Ce phénomène est-il spécifique à la langue? (Parce qu'en C ++ on peut écrire la même chose de différentes manières).

Que dois-je faire si j'éprouve ce sentiment de refactorisation pour un code de production du monde réel, où le changement du code de travail ne me gagnera pas beaucoup d'éloges, mais il peut plutôt provoquer des problèmes s'il échoue.


14
Je serais plus inquiet si je ne rencontrais jamais de problèmes avec mon ancien code. Cela montre que vos compétences se développent.
Darren Young

1
Si vous regardez votre ancien code et ne pensez pas "bon sang, pourquoi ne l'ai-je pas fait de cette façon à l'époque?!", Alors vous n'en avez pas assez appris depuis que vous avez écrit le code.
sbi

Réponses:


17

Ce phénomène est très courant et n'est pas spécifique aux programmeurs. Chaque fois que vous effectuez une tâche intellectuelle, vous remarquerez des dizaines d'endroits où vous auriez pu vous améliorer - après avoir pris de la distance. Demandez à un homme sage (WO-) qui n'a jamais écrit une thèse, et ils vont vous dire une chose: «Ne regardez pas Vous y trouverez une erreur sur le premier coup d' oeil. »

Il y a essentiellement deux choses pour éviter la boucle de refactoring:

  1. Lors de l'écriture et de la conception, essayez d'obtenir la perspective éloignée le plus tôt possible. Demandez à un collègue d'examiner votre conception / code. Regardez à nouveau après un week-end. Regardez-le en état d'ivresse ou en état d'ébriété (mais attention: ne changez rien avant d'être sobre).
  2. Vivez avec l'imperfection. S'il n'est tout simplement pas joli, mais fonctionne bien (lire: fait un bon travail pour répondre à toutes les exigences, y compris l'extensibilité et la lisibilité), laissez-le reposer et contentez-vous du bon travail que vous avez fait, sans vous efforcer d'obtenir le travail parfait.


3

La refonte continue est la voie à suivre. Changer le code de travail ne causerait pas de problèmes et devrait être encouragé s'il est fait correctement. Si votre code est entièrement testé à l'unité, vous pouvez re-factoriser votre code en toute confiance.

La seule chose que vous pouvez prédire sur le code de production du monde réel est que cela changera. N'essayez pas de deviner comment cela va changer, quelles nouvelles techniques vous apprendrez demain. En bref, n'essayez pas de rendre votre code "parfait". Faites-le aussi bien que possible avec vos connaissances actuelles. Assurez-vous également que votre code est entièrement testé et extensible.

Je passe de 20% à 30% de mon temps à refactoriser le code existant. Je travaille dans une entreprise technologique et la "direction" ne s'est jamais plainte de changer le code existant. Cependant, je me rends compte que cela peut être un problème dans certaines entreprises. Martin Fowler a même une section à ce sujet dans son livre de refactoring .

En résumé, c'est un sentiment commun dans mon expérience, mais ce n'est pas négatif.


2

Chaque module / fonction est né et évolue dans un monde de priorités. Une fois qu'il suffit de servir les objectifs du monde extérieur, il stagne souvent. Tout est finalement un échafaudage au service de l'objectif supérieur. Oui, nous devons être obsédés par le code, et cela peut aussi nous faire stagner. Ce serait peut-être une bonne chose pour vous de vous éloigner un peu du code lui-même et de réfléchir davantage aux processus qui se déroulent en vous, le producteur du code.


2

Est-ce un sentiment commun à beaucoup de gens? Ce phénomène est-il spécifique à la langue?

Cela signifie que vous élargissez vos connaissances et vos points de vue.

Si vous n'avez aucune tâche de priorité plus élevée, vous devez toujours revenir en arrière et améliorer votre code.


"... revenir en arrière et améliorer votre code." - qui vous paiera pour cela? Une fois que votre code fonctionne, passez à autre chose. En apprenant et en grandissant en tant que programmeur, vous trouverez TOUJOURS de meilleures façons de faire les choses et vous sentirez que vos efforts antérieurs pourraient être améliorés. Résistez à l'envie de faire quoi que ce soit à ce sujet - revenir en arrière et améliorer votre ancien code est généralement une perte de temps suprême.
Dawood dit de réintégrer Monica le

1
@David Wallace - Si personne ne devait jamais revenir à l'ancien code, nous n'en ferions pas autant d'histoires.
JeffO

1
"Une fois que votre code fonctionne, passez à autre chose" - vous ne croiriez pas quel genre de bugs j'ai vu dans le code de production, parce que le code fonctionnait;)
BЈовић

@Jeff O - c'est très vrai. Si je veux conserver l'ancien code, j'envisagerais de le réparer, que ce soit mon code ou celui de quelqu'un d'autre. Mais à moins qu'il y ait un projet avec quelques dollars derrière qui nécessite de maintenir ce code, alors il n'y a aucun moyen de justifier le temps passé à le ranger. Sauf si c'est buggy, bien sûr.
Dawood dit de réintégrer Monica le

@VJovic - s'il y avait des bugs en production, c'est parce que le code ne fonctionnait pas. Je pense que l'OP parlait de code qui fonctionne correctement, mais est moche.
Dawood dit de réintégrer Monica le

2

J'ai toujours pensé qu'une personne prend un cours de mathématiques pour renforcer ses compétences dans la classe précédente. L'algèbre semblait difficile, jusqu'à ce que vous preniez l'algèbre II; Ensuite, les compétences que vous avez apprises en algèbre sont devenues utiles. C'est la même chose dans la programmation, l'écriture, le travail du bois ou autre chose.

Lorsque vous avez suivi un cours de programmation, vous avez appris If-then-else, ce qui a fait beaucoup de choses jusqu'à ce que vous appreniez les commutateurs. Lorsque vous apprenez quelque chose de nouveau, vous passez par cette progression, tout le monde le fait.


2

J'ai le même sentiment chaque fois que je lis la plupart des codes écrits par moi-même dans le passé. C'est une bonne chose, cela signifie que vos connaissances et votre style de codage se sont améliorés au fil des ans.

En ce qui concerne la modification du code de production, c'est un gros non sauf si vous avez repéré des bogues évidents. Non seulement parce que cela pourrait être une perte de temps, mais surtout parce que la grande majorité des bogues logiciels créés sont du type de ceux qui sont introduits lorsque des modifications sont apportées aux programmes publiés. Statistiquement, il est probable que vous introduisiez des bogues imprévus. S'il n'est pas cassé, ne le réparez pas.


1

Développer une application, c'est l'améliorer et la rendre meilleure; c'est un processus continu, donc pendant que vous programmez, vous gagnez plus d'expérience et de connaissances. Cela signifie également que vous développez également, donc lorsque vous regardez votre ancien code, vous pouvez découvrir qu'il peut être amélioré.

Si vous n'avez pas ce sentiment, cela signifie l'une des deux choses suivantes:

  1. Vous êtes toujours au même niveau de compétence.
  2. Votre code est déjà parfait (peu probable).
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.