Indépendamment du fait que "ça marche" ou que "ça ne marche pas", il faut savoir se débrouiller pour que du "plus gros" continue à marcher... Tant qu'on est sur une demi-page de code, on arrive à se débrouiller, mais plus le programme grossi, et plus ça devient complexe.
Deux points me semblent important:
1) les outils de développements te donnent des "outils" pour vérifier. Sous Unity tu as la console. Elle t'indique ce qui ne va pas. Ce n'est pas toujours clair mais si elle t'indique "j'attends ; et je trouve = ligne 25" tu as déjà une bonne piste de recherche. Notons quand même que les éditeurs (je parle de l'outil dans lequel on programme) se plantent souvent sur la première erreur rencontrée et "imaginent" souvent d'autres erreurs qui ne sont que la conséquence de la première.
2) Les commentaires sont une bonne aide à la programmation. Ils doivent être nombreux. Durant mes années de gestion de projet orienté qualité logiciel, nous avions fait des statistique sur les commentaires. Nous étions arrivé à la conclusion qu'il fallait prés de 80% de commentaires pour qu'une équipe puisse reprendre le travail d'une autre équipe et immédiatement être opérationnel sur le code pour le continuer ou le débugger!
Les commentaires, c'est pas évident à écrire, mais ça aide. Deux exemples.
D'abord un mauvais
// Valeur pour le tir
canFire=true;
Un bon:
// Indique la possibilité de tirer:
// false= l'arme ne peut pas tirer, true=elle peut tirer
// Par défaut, l'arme peut tirer
canFire=false;
Dans le second exemple, on a une explication. Et on voit aussi immédiatement que quelque chose coince: si par défaut l'arme peut tirer, alors canFire devrait valoir true et pas false.
En conclusion:
1) coup d'oeil à la console
2) commentaires, commentaires, commentaires, commentaires
Amitiés
PL
