Re: Pendant ce temps

ça peut quand même sauver les meubles ;).

En fait ça dépend vraiment de ce que tu cherches: un logiciel sans bug, ou un logiciel qui a "l'air" de fonctionner (mais en fait est tout cassé).

Quand on dit "cas impossible" ici, cela veut bien entendu dire "théoriquement" et non pas dans les faits, clairement (puisqu'il est arrivé cette première fois). Donc le "dans la tronche le cas impossible" ne prouve donc absolument rien, sinon le fait que tes collègues ont possiblement raison et qu'il y a un autre bout de code créant ce cas "impossible".
La réponse à cela doit donc être de corriger ce code qui a généré cet état impossible, afin qu'il représente cette théorie. Le problème de la correction a posteriori (c'est à dire quand il est déjà arrivé) du cas impossible, c'est qu'on ne fait que cacher le problème, un peu l'équivalent de mettre la poussière sous le tapis.

Deux jours plus tard, bim! dans la tronche le cas impossible :D. Je m'en suis un peu voulu de m'être laissé convaincre.

Alors je connais pas ton cas particulier. Peut-être est-ce un autre cas, et qu'en fait ce n'était simplement pas réellement un cas qui devait être impossible dans la théorie. Ce qui n'est alors pas ce dont on parle ici.

Mais si on suppose que ça l'était, alors je suis désolé, mais tes collègues avaient raison et le fait que ça se reproduise 2 jours plus tard... ne fait que leur donner encore plus raison! 😛 La dernière chose que tu voudrais vouloir est de cacher cet état impossible des choses. Si ça se produit vraiment régulièrement, tu veux comprendre pourquoi et c'est ça que tu veux corriger. Et tu veux laisser les conséquences de ce problème bien visibles jusqu'au moment où tu as corrigé cela, comme un marqueur du problème (par exemple, si le problème est très complexe et tu n'es pas certain de ta correction, tu vérifies si d'autres gens continuent de rapporter le problème; si à un moment donné, plus personne ne le rapporte, tu peux supposer que la correction est bonne).

Je dis pas qu'il faut aller vers du if(1==1) avant chaque instruction, mais vérifier les entrées quand ça vient d'un truc un peu lointain/compliqué, ça peut quand même sauver les meubles ;).

C'est justement pour cela que les assert() ont été créés. Tu vérifies l'état de ton processus (le contenu des variables, l'état d'un objet, etc.) tel qu'il est censé être au début d'une fonction (ou parfois même au milieu, après être passé par certains traitements).

Alors assert, c'est un peu violent, tu vas me dire. Et tu aurais raison. Néanmoins les processus de développement ont évolué depuis qu'on en fait! Dans GIMP, nous avons des fonctions du même genre qui ne plantent pas immédiatement le processus. À la place, ça va générer des WARNINGs ou CRITICALs, et parfois aussi retourner immédiatement de certaines fonctions (surtout quand on sait que sinon, on planterait, genre parce qu'on ferait une division par zéro, ou qu'on va déréférencer un pointeur NULL, etc.). Donc le processus est toujours dans un état instable, mais on se donne une chance de retrouver un état stable, probablement avec un truc qui va mal (ou pas) se passer, mais avec un peu de chance, quelque chose de pas trop grave.

Par contre, la grosse différence, c'est qu'on aura eu notre CRITICAL. Et c'est là où on va pouvoir se mettre à débugguer. Ce CRITICAL va bien sûr se logguer dans le terminal, mais surtout j'ai implémenté une fenêtre de Debug qui s'ouvre automatiquement en popup et produit une backtrace du code qui a produit ce CRITICAL. Et cette fenêtre suggère aux gens de soumettre un rapport de bug avec ces informations. Ce qui en retour nous permet de trouver l'origine du CRITICAL puis de dialoguer avec la personne ("Vous rappelez-vous ce que vous faisiez?") pour essayer de trouver l'origine du bug (note que parfois, la trace se suffit à elle-même, bien sûr! Mais je parle du cas dont il est question où la trace serait plutôt un symptôme que la cause du problème).

Avant que j'arrive chez GIMP, on avait pas cette fenêtre de Debug donc on n'obtenait jamais des rapports pour ces bugs un peu "cachés" (car les gens ne regardent pas le terminal pour un logiciel graphique en général!), on avait rarement des traces de debug (sauf quand le rapporteur était aussi développeur) et notre indice principal était les procédures de reproduction (ce qui reste très important, mais maintenant, c'est pas notre seul indice et dans beaucoup de cas, on arrive même à faire sans).

Le développement a évolué, et de nos jours, il existe donc des moyens d'éviter des plantages intempestifs sans pour autant cacher les problèmes. Alors as-tu vraiment sauvé les meubles si tu t'es contenté d'un if qui a silencieusement corrigé une variable fausse (ou quelque chose du genre)? Rien n'est moins sûr (et encore une fois, je connais pas ton cas précis).

Je sais qu'on a régulièrement des cas comme cela dans GIMP où certains développeurs plus junior vont faire des corrections de conséquences; mais cela reste des développeurs de confiance à qui j'ai donné les clés (ils font du bon travail globalement, même si parfois aussi quelques erreurs). Et à cause de cela, le même bug se reproduit, mais ailleurs. Et ils refont globalement la même "correction" dans cet "ailleurs". Plusieurs fois.

Puis j'arrive à un moment, je regarde le problème, et corrige la vraie source du bug (qui peut être dans un endroit totalement différent du code). Puis on retire tous les "sparadraps" du reste du code qui n'avaient été rien d'autre que des cache-misères tentant de maladroitement cacher un vrai bug ailleurs.

Au final, on peut considérer donc que cacher ce cas impossible ne fait que créer plus de travail. Notamment car il devient alors plus compliqué de diagnostiquer un problème. Le pire cas est même quand on arrive à vraiment bien cacher le problème en fait, si bien qu'il ne ressort plus de manière évidente ailleurs, mais à la place apparaît alors comme un problème dorénavant bien plus subtil dans un processus qui a l'air de fonctionner mais qui produit un résultat légèrement erroné. Et personne ne comprend pourquoi. Mais qu'est-ce qui se passe? Bah voilà! C'était le développeur débutant qui a caché un méchant bug l'autre jour (et d'après lui, il a bien fait! Ben oui, avant le processus plantait complètement; et maintenant non; c'est mieux, non?), sauf que maintenant à la place, on a un résultat faux, mais suffisamment subtilement pour que beaucoup ne s'en rendent pas compte (donc on le découvrira des mois après) et que quand on le voit enfin, on va chercher des jours et des jours pour le problème.

Alors as-tu vraiment sauvé les meubles? La question reste ouverte! 😜

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]