Posté par freem .
En réponse au journal Petite histoire de debug.
Évalué à 4.
Dernière modification le 02 août 2020 à 22:49.
Tu veux dire que ça, c'est pas du use-case ?
En vrai, j'ai dis le problème d'origine, mais c'est p'tet juste un d'eux. Pas comme si on avait des gens dont c’eut été le métier, en fait, alors on s'est démerdé à l'empirique.
Bon, et sinon, le "use case a écouter", c'était "Bonjour, je suis arrivé, la borne est freeze". Démerdes toi. Faut faire un poff/pon déjà pour remettre en service, parce que le client en a besoin pour alimenter son bateau, et donc ouai, t'as aucune info, sauf, ça freeze. Est-le soft? Est-le hard? Tu sais pas.
Et tu peux pas forcément aller voir sur place, non.
je crois que ça reste pareil : si y'a une sorte de grain de sable, il faut le trouver avant de s'attaquer au reste.
Dans ce cas on n'aurait jamais rien livré, parce qu'on ne peux pas reproduire aisément dans un petit atelier le passage a proximité d'une péniche mal blindée, l'usage d'un groupe électrogène foireux dans un système qui est connecté d'une manière ou d'une autre au système électrique, les problèmes de radio, etc.
C'est une des différences entre les problèmes liés au hard et ceux qui sont 100% logiciels.
Dans une solution purement logicielle, tu peux tout simuler a moindre frais, tu peux même fuzzer pour 3 fois rien, sans même instrumenter!
Quand c'est lié au hard (ou a des bugs de firmware qui seraient utilisés dans des composants hein)... pas vraiment. C'est pire que d'avoir un code proprio à intégrer.
Après, je manque clairement d'expérience sur le sujet, mais le peu que j'en ai me fait penser que c'est bien plus difficile a jauger quand il faut composer avec le matériel, ses défauts, les conditions météorologiques, les systèmes pourris qui passent à côté et t'envoient un max de parasites de partout (oui, le blindage aide, les mises à la masse aussi, mais difficile de toute tester amha), ...
[^] # Re: Corriger par paire
Posté par freem . En réponse au journal Petite histoire de debug. Évalué à 4. Dernière modification le 02 août 2020 à 22:49.
En vrai, j'ai dis le problème d'origine, mais c'est p'tet juste un d'eux. Pas comme si on avait des gens dont c’eut été le métier, en fait, alors on s'est démerdé à l'empirique.
Bon, et sinon, le "use case a écouter", c'était "Bonjour, je suis arrivé, la borne est freeze". Démerdes toi. Faut faire un poff/pon déjà pour remettre en service, parce que le client en a besoin pour alimenter son bateau, et donc ouai, t'as aucune info, sauf, ça freeze. Est-le soft? Est-le hard? Tu sais pas.
Et tu peux pas forcément aller voir sur place, non.
Dans ce cas on n'aurait jamais rien livré, parce qu'on ne peux pas reproduire aisément dans un petit atelier le passage a proximité d'une péniche mal blindée, l'usage d'un groupe électrogène foireux dans un système qui est connecté d'une manière ou d'une autre au système électrique, les problèmes de radio, etc.
C'est une des différences entre les problèmes liés au hard et ceux qui sont 100% logiciels.
Dans une solution purement logicielle, tu peux tout simuler a moindre frais, tu peux même fuzzer pour 3 fois rien, sans même instrumenter!
Quand c'est lié au hard (ou a des bugs de firmware qui seraient utilisés dans des composants hein)... pas vraiment. C'est pire que d'avoir un code proprio à intégrer.
Après, je manque clairement d'expérience sur le sujet, mais le peu que j'en ai me fait penser que c'est bien plus difficile a jauger quand il faut composer avec le matériel, ses défauts, les conditions météorologiques, les systèmes pourris qui passent à côté et t'envoient un max de parasites de partout (oui, le blindage aide, les mises à la masse aussi, mais difficile de toute tester amha), ...