Lorsque vous arrivez dans la matinée, vous constatez que votre logiciel ne fonctionne plus, alors qu’il l’avait quand vous êtes parti hier soir.

Que faire? Qu'est-ce que vous vérifiez en premier? Que faites-vous pour arrêter d'être en colère et commencer à travailler sur votre problème? Est-ce que vous blâmez vos collègues et allez directement à eux? Que peut-on faire pour éviter de se retrouver dans une telle situation?

Les suspects habituels sont:

• Vous pensiez que cela fonctionnait hier, mais après une journée complète de travail, vous étiez trop aveugle pour réaliser que cela ne fonctionnait pas.

• Ce matin, vous ne pouvez plus vous référer à ce qui était dans la mémoire cache de l'IDE hier.

• Le poste de travail a redémarré la nuit dernière ou une opération de maintenance nocturne dans les répertoires / tmp effacés.

• Quelque chose a changé dans la base de code: vérifiez si quelqu'un (éventuellement vous-même) a validé les changements entre votre dernière compilation d'hier et votre dernière compilation d'aujourd'hui.

• Quelque chose a changé dans les bibliothèques de support: vérifiez si ces bibliothèques ont été recompilées ou mises à niveau. La cause peut être à l'intérieur du projet pour des bibliothèques spécifiques ou à l'extérieur si une nouvelle version d'un package apparemment indépendant a été déployée.

• Quelque chose a changé dans l'environnement de test: nouvelle version d'une machine virtuelle, un stub qui a été modifié, des modifications dans un serveur de base de données distant ...

• Quelque chose a changé dans la chaîne de compilation: modifications dans les Makefiles, nouvelle version de IDE, du compilateur, des bibliothèques standard ...

1) Si cela ne fonctionne pas aujourd'hui, cela ne fonctionnait pas hier non plus.

Vous pensiez que cela fonctionnait, mais ce n'était pas le cas.

2) Il y a un problème et il faut le résoudre .

Ne pensez pas à qui est responsable de ceci ni à blâmer les autres.

Si rien n'a changé entre hier et aujourd'hui (comme je suppose que j'ai lu votre question), cela signifie que vous devriez mieux tester votre code avant d'affirmer qu'il fonctionne.

Pour éviter cette situation, vous devez effectuer les tests et le débogage appropriés .

Définissez "travail" et testez les limites de vos routines de code.

• Essayez de devenir l’un des utilisateurs qui utiliseront les fonctionnalités de votre programme ou de votre code.
• Poussez votre code dans les limites autorisées et au-delà, et vérifiez réellement s'il se casse.

Une façon de procéder consiste à exécuter un ensemble automatisé de tests approfondis pendant la nuit, de sorte que le lendemain, vous puissiez vérifier si quelque chose ne va pas et résoudre le problème.

Essayer de trouver quelqu'un qui blâme le coup n'est pas constructif et ne résout pas les problèmes. Ne le fais pas.

Si quelque chose a fonctionné hier et ne fonctionne pas maintenant, alors soit vous avez un comportement non déterministe (comme une situation de compétition) et le faire fonctionner hier n'était que de la chance, ou quelque chose a changé entre maintenant et maintenant, et vous avez besoin de savoir ce qu'il en est. est.

Comment savoir exactement où se trouve le cas et comment le réparer peut dépendre des particularités de la situation, mais il est toujours utile d’être méthodique pour éliminer les causes, c’est-à-dire ne changez pas 5 choses à la fois et arrêtez de chercher si cela peut vous aider - Découvrez quelle est la cause spécifique du problème et, éventuellement, comment y remédier, afin que vous puissiez le rechercher lorsqu'il se reproduira dans 3 semaines.

L'utilisation des outils de diagnostic appropriés (débogueur, profileur, outils d'analyse de réseau) peut également faire toute la différence.

J'ai travaillé avec du code qui semblait changer du jour au lendemain et après un certain temps, j'en suis venu à la conclusion que cela était dû à des lutins malveillants qui rampaient dans ma base de code la nuit et changeaient les choses de telle manière que malgré le fait que cela fonctionnait hier, maintenant ne fonctionne pas du tout. En effet, dans le style classique de Schroedinbug , non seulement cela ne fonctionne pas maintenant, mais il est également clair qu’il n’y aurait aucun moyen de le faire.

Au fil du temps, j'ai réalisé qu'il était tout à fait possible qu'en réalité les lutins n'aient rien à voir avec cela et que peut-être mon "temps de rentrer à la maison, ça suffira", la dernière version ne reçoit pas les tests détaillés et l'attention qu'elle mérite peut-être .

Ma première hypothèse quand je rencontre ceci le matin est que c'est probablement de ma faute, car c'est généralement moi qui suis responsable de mes propres fonctionnalités ou de certains coins de logiciels sur lesquels je travaille. Ma deuxième hypothèse est que je pourrais aussi bien avoir ce café maintenant. Si ce n'est pas une évidence flagrante qu'un singe puisse comprendre (ce qui est parfois le cas), alors il y a de bonnes chances que j'ai réussi à faire glisser une ancienne version d'une bibliothèque, annulant par erreur un fichier qu'il n'était pas nécessaire de restaurer. retour ou avoir quelque chose en cache quelque part qui l'a introduit dans la construction sans le vérifier. En parcourant ma récente activité de contrôle de code source a tendance à révéler ce que j'ai fait, le nettoyage de la version supprime souvent les versions en cache errantes.

Parfois, cela n'a vraiment rien à voir avec moi - quelqu'un a mis à jour une dépendance sans le mentionner, WindowsUpdate a installé quelque chose qui a changé l'environnement pour que mon code ne fonctionne pas; Il y a beaucoup de possibilités en arrière-plan, mais il s'agit généralement de gérer et d'accepter le fait que, comme la plupart des gens, je suis fondamentalement un idiot.

Utilisez le contrôle de version. Faites un diff ou utilisez la fonctionnalité de blâme de votre VCS .:

• diff: Chaque VCS. Vous montre les différences entre, euh, différentes versions
• blame: par exemple git. Vous montre ligne par ligne qui a changé quoi

S'il n'y a pas de contrôle de version, mis à part qu'il s'agisse de votre faute ou de celle de votre patron, vous pouvez consulter les dates de modification des fichiers et éventuellement consulter les fonctions de journalisation de votre système d'exploitation.

En dehors de cela: Recompilez tout, assurez-vous de recompiler également les bibliothèques auxiliaires.

Bien sûr: si vous avez trouvé la source d'erreur, restez calme, demandez pourquoi un changement a été apporté, expliquez votre problème et proposez une solution qui vous rende tous les deux heureux. Ne lui criez pas dessus, ce serait un poison pour votre productivité.

S'il n'y a aucun changement, il est temps de voir ce qui a changé sur le système. Par exemple, récemment, les ordinateurs Mac OS ont mis à jour une nouvelle version d’Apache qui a rendu certaines configurations non valides.

Eh bien, voici un exemple concret de code qui "a fonctionné hier" et non pas aujourd'hui ... Il date du début de ce mois.

L'application en question extrait les informations d'une base de données par date et le comportement par défaut consiste à obtenir des données pour le jour actuel. Cela a bien fonctionné le 8 août mais a échoué le 9. Il n'a pas été testé auparavant. Cela aurait également fonctionné le 9 septembre et le 10 octobre ...

Un autre indice est que nous sommes au Royaume-Uni, la base de données en question était aux États-Unis ...

Donc, ma réponse à votre question sur ce qu'il faut vérifier en premier lieu est de vérifier comment vous formatez vos dates, car si vous mélangez les champs du jour et du mois, cela fonctionnera parfaitement, mais seulement 1 jour par mois :-)

Corrigez le bogue (comme vous le faites normalement). Ensuite, si vous trouvez qui en est la cause, envoyez-leur un courrier électronique poli leur indiquant ce qui ne va pas.

Chaque codeur fait des erreurs et si vous commencez à blâmer, il se retournera sérieusement la prochaine fois. (peut-être même ce bug était le vôtre)

Ce n'est que si vous les suspectez d'être négligents régulièrement si vous faites une grosse affaire avec quelques insectes.

... vous effectuez des tests de régression et vous concentrez sur ceux qui échouent.

En fait, c’est ce que vous avez oublié de faire hier avant de partir.

Vous n'en avez pas? Ok .. qu'est-ce que tu dis? Blâmer ? Eh bien ... ça pourrait marcher, alors

La première chose à faire quand quelque chose cesse de fonctionner est de vous demander - Qu'est-ce qui est différent? Qu'est ce qui a changé?

