"Ça fonctionnait hier, je le jure!" Que pouvez-vous faire?
Lorsque vous arrivez le matin, vous constatez que votre logiciel ne fonctionne plus, même s'il l'a fait lors de votre départ hier soir.
Que faire? Que vérifiez-vous en premier? Que faites-vous pour arrêter d'être en colère et commencer à travailler sur votre problème? Blâmez-vous vos collègues et allez-vous directement vers eux? Que peut-on faire pour éviter d'être 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 IDE hier).
La station de travail a redémarré la nuit dernière ou une opération de maintenance nocturne a effacé les répertoires/tmp.
Quelque chose a changé dans la base de code: vérifiez si quelqu'un (éventuellement vous-même) a validé des modifications 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 changements dans un serveur de base de données distant ...
Quelque chose a changé dans la chaîne de compilation: changements dans les Makefiles, nouvelle version de l'IDE, du compilateur, des bibliothèques standard ...
1) Si ça ne marche pas aujourd'hui, ça ne marchait pas non plus hier.
Vous pensiez que cela fonctionnait, mais ce n'était pas le cas.
2) Il y a un problème, et il doit être résol.
Ne pensez pas à qui est responsable de cela ou à blâmer les autres.
Si rien n'a changé entre hier et aujourd'hui (comme je suppose que vous lisez votre question), cela signifie que vous devriez faire un meilleur travail pour tester votre code avant de déclarer ça marche.
Pour éviter cette situation, vous devez faire correctement Testing et Debugging.
Définissez "travailler" et testez les limites de vos routines de code.
- Essayez de devenir l'un des utilisateurs qui utilisera vos fonctionnalités de programme ou de code.
- Poussez votre code dans les limites autorisées et au-delà, et vérifiez s'il se casse.
Une façon de procéder consiste à exécuter un ensemble automatisé de tests approfondis pendant la nuit, afin que le lendemain, vous puissiez vérifier si quelque chose s'est mal passé et résoudre les problèmes.
Essayer de trouver quelqu'un pour rejeter la faute 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 condition raciale) et le faire fonctionner hier était juste de la chance, soit quelque chose a changé entre alors et maintenant, et vous devez savoir ce qu'il est.
La façon exacte de savoir quel est le cas et comment il peut être résolu dépend des spécificités de la situation, mais cela aide toujours à être méthodique pour éliminer les causes, c'est-à-dire ne changez pas 5 choses à la fois et arrêtez de chercher si cela aide - Découvrez quelle chose spécifique a causé le problème, et écrivez peut-être comment le résoudre 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 une grande différence.
J'ai travaillé avec du code qui semblait changer du jour au lendemain et après un certain temps, je suis arrivé à la conclusion que cela était dû à des pixies malveillants qui rampaient dans mon code la nuit et changeaient les choses de telle manière que, malgré le fait qu'il fonctionnait hier, il le fasse maintenant ne fonctionne pas du tout. En effet, dans le style classique Schroedinbug , non seulement cela ne fonctionne pas maintenant, mais il est clair que il n'y a aucun moyen qu'il puisse jamais avoir.
Au fil du temps, je me suis rendu compte qu'il est tout simplement possible qu'en fait les lutins n'aient rien à voir avec cela et que mon "temps de rentrer à la maison, ce sera assez bien" ne reçoive pas les tests détaillés et l'attention qu'il mérite peut-être .
Ma première hypothèse lorsque je rencontre cela le matin est que c'est probablement ma faute car je suis généralement responsable de mes propres fonctionnalités ou coins de logiciels sur lesquels je travaille. Ma deuxième hypothèse est que je pourrais aussi bien obtenir ce café maintenant. Si ce n'est pas quelque chose de tout à fait évident qu'un singe pourrait comprendre (ce qui est parfois le cas), alors les chances sont bonnes que j'ai réussi à faire glisser dans une ancienne version d'une bibliothèque, par erreur restauré un fichier qui n'avait pas besoin d'être roulé ou avoir quelque chose en cache quelque part qui l'a introduit dans la build sans le vérifier. En parcourant ma récente activité de contrôle de source a tendance à révéler des choses que j'ai faites, le nettoyage de la build 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 afin que mon code ne fonctionne pas; il y a beaucoup de possibilités de fond, mais il s'agit généralement de gérer et d'accepter que, comme la plupart des gens, je suis essentiellement un idiot.
Utilisez le contrôle de version. Faites une différence ou utilisez la fonctionnalité de blâme de votre VCS .:
diff: chaque VCS. Vous montre les différences de, euh, différentes versionsblame: par exemple git. Vous montre ligne par ligne qui a changé quoi
S'il n'y a pas de contrôle de version, en dehors de votre faute ou de celle de votre patron, vous pouvez consulter les dates de modification des fichiers et éventuellement consulter les fonctionnalités de journalisation de votre système d'exploitation.
En dehors de cela: recompilez tout, assurez-vous également de recompiler les bibliothèques auxiliaires.
Bien sûr: si vous avez trouvé la source de l'erreur, restez calme, demandez pourquoi un changement a été fait, expliquez votre problème et proposez une solution qui vous rendra heureux tous les deux. 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 sont passés à une nouvelle version d'Apache qui a rendu certaines configurations invalides.
Eh bien, voici un exemple réel de code qui "a fonctionné hier" et 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 la journée en cours. Cela a bien fonctionné le 8 août, mais a échoué le 9. Il n'a pas été testé plus tôt que cela. Il 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 USA ...
Donc, ma réponse à votre question sur ce qu'il faut vérifier en premier est de vérifier la façon dont vous formatez vos dates, car si vous mélangez les champs jour et mois, cela fonctionnera parfaitement, mais seulement 1 jour par mois :-)
La première chose à faire lorsque 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é hier soir mais échoue ce matin, la seule chose qui a évidemment changé est - la date et l'heure :)
J'essaierais de penser s'il y a une partie de la logique sur laquelle je travaille qui dépend des dates et pourrait être affectée par le temps qui passe. Il est surprenant de voir combien de fois cela est à l'origine de tels problèmes.
Si cela échoue, vous devriez certainement suivre les autres bons conseils fournis ici.
Correction du bug (comme vous le faites normalement). Ensuite, si vous trouvez la cause, envoyez-leur un e-mail poli pour leur faire savoir ce qui ne va pas.
Chaque codeur fait des erreurs et si vous commencez à blâmer, cela se retournera sérieusement la prochaine fois que vous ferez la même chose. (peut-être même que ce bug était le vôtre)
Ce n'est que si vous les soupçonnez d'être insouciant de façon régulière que vous devriez faire une grosse affaire avec quelques bugs.
... vous exécutez tests de régression et vous concentrez sur ceux qui échouent.
En fait c'est ce que tu as oublié de faire hier avant de partir, ça arrive.
Vous n'en avez pas? Ok .. où tu dis? Blâme ? Eh bien ... cela pourrait fonctionner, alors
Une réponse un peu courte (pour écrire) mais un peu longue pour en avoir l'essentiel: Pourquoi les programmes échouent: Un guide du débogage systématique par Andreas Zeller (qui peut sembler un peu trop académique mais ce n'est pas le cas)
Vous regardez 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 de journal si vous n'avez pas observé ce problème spécifique), et voyez qui a effectué l'enregistrement juste avant cette génération .
Allez ensuite 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 dont vous n'avez pas tenu compte. Soit les données ne sont pas validées correctement, soit une erreur de logique n'a pas été révélée jusqu'à ce qu'une condition logique que vous n'attendiez pas se produise. Cela signifie que le bogue était là hier, mais il se cachait sous des données valides.
Une fois, j'ai eu un code d'entrée de commande qui fonctionnait bien 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 bug caché dans une chaîne d'appels de fonction. Dans un langage faiblement typé, j'ai déclaré un entier alors que j'aurais dû utiliser un entier long. La langue a fait la conversion entre les deux automatiquement jusqu'à ce qu'elle ne puisse pas, car le nombre dépassait ce qui pouvait tenir 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 lancé une mise à jour du système d'exploitation? Un autre codeur a-t-il modifié le code utilisé par votre programme? L'autorisation de l'utilisateur a-t-elle changé? Souvent, si vous trouvez ce qui a changé, vous trouverez le bogue.
Côtelette binaire
fonctionne particulièrement bien pour les erreurs JavaScript difficiles. Fondamentalement, commentez la moitié du code, voyez si vous obtenez l'erreur, si vous le faites, c'est dans cette moitié du code. La moitié encore et continuez.
Si votre code est bien encapsulé, il s'agit d'un fantastique outil permettant d'économiser du temps et de réduire le stress.
Une fois que vous avez trouvé le code coupable, il est souvent utile d'isoler l'erreur sur sa propre page de test.
Et bien sûr, que peut-on faire pour éviter d'être dans une telle situation?
Pour répondre à cette question, vous voudrez peut-être examiner Intégration continue (CI) . Autrement dit: CI est un processus où les développeurs intègrent fréquemment (autant que plusieurs fois par jour) et testent tout le code. L'idée est que les modifications d'un module qui cassent un autre module sont rapidement trouvées.
En pratique, la plupart des équipes qui utilisent 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 démarrer une génération lorsqu'il voit des modifications. Une fois la génération terminée, il exécutera une série de tests automatisés et publiera les résultats par e-mail et/ou page Web de la génération et des tests, ainsi que les modifications qui ont provoqué la génération. Avec un peu de chance, quand quelque chose casse la construction ou les tests, vous n'avez qu'une toute petite modification à examiner, donc cela se résout plus rapidement.
Il y a d'autres questions ici sur le serveur CI à utiliser, donc je vous laisse les trouver intéressés. Personnellement, je suis un grand fan de Jenkins.
[Que dois-je faire pour que les choses soient brisées.]
Comme d'autres l'ont déjà dit, découvrez ce qui s'est cassé et essayez de le réparer. Passer du temps à essayer de blâmer est le 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, je me suis rendu compte que c'est généralement moi qui est en faute. En plus de tous les excellents commentaires ci-dessus, il est important que vous notiez par 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 que vous souhaitez retourner au travail!) Est d'enregistrer la raison.
Si vos méthodes habituelles de suivi des bogues ne fonctionnent pas et que tout est un gâchis total, il peut être merveilleux d'avoir une sauvegarde que vous pouvez restaurer facilement.
C'est ce que je lance localement, automatiquement toutes les heures de 8h à 18h:
rdiff-backup /path/to/mystuff /path/to/mybackup
C'est simple, hein?
Si vous devez restaurer quelque chose, utilisez
rdiff-backup -r 24h /path/to/mybackup/specific/dir /tmp/restored
rdiff-backup stocke uniquement 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 simple et bon marché d'avoir une sauvegarde locale.
Maintenant, je ne recommanderais pas cela comme une méthode normale de correction de bugs, mais si tout le reste échoue, c'est un repli.
Le bogue a peut-être déjà existé, mais il a été masqué par des facteurs externes ou des problèmes système profonds.
Cela m'est arrivé. Un bug s'est développé entre 2 builds de notre projet. Littéralement, le seul changement que nous avions fait était de mettre à jour vers une version plus récente de celle des bibliothèques sous-jacentes.
Naturellement, nous les avons blâmés. Mais le seul changement ils avait été de refactoriser certains en-têtes pour une compilation plus rapide. J'ai convenu que cela n'aurait pas dû briser le système.
Après de nombreux débogages, il s'est avéré que le problème était un bug de pointeur escroc qui était latent depuis mon code pendant ans . D'une manière ou d'une autre, il n'a jamais été déclenché jusqu'à ce que leur refactoring ait changé la disposition de l'exécutable.
Vraisemblablement, si cela ne fonctionne plus, vous en avez identifié les symptômes, c'est-à-dire qu'il se bloque ou renvoie une boîte de dialogue d'erreur particulière à l'utilisateur.
Si la seule description du problème est "cela ne fonctionne pas", la première chose que vous devez faire est de rassembler plus d'informations sur les symptômes du problème.
Ensuite, vous commencez à rechercher des causes possibles, soit via des journaux, soit une tentative de recréation du problème ou une combinaison des deux - cela dépend de la configuration de votre système, je suppose.
Ensuite, vous commencez à les exclure.
C'est ce qui arrive généralement quand je prends des vacances :-)
Plus sérieusement, je leur dirais d'abord:
je vais l'examiner pour voir ce qui ne va pas et quelle 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 ce temps, je peux hasarder une estimation de ce qui aurait pu arriver et combien de temps il faudra le réparer s'il n'est pas déjà réparé et, le cas échéant, quelles données nous avons peut-être perdues (mais j'ai de bonnes sauvegardes, de sorte que cela n'arrive jamais) j'espère).
Quant à la partie à blâmer:
si c'est juste une faute de frappe d'un collègue, il n'est pas nécessaire de le mentionner: la merde arrive et la frayeur du bug lui a probablement donné une leçon et j'espère qu'il ne le fera plus.
s'il a intentionnellement fait quelque chose que je lui ai dit de ne pas faire (par exemple, donner le mot de passe root du serveur de production au nouveau type et lui dire d'y apporter une modification directement sans supervision) (oui, c'est déjà arrivé ...), alors je dois le mentionner.
il fonctionnait hier car il était utilisé correctement.
vous constatez que d'autres personnes utilisent des choses d'une manière qui ne semble pas ê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 un bon environnement de test.
Sauvegarde!