Discussion :

[Angelsafrania]

Tu veux dire comme c'est dit dans la news?
Je viens d’atterrir sur un projet en 20 ans d'age (MFC ) ou ceux qui savent où ont su ont disparu. 1,5 million de ligne de code sur 900 classes, avec une 15aine de tâches qui discutent entre elles.
évidement, très peu de doc existe et celle qui existe est souvent obsolète.

Bien maîtriser le débogage est essentiel, même si cela s'apparente finalement a du rétro engineering...

C'est bien ça.
La maîtrise du n'est pas là.
C'est pas forcement un tord, mais sur certain projet c'est inéducable.
Pour moi c'est de la responsabilité du chef de projet de faire que le projet soit maîtrisable, et donc quand il ne peut plus l'être faire une scission.
Et bien sûr avoir au moins plusieurs personne qui maîtrise le projet (le cas des départs), et d'en formé d'autre quand les gens partent. (tiens mais c'est pas mal la méthode agile pour ça).

[santana2006]

Impossible de développer sans déboguer.

[kisitomomotene]

Impossible de développer sans déboguer.

ça c'est clair et concis, rien à ajouter

[CodeurPlusPlus]

J'ai une stratégie "rouleau-compresseur" pour les gestions d'erreurs, stratégie que je n'applique pas toujours (cela dépend du type d'application).

Le moindre problème détecté entraîne :

1) l'affichage d'une sorte de warning précis ("appel de telle fonction, telle valeur devrait appartenir à tel ensemble, voici la valeur trouvée à la place : etc")

2) une tentative de correction de l'erreur (par exemple le programme choisit une valeur par défaut pour la variable fautive, affiche un message pour réciser quelle valeur a été choisie... le but n'est pas de deviner la valeur qu'il y aurait du avoir... mais d'en avoir une suffisamment crédible pour qu'il n'y ait pas de plantage immédiat).

3) le programme tente de continuer son exécution le plus normalement possible.

Depuis que je fonctionne de cette manière, le scénario suivant se produit assez souvent :

1) une anomalie apparaît quelque part, qu'elle provienne d'une erreur de conception, d'une erreur d'algorithmique, d'une erreur d'implémentation ou d'un problème avec les entrées/sorties ;
2) je vois apparaître un ou plusieurs warnings (souvent plusieurs car le premier en entraîne d'autres) ;
3) l'appli ne plante pas... elle continue de tourner avec cela dit quelques affichages aberrants ;
4) je continue à la tester pendant plusieurs minutes pour essayer de voir s'il n'y a pas d'autres choses qui ne vont pas que ce qui a été signalé ;
5) avant de fermer l'appli, je sauvegarde toutes les données (sauf celle dont je sais qu'elle est "corrompue") qu'il est utile de sauvegarder ;
6) je ferme l'appli, sauf bien sûr si un autre problème survenu après le premier arrive à la faire "planter", ce qui est assez rare finalement.

Rarement eu besoin de me battre contre mon ordinateur plus de quelques minutes, et jamais plus d'une ou deux heures, depuis que j'applique ce fonctionnement.

Il reste que ce n'est pas facile à faire : quand une anomalie est détectée sur une simple valeur numérique, en général c'est facile d'écrire du "code de gestion d'erreur" qui respecte les principes que j'ai exposés plus haut... quand l'erreur porte sur une donnée plus compliquée (un sprite par exemple), cela peut être moins évident, mais avec un peu d'entraînement on arrive à des trucs qui fonctionnent pas mal (dans un jeu que je suis en train de programmer, par exemple, j'ai souvent pu terminer une partie entière malgré des bugs graves de chez graves qui n'altèrent finalement presque que l'affichage... un vrai luxe de pouvoir continuer à tester un programme qui "a planté").

Je ne raise ni ne catch presque jamais d'exception... les exceptions permettent de faire ce que je fais mais en alourdissant considérablement l'écriture du code... (ne parlons même pas de ceux qui utilisent les exceptions comme des asserts améliorés)

Après, savoir si on peut réellement "enseigner" cela à des étudiants qui, par définition, en sont encore à apprendre les techniques de base...

[kisitomomotene]

Les bugs véritables ( dans mon expérience) se trouve au niveau de l'intégration de son code, avec les framework tierce ou avec le runtime sous-jacent.
par exemple, lorsque j'utilise JPA pour rendre persistent une entité e1 de type E1, contenant un champ e2 de type E2 ( E2 étant aussi une entité), je constate que dans la base de donné, le champ e2 n'a pas été mise à jour. Alors on se demande quelles annotations ont été mal utilisées? on relit toute la documentation de JPA, on ne voit pas se qu'on a omis! le temps presse, les utilisateurs sont bloqués car ils ne peuvent plus travailler, et le problème c'est que le bug implique des piles de framework dont on n'a pas totalement la maîtrise! bonjour le grand stress, on ne sait pas quand est ce qu'on va détecter ce qui fait problème, les utilisateurs mettent la pression, et la patron te rappelle que tu es entrain de lui faire perdre de l'argent...