À quelle fréquence exécutez-vous et testez-vous votre code pendant la programmation? [fermé]


16

Surtout lors de l'écriture de nouveau code à partir de zéro en C, je me retrouve à écrire du code pendant des heures, voire des jours sans exécuter le compilateur pour autre chose qu'une vérification de syntaxe occasionnelle.

J'ai tendance à écrire de gros morceaux de code avec soin et à ne tester à fond que lorsque je suis convaincu que le code fait ce qu'il est censé faire en analysant le flux dans ma tête. Ne vous méprenez pas - je n'écrirais pas 1000 lignes sans tester du tout (ce serait du jeu), mais j'écrirais un sous-programme entier et le testerais (et le corrigerais si nécessaire) après avoir pensé que j'avais fini.

De l'autre côté, j'ai vu principalement des débutants qui exécutent et testent leur code après chaque ligne qu'ils entrent dans l'éditeur et pensent que les débogueurs peuvent remplacer la prudence et la raison. Je considère que c'est beaucoup de distraction une fois que vous avez appris la syntaxe du langage.

Selon vous, quel est le bon équilibre entre les deux approches? Bien sûr, le premier nécessite plus d'expérience, mais affecte-t-il la productivité de manière positive ou négative? La seconde vous aide-t-elle à repérer les erreurs à un niveau plus fin?


3
Cela vous prend des heures ou des jours pour écrire un sous-programme entier?

1
@Thorbjorn Le sous-programme est long d'environ 999 lignes, et il est obscurci: #define h for(int c=y-3; y; c++/(randomTypeIDefinedEarlier)s*(float)4*(lol)sin((helloWorld)mysub(2,1,++a,*(r+z))); goto xkcd)Et ce n'est qu'une seule ligne.
Mateen Ulhaq

1
Les compilateurs peuvent parfois prendre beaucoup de temps pour compiler un programme. C'est pourquoi ce n'est pas une bonne pratique de compiler tout le temps. après chaque fonction est une bonne pratique. je recompile après avoir ajouté de nouvelles fonctionnalités ou un morceau de code difficile. Je l'utilise uniquement comme vérificateur de syntaxe. il n'y a pas de substitut pour vérifier soigneusement votre code et éviter les erreurs cachées et les comportements aléatoires.
Ross

Réponses:


6