Quand quelque chose a fonctionné la nuit dernière mais a échoué ce matin, la seule chose qui a évidemment changé est - la date et l'heure :)

J'essayerais de penser que la logique sur laquelle je travaille est liée à des dates et pourrait être affectée par le temps qui passe. C'est surprenant combien de fois c'est la cause de tels problèmes.

Si cela échoue, vous devez absolument suivre le bon conseil fourni ici.

Une réponse un peu courte (pour écrire) mais un peu longue pour en comprendre l'essentiel: Pourquoi les programmes échouent: Un guide pour le débogage systématique par Andreas Zeller (qui peut paraître un peu trop académique mais ce n'est pas le cas)

Vous consultez dans votre boîte aux lettres le courrier envoyé par le moteur d'intégration continue lorsque le ou les tests unitaires ont échoué (ou la page du journal si vous n'avez pas observé ce problème spécifique), et vous voyez qui a effectué l'enregistrement juste avant cette génération. .

Puis va lui parler.

Il n'y a que deux raisons possibles pour lesquelles votre code échoue aujourd'hui, mais a fonctionné hier.

Regardez les données

Il y a quelque chose dans les données que vous n'avez pas testées et / ou prises en compte. Soit les données ne sont pas validées correctement, soit une erreur de logique n’a été révélée qu’une condition logique inattendue se produit. Cela signifie que le bogue était là hier, mais il se cachait sous des données valides.

Une fois, un code d’entrée de commande a fonctionné pendant des semaines. Je suis rentré chez moi un jour et il est mort. L'enquête du lendemain a révélé que j'avais un bogue caché dans une chaîne d'appels de fonctions. Dans un langage faiblement typé, j'ai déclaré un entier alors que j'aurais dû utiliser un long int. La langue faisait automatiquement la conversion entre les deux jusqu'à ce qu'elle ne puisse pas, car le nombre dépassait ce qui serait contenu dans un entier. Le système a échoué sur le numéro de commande 32768.

Regardez ce qui a changé

Regardez ce qui a changé depuis que cela a fonctionné. La section informatique a-t-elle publié une mise à jour du système d'exploitation? Un autre codeur a-t-il modifié le code utilisé par votre programme? La permission de l'utilisateur a-t-elle changé? Souvent, si vous trouvez ce qui a changé, vous trouvez le bogue.

Hachage binaire

fonctionne particulièrement bien pour les erreurs JavaScript difficiles. En gros, commentez la moitié du code, voyez si vous obtenez l’erreur, c’est dans cette moitié du code. La moitié encore et continuer.

Si votre code est bien encapsulé, il s'agit d'un outil fantastique permettant de gagner du temps et de réduire le stress.

Une fois que vous avez trouvé le code de culpabilité, il vaut souvent la peine d'isoler l'erreur sur sa propre page de test.

Et bien sûr, que peut-on faire pour éviter de se retrouver dans une telle situation?

