Baike.dev
Connexion
> 返回资讯列表
news_article.exe
📰

J'ai dit qu'aucune donnée ne partait. Sur la première bonne manche, deux disques sont partis

I said no data was leaving. On the first good run, two records left

2026年9月4日6 次浏览来源:Dev.to 阅读原文

On m'a demandé si le système envoyait des données sur les patients à un organisme externe alors que l'intégration était à moitié construite. Je suis allé lire les journaux de chaque course. Ils sont tous morts tôt: certains avec un 415 parce que le type de contenu n'était pas ce que l'autre fin attendait, d'autres avec un 500. Personne n'a fait un appel. J'ai répondu que rien ne sortait. La première série qui a dépassé les 500 a envoyé deux demandes contenant des données cliniques réelles. Ma réponse avait été fausse depuis le début, et le pire est qu'elle était fausse d'une manière qui se sentait rigoureuse: j'avais regardé. J'avais des preuves. Les preuves étaient des registres d'exécutions réelles, pas des hypothèses. Un négatif ne dit rien de lui-même L'erreur n'était pas de mal lire les journaux. Il ne voyait pas ce qui a produit ce silence. Les pistes sont mortes avant d'atteindre le code qui envoie...

On m'a demandé si le système envoyait des données sur les patients à un organisme externe alors que l'intégration était à moitié construite. Je suis allé lire les journaux de chaque course. Ils sont tous morts tôt: certains avec un 415 parce que le type de contenu n'était pas ce que l'autre fin attendait, d'autres avec un 500. Personne n'a fait un appel. J'ai répondu que rien ne sortait. La première série qui a dépassé les 500 a envoyé deux demandes contenant des données cliniques réelles. Ma réponse avait été fausse depuis le début, et le pire est qu'elle était fausse d'une manière qui se sentait rigoureuse: j'avais regardé. J'avais des preuves. Les preuves étaient des registres d'exécutions réelles, pas des hypothèses. Un négatif ne dit rien de lui-même L'erreur n'était pas de mal lire les journaux. Il ne voyait pas ce qui a produit ce silence. Les pistes sont mortes avant d'atteindre le code qui envoie. Le journal n'a pas dit "je n'ai pas envoyé", il a dit "je n'ai jamais eu à la partie qui envoie". Ce sont deux énoncés différents et ils produisent exactement la même sortie : rien. C'est la forme générale du problème, et il apparaît partout une fois que vous le cherchez: Un compteur à zéro peut signifier "ça n'est pas arrivé" ou "le compteur n'a jamais été incrémenté". Un "non trouvé" peut signifier "il n'existe pas" ou "j'ai regardé au mauvais endroit". Un test vert peut signifier "il a passé" ou "il a sauté lui-même". Un peut signifie "il a travaillé" ou "la commande a été étranglée par un tuyau qui a avalé le code de sortie". Un tableau de bord silencieux peut signifier "tout va bien" ou "le processus qui l'alimente est mort depuis trois semaines". Dans les cinq cas, la preuve est identique. Et dans les cinq, la lecture optimiste est celle rassurante, donc c'est celle choisie sans réfléchir. Le contrôle positif La solution ne doit pas être plus suspecte. C'est de demander une chose spécifique avant d'accepter un négatif: Trouver quelque chose que le journal DOIT afficher si le chemin a été effectivement pris. Si le système avait atteint la partie qui envoie, quelque chose devrait apparaître dans le journal: la ligne "préparer la requête", l'identificateur de lot, la tentative de connexion. Tout signal impossible sans être passé par là. Si ce signal n'est pas là, vous n'avez pas démontré qu'il n'envoie pas. Vous avez démontré que vous ne savez pas si c'est envoyé. Et "je ne sais pas" est une réponse parfaitement respectable; "il n'envoie pas" était un mensonge. Quand ce témoin existe, le négatif commence à compter, parce que maintenant il sépare les deux mondes: est arrivé et n'a pas envoyé, versus n'y est jamais arrivé. Et vous devez veiller à nouveau sur le premier succès C'est la deuxième moitié, et dans mon cas c'était la plus chère. Je me suis occupé des échecs. C'est naturel : on enquête quand quelque chose tourne mal. Mais le comportement qu'on m'avait demandé de vérifier n'est apparu qu'au moment où les choses se sont passées, et cela ne se produit qu'après que quelqu'un ait corrigé les 415 et les 500. Donc, la règle complète a deux moments: vérifier que le chemin exécuté, et vérifier à nouveau après la première course réussie, pas seulement après les échecs. Le premier vert est le moment le plus dangereux d'une intégration, car c'est là que le nouveau code finit enfin par se terminer et personne ne regarde : il a déjà été déposé comme résolu. Tout ce qui peut rester silencieux doit dire pourquoi il est silencieux De cela vient une conséquence de conception qui a changé comment j'écris tout ce qui regarde. Un processus qui ne parle que lorsqu'il trouve un problème est indissociable d'un processus mort. Tous deux produisent le même silence, et le silence est exactement ce que nous lisons comme "tout bon". Donc un observateur qui peut légitimement rester silencieux doit émettre, chaque cycle, pourquoi il est calme: "412 entrées vérifiées, 0 violations" au lieu de ne rien dire. Ça coûte une ligne. Et il transforme « sain et silencieux » en quelque chose qui semble différent de « mort », ce qui est exactement ce que l'observateur existe pour distinguer. Il en va de même pour les tests : une suite qui signale « 0 échecs » sans dire combien de tests elle a effectué n'a rien dit. Zéro sur zéro est vert. Ce qui reste Avant de réclamer quelque chose ne se passe pas, vérifiez que le code capable de le faire a réellement couru. Si tu ne peux pas vérifier ça, t

> 分享: