Rétrospective du TP2 : bien, mais j'en veux plus.

[guyfrancoeur]

Bonjour,

Rétrospective sur la correction.

Pour ceux qui voulaient une rétrospective sur leur tp. Prendre uniquement ce qui s'applique à vous.

Globalement:

• Code :
  • Beaucoup de code. Un peu garroché.
  • Pas toujours simple.
  • Il semble y avoir trop de fonctions (héritage de vos cours Java ?)
  • Les variables vous devez penser, réfléchir plus, en C on fait rien pour rien!
  • Vous devez utiliser toutes les notions C vues: struct, typedef, TAD, pointeurs, modules, SYMBOLES.
  • Ne pas utiliser les variables en dehors des fonctions (variable globale). Variable locale uniquement.
  • Les arguments de fonctions et les passages par valeurs ou par références est-ce compris ?
  • Vous codez beaucoup, mais ça ne marche pas ou c'est incomplet. Construction sur du mou, pourquoi ?
• Organisation du travail :
  • Il est ou votre dessin (votre image des composantes à réaliser) est-ce clair pour vous globalement ?
  • Il faut avoir une meilleure vue d'ensemble. Ça ne sert à rien de vous casser la tête.
  • Ne pas d'écrire comment exécuter le programme dans le README.md. Vous devez réaliser cela dans le Makefile.
• Résultats :
  • J'ai donné beaucoup de bonus. Correction sur /22+.
  • Les résultats des exécutions ne sont pas satisfaisants. 🙄
• Automatisation :
  • Les Makefile ne sont pas assez simples, et les dépendances doivent être utilisées.
  • Les commandes wget et unzip ont des options, utilisez-les !
  • La marche à suivre contenu dans votre README.md, faites-la dans le Makefile :
    • cible : dépendance
    • TAB commandes.
  • Regrouper vos commandes rm dans la cible clean.
• Tests :
  • Les tests par type de transactions ou sont-ils ?
  • Vous n'avez pas fait de test fonctionnel ou trop peu ! Pourquoi ?
  • Vous devez absolument revoir le traitement de chacune des transactions INDIVIDUELLEMENT.

Finalement : Coder sans plan et sans tests ça ne sert à rien. Un peu comme sauter en parachute sans le sac dans le dos ... 🙄

À faire (itérativement) : (une chose simple, pas 3 ou 4) UNE :

• 1. Dessin simple
• 2. Préparation des requis de tests
     • 1. faire des fichiers d'entrés
     • 2. faire des fichiers de sortie attendus
• 3. Coder certains tests unitaires
• 4. Coder le cas d'utilisation connu défini en 1.
• 5. Valider et automatiser la vérification (avec Makefile ou yaml) défini en 2.
• 6. Répéter
• 7. À chacune des itérations on simplifie.

On vise un 20 sur 20 pour le TP3. Les demandes du tp3 sont en fait les manques du tp2. Attention aux dépendances circulaires de vos #include.

Il sera possible d'avoir des avis, des rétroactions lors des séances en classe et de laboratoire, plus de détail sera donné en classe comment.

Je vais revenir sur les points contenus dans ce post, ça va bien, mais nous devons continuer, on ne lâche pas vous êtes capables.

Réagissez (icons) à ce post

[Patrickcob]

Pour les tests fonctionnels, quelqu'un avait posé la question et idéalement, il ne fallait pas mettre les tests dans le repo, ceci dit, pour le tp3, si ce n'est pas un problème, pour ma part, je ferai un dossier test.

[guyfrancoeur]

Bonjour,

Vous n'êtes pas obligé, mais si vous en avez il est surement plus judicieux de les sauvegarder. Je vous fait confiance.

G