Pour répondre à cette question, vous voudrez peut-être vous pencher sur l’ intégration continue (CI) . Autrement dit: CI est un processus au cours duquel les développeurs intègrent et testent fréquemment tout le code (jusqu'à plusieurs fois par jour). L'idée est que les modifications apportées à un module qui en cassent un autre sont rapidement trouvées.

En pratique, la plupart des équipes qui emploient CI utilisent un serveur CI (voir: liste de Wikipedia ). Le serveur CI est généralement configuré pour surveiller le référentiel SCM et pour démarrer une construction lorsqu'il voit les modifications. Une fois la construction terminée, il exécutera une série de tests automatisés et affichera les résultats par courrier électronique et / ou sur la page Web de la construction et des tests, ainsi que les modifications qui ont provoqué la construction. Espérons que, lorsque quelque chose brise la construction ou les tests, vous n’avez qu’un très petit changement à examiner, ce qui permet de le résoudre plus rapidement.

Il y a d'autres questions ici sur le serveur CI à utiliser, je vous laisse donc les trouver. Personnellement, je suis un grand fan de Jenkins.

[Que dois-je faire à propos des choses cassées.]

Comme d'autres l'ont déjà dit, trouvez ce qui a éclaté et essayez de le réparer. Passer du temps à essayer de blâmer c'est du temps passé à ne pas résoudre le problème.

Ma réaction naturelle est toujours de blâmer les autres, mais au fil du temps, j'ai fini par me rendre compte que c'est généralement moi qui suis en faute. En plus de tous les excellents commentaires ci-dessus, il est important que vous enregistriez vous-même quelle était la raison finale. Peu importe que vous utilisiez un wiki partagé avec d'autres membres de l'équipe, un Twiki privé, Evernote, un journal de bord ou une bonne mémoire. L'important, au moment où vous trouvez la réponse (et souhaitez retourner au travail!), Est d'enregistrer la raison.

Vraisemblablement, si cela ne fonctionne plus, vous avez identifié les symptômes. Il se bloque ou renvoie une boîte de dialogue d'erreur particulière à l'utilisateur.

Si la seule description du problème est "ça ne marche pas", la première chose à faire est de rassembler plus d'informations sur les symptômes du problème.

Ensuite, vous commencez à rechercher les causes possibles, via des journaux ou une tentative de reconstitution du problème ou une combinaison des deux - dépend de la configuration de votre système, je suppose.

Ensuite, vous commencez à les exclure.

C'est ce qui se passe généralement quand je prends des vacances :-)

Plus sérieusement, je leur dirais d'abord:

• Je vais regarder pour voir ce qui ne va pas et ce qui pourrait être la racine

• Je toucherai la base dans 30 à 60 minutes une fois que j’aurai eu la chance de voir ce qui se passe.

Après cette période, je peux vous donner une estimation de ce qui aurait pu se passer et du temps qu’il faudra pour régler le problème si ce n’est pas déjà fait et, le cas échéant, quelles données nous avons peut-être perdues (mais j’ai de bonnes sauvegardes, ce qui n’arrive jamais j'espère).

En ce qui concerne la partie blâmante:

• s'il ne s'agit que d'une faute de frappe de collègue, inutile de le mentionner: il y a de la merde et la peur du bogue lui a probablement appris une leçon et, espérons-le, il ne le fera plus.

• s'il a intentionnellement fait quelque chose que je ne lui ai pas dit (par exemple, donner le nouveau mot de passe du serveur de production au nouveau gars et lui dire de le modifier directement sans surveillance) (oui, c'est déjà arrivé ...), alors je dois le mentionner.

Si vos méthodes de traçage de bogues habituelles ne fonctionnent pas et que tout fonctionne comme un gâchis total, il peut être merveilleux de disposer d’une sauvegarde que vous pourrez restaurer facilement.

C'est ce que je lance localement, automatiquement toutes les heures de 8h à 18h:

rdiff-backup /path/to/mystuff /path/to/mybackup

Simple, hein?

Si vous devez restaurer quelque chose, utilisez

rdiff-backup -r 24h /path/to/mybackup/specific/dir /tmp/restored

rdiff-backup ne stocke que les fichiers qui diffèrent. Vous pouvez utiliser rdiff-backup sur Linux, Mac et Win.

Bien sûr, cela ne devrait pas être votre seule sauvegarde. Mais c’est un moyen extrêmement facile et peu coûteux d’avoir une sauvegarde locale.

Maintenant, je ne recommanderais pas cela comme méthode de résolution de bogues normale, mais si tout le reste échoue, c'est une solution de secours.

Le bogue a peut-être déjà existé, mais il a été masqué par des facteurs externes ou par des problèmes système graves.

Cela m'est arrivé Un bug développé entre 2 builds de notre projet. Littéralement, le seul changement que nous avions fait était de passer à une version plus récente de l'une des bibliothèques sous-jacentes.

Naturellement nous les avons blâmés. Mais le seul changement qu’ils avaient fait était de refactoriser certains en-têtes pour une compilation plus rapide. J'ai convenu que cela n'aurait pas dû casser le système.

Après beaucoup de débogage, il s’est avéré que le problème était un bogue de pointeur non autorisé qui était caché dans mon code pendant des années . D'une manière ou d'une autre, cela n'a été déclenché que lorsque leur refactorisation a changé la disposition de l'exécutable.

cela fonctionnait hier car il était utilisé correctement.

vous constatez que d’autres personnes utilisent les choses d’une manière qui n’est pas supposée être un bon moyen de casser des choses.

Il est toujours bon de mettre à jour le code tôt dans la journée car cela vous laisse avec un bon environnement de test.

Sauvegarde!

Je trouve très utile de définir des points d'arrêt pour mettre en pause et vérifier mes données, afin de déterminer exactement où et comment les choses se passent mal.