Cela dépend VRAIMENT de l'aspect du projet sur lequel vous travaillez.

  • Lorsque je fais quoi que ce soit avec OpenGL (qui fonctionne comme une machine d'état), je compile et exécute constamment pour m'assurer que je n'ai rien accidentellement foutu. La définition d'une valeur sans oublier de la réinitialiser à la fin d'une fonction peut facilement faire en sorte que l'application affiche uniquement un écran noir.

  • Pour un développement à plus grande échelle "sous le capot", j'essaie d'obtenir le plus de tests possible au préalable. Étant donné que les tests peuvent me dire plus facilement ce qui s'est cassé, je peux passer un certain temps sans avoir à attendre la compilation généralement longue.

  • Pour la conception UX, j'utilise une sorte de concepteur visuel, qui regarde toujours la façon dont il fonctionnera (ou près de lui). Il s'agit essentiellement de toujours compiler le code de conception.


63

Personnellement, je dois travailler en petits morceaux car je ne suis pas assez intelligent pour conserver des heures de codage dans mon cache L1 biologique. En raison de mes capacités limitées, j'écris de petites méthodes cohérentes et je conçois des objets pour avoir un couplage très lâche. Des outils et des langages plus puissants permettent de coder plus facilement sans construire, mais il y a encore une limite pour moi.

Ma préférence est d'écrire un petit morceau, de vérifier qu'il fonctionne comme prévu. Ensuite, en théorie, je suis libre d'oublier les détails de cette pièce et de la traiter comme une boîte noire autant que possible.


12
Vote positif pour "... pas assez intelligent .." Je ressens cela depuis un certain temps.
leed25d

4
Et votre cache L2?
Mateen Ulhaq

J'allais voter contre, mais le score est à 42 ...
Wayne Werner

Les nouveaux modèles ont des caches L1 beaucoup plus gros. Quand avez-vous acheté le vôtre? Vous voudrez peut-être opter pour une mise à jour matérielle.
Peter Ajtai

Eh bien, ce n'est pas l'âge du modèle autant que le fait qu'il s'agissait de la ligne "budget". :(
dss539

17

J'aime écrire mon test avant d' écrire mon code d'implémentation. J'aime ça pour trois raisons:

  1. Écrire mon code de test à l'avance m'aide à réfléchir à la façon dont mon code doit être utilisé. Cela m'aide à penser à des cas marginaux auxquels je ne pensais pas lorsque je concevais à l'origine mon programme.
  2. Je sais que j'ai fini d'écrire le code d'implémentation lorsque tous mes cas de test ont réussi.
  3. Prendre l'habitude d'écrire des tests avant le code a également pour effet de prouver que votre code n'a ajouté aucun nouveau bogue (en supposant que vous ayez écrit de bons cas de test).

2
"Je sais que j'ai fini d'écrire le code d'implémentation lorsque tous mes cas de test ont réussi." - Comment déterminez-vous si vous avez écrit tous les cas de test nécessaires?
dss539

1
Voilà une excellente question. À mon avis, vous ne pouvez jamais être complètement certain que votre code fonctionne correctement, sauf si vous avez une preuve formelle le déclarant. Je considère les tests unitaires comme une preuve que votre code a tendance à faire ce que vous voulez. Mais, à mesure que les fonctionnalités que vous ajoutez augmentent, le nombre de cas de test que vous écrirez augmentera probablement aussi. En cas de doute, demandez à quelqu'un d'autre d'examiner vos cas de test et demandez-leur les cas auxquels vous n'avez pas pensé.
David Weiser

4
@David - comment prouvez-vous formellement que votre preuve formelle ne contient aucune erreur? Comment prouvez-vous formellement que les exigences perçues par vous correspondent aux exigences réelles. Vous pouvez prouver formellement qu'une description correspond à une autre, mais il est parfaitement possible que les deux descriptions soient incorrectes de la même manière - surtout si les deux descriptions ont été écrites par la même personne. Écrire des choses en notation mathématique ne rend pas les gens infaillibles. Un grand nombre de "preuves" mathématiques se sont révélées fausses (après de longues périodes de vérification très détaillée).
Steve314

1
@ Steve314: AFAIK, lorsque vous prouvez formellement l'exactitude d'un algorithme, vous spécifiez exactement et de manière concise quelle est l'exactitude attendue. Vous soulevez un bon point cependant, que la définition de « correcte » ne peut pas réellement être correct.
David Weiser

1
@ dss539, qui provient des cas d'utilisation que le programme est destiné à implémenter.

4

Je me retrouve à écrire du code pendant des heures, voire des jours sans exécuter le compilateur pour autre chose qu'une vérification de syntaxe occasionnelle.

Des heures à des jours - c'est un signe clair que vous manquez la possibilité de décomposer votre code en petits morceaux qui peuvent être vérifiés et testés par eux-mêmes. Vous devriez certainement y travailler.

J'ai tendance à écrire de gros morceaux de code avec soin et à ne tester à fond que lorsque je suis convaincu que le code fait ce qu'il est censé faire en analysant le flux dans ma tête.

Au lieu d'écrire des morceaux de code plus gros - et donc compliqués - qui nécessitent des heures à analyser dans votre tête, vous devriez essayer de créer des blocs de construction plus petits, pas si gros. C'est ce qu'on appelle la construction d' abstractions - et c'est l'essentiel d'une bonne programmation, certainement pas le signe d'être un débutant.

Une excellente programmation est comme un excellent jeu de Billard - un bon joueur ne joue pas les coups durs. Au lieu de cela, il joue d'une manière où, après chaque coup, les balles s'arrêtent dans une position où le coup suivant est à nouveau facile. Et un programmeur n'est pas bon parce qu'il peut écrire du code compliqué - il est bon parce qu'il peut éviter d' écrire du code compliqué.


3

Je compile et teste si l'une des conditions suivantes est remplie:

  • Dernière compilation il y a 15 minutes
  • La dernière compilation date de 25 lignes
  • Une nouvelle fonction / sous-routine a été implémentée
  • Changement majeur
  • Nouvelle fonctionnalité (ou un bug déguisé en fonctionnalité)
  • Correction d'un bug (suppression d'une "fonctionnalité")
  • Je m'ennuie

1

La fréquence d'exécution et de test du code dépend de la langue avec laquelle je travaille à ce moment-là. Si je code une procédure stockée, j'attends généralement que tout soit là.

D'un autre côté, si je code en Lisp, j'essaierai chaque fonction après l'avoir tapée.

Si je code en Haskell, je vais généralement faire une compilation après chaque fonction pour détecter les erreurs de type et exécuter le code une fois que tout est terminé.


1

J'écris juste assez de code pour faire passer le test au vert. Cela signifie que je lance le test toutes les quelques minutes. C'est mon style C ++. Cependant, dans Ruby, j'utilise l'autotest, donc chaque fois que je clique sur Enregistrer, je reçois des commentaires sur les tests via une jolie fenêtre contextuelle. Je n'arrête même pas d'écrire du code, ça se passe juste en arrière-plan.


1

Trois fois une heure, qu'elle en ait besoin ou non.

Nous faisons de la programmation avant tout et n'engage que du code de travail dans le VCS. Le smolderbot va vérifier le repo toutes les 20 minutes et exécute la suite de tests. Tout échec est immédiatement envoyé à toute l'équipe de programmation pour une correction immédiate.


1

Pour moi, ce n'est pas combien j'écris. Je peux écrire des milliers de lignes de code simple sans avoir à le tester. Mais lorsque j'écris du code plus difficile, j'ai tendance à tester chaque fonction individuellement après en avoir écrit un ensemble cohérent.

Parfois cependant, voir votre code en cours d'exécution est un énorme stimulant de motivation, lorsque vous n'avez rien exécuté depuis un moment, il est bon de le voir fonctionner.


0

Pour moi; -
Chronologie courte (pas beaucoup de temps pour réfléchir) - écrire du code, compiler, tester. debug
Suffisamment de temps - pendant que (terminé) {écrire un petit code, compiler}, tester, déboguer


Je trouve que le premier prend plus de temps que le second: vous avez plus à déboguer que si vous avez une très petite boucle de test / écriture.
Frank Shearar

Peut être. Mais un court délai signifie que le cul est en feu, et le gestionnaire a besoin d'un rapport qui indique qu'une tâche est à 100% effectuée.
Manoj R

0

Je teste pour chaque concept de codage. Parfois, c'est une fonction ou une classe et parfois ce n'est rien de plus qu'une instruction if. Une fois que le concept fonctionne, passez au suivant.


0

J'essaie d'écrire des tests avant le code. J'exécute mes tests au moins deux fois avant un commit. Il s'exécute ensuite à nouveau avec le serveur d'intégration continue.

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.