Fail rapide par rapport à Robustesse

voix
16

Notre produit est un système distribué. Les modules sur lesquels je travaille sont assez nouveaux, assez rigoureux, bien testé. Ils ont été développés avec les meilleures pratiques récentes à l'esprit. D'autres modules peuvent être considérés comme les logiciels existants.

Alors que je suis vigilant sur tout ce qui se passe dans les modules dont je suis responsable, je suis sous pression constante de travailler avec de mauvaises données qui me sont envoyés des autres modules. Au fond, je suis un développeur principe « Fail rapide » et par conséquent, en cas de problème, je suis généralement en mesure d'éliminer la possibilité d'une erreur dans mes modules. Ce n'est pas tellement de blâme, sauvant tout gaspillage d'efforts dans la poursuite des bugs dans les mauvais endroits.

Mais l'argument que je continue à venir contre est: « Nous ne pouvons pas laisser ce genre de choses échouent dans la production, le client attend que cela fonctionne, pourquoi travaillez-vous pas autour de ce problème ». Et ce serait un argument en faveur de la robustesse: être libéral dans ce que vous acceptez, conservateur dans ce que vous envoyez.

Je tiens également à noter que ceux-ci sont pour la plupart des problèmes intermittents. Nous les voyons dans les tests d'intégration, mais ils sont difficiles à reproduire. Calendrier et sont impliqués concurrency.

Je suis un moment difficile équilibre entre les deux principes. Une partie de c'est mon souci que si je commence à permettre et à propager des données exceptionnelles, j'invite du mal et je ne vais pas avoir autant de confiance dans mon système. Mais je ne peux pas argumenter contre le maintien du système de travail, même si d'autres modules me envoient des données erronées. La raison pour laquelle d'autres modules ne sont pas se fixe est qu'ils sont trop complexes et fragiles, alors que le mien semble toujours claire et sûre. Mais si je ne suis pas résister à la pression, mes modules sera lentement aux prises avec les mêmes problèmes que j'ai Rejetant jusqu'à présent.

Je dois dire que le système ne «s'écraser » dans la production, mais mon module peut afficher simplement une erreur à l'opérateur et demandez-leur de contacter le support technique. Un accident serait un gros problème, mais si je signale l'erreur clairement, alors est-ce pas la bonne chose à faire? Je pense que mes collègues ne veulent tout simplement pas le client pour voir aucun problème, période. Mais mon module rejette les données d'autres modules au sein de notre produit, pas l'entrée à la clientèle. Donc, il me semble que nous sommes tout simplement pas aborder les problèmes.

Alors, dois-je être plus pragmatique ou tenir mon terrain?

Créé 28/01/2010 à 06:21
source utilisateur
Dans d'autres langues...                            


8 réponses

voix
3

Je dirais que cela dépend de ce qui se passe si vous n'arrêtez pas. Est-ce que le salaire de quelqu'un se traiter mal? Est-ce que le mauvais ordre s'envoyé? Ce serait intéressant de s'arrêter pour.

Si possible, demandez à votre gâteau et le manger trop - ne pas signaler l'erreur à l'utilisateur, obtenir le client d'accepter d'envoyer des rapports de diagnostic et de signaler tous les échecs de retour. Bug le développeur (s) qui possèdent le module de formation de failles (s) pour les fixer. Et bogue Je veux dire un rapport de bogue contre eux. Ou, si la direction ne pense pas que ça vaut le coût de fixation, ne sont pas.

Je voudrais aussi écrire des tests unitaires contre ces modules qui échouent, surtout si vous pouvez dire ce que l'entrée d'origine a été qui les a fait pour générer la sortie mal.

Ce qu'il vient vraiment à bien est ce que la personne qui examine votre performance veut de vous, surtout après vous expliquer le problème à eux, par courrier électronique.

Créé 28/01/2010 à 06:30
source utilisateur

voix
0

C'est une question délicate. Si votre module reçoit des données incorrectes et il est « ok » pour vous de ne rien faire avec eux et le retour, alors je suggère d'écrire à un journal d'erreur au lieu d'afficher une erreur à l'utilisateur.

Créé 28/01/2010 à 06:32
source utilisateur

voix
2

Autrement dit, cela ressemble à un « ne vérifie pas quelque chose que vous ne pouvez pas gérer ». Le fait que vous attraper l'erreur et en mesure de signaler cela signifie que vous n'êtes pas propager. Mais cela signifie aussi que, puisque vous pouvez le signaler, vous avez un mécanisme pour intercepter l'erreur et, par conséquent potentiellement gérer vous-même, et la corriger plutôt que signaler.

L'esprit, je suppose que votre rapport d'erreur est plus intéressante qu'une exception au hasard vous avez pris un endroit profond dans le système. Mais même alors, si elle est une exception que vous testez et vous créez (vous vérifier si le dénominateur est égal à zéro et d'envoyer une erreur plutôt que de simplement en divisant par inadvertance par zéro et attraper l'exception plus haut), alors que vous suggère pourrait bien avoir un moyen de corriger le problème.

En bout de ligne, vous avez besoin à la fois. Vous devez essayer de rendre les données moins d'erreurs pratiques, mais aussi signaler l'inattendu.

Je ne pense pas que vous pouvez verrouiller la porte et croiser les bras en disant « ce n'est pas mon problème ». Le fait qu'il vient de « vieux systèmes fragiles » n'a pas de sens. Votre code est pas vieux fragile et clairement la place efficace, en termes de l'ensemble du système intégré, de « réparer » les données, une fois que vous avez détecté le problème. Yea les anciens modules continueront de GIGO à d'autres systèmes moins, mais ces anciens modules combinés avec votre nouveau module sont un ensemble cohérent et donc constituent « le système ».

Le vrai problème typique ici est tout simplement l'équation du temps / valeur d'écrire tout ce correctif le code vs nouvelles fonctions. C'est un autre débat. Mais si vous avez le temps, et vous savez que les choses que vous pouvez faire pour nettoyer les données entrantes, « être libéral dans ce que vous acceptez » est une politique saine.

Créé 28/01/2010 à 06:37
source utilisateur

voix
2

Je ne vais pas entrer dans les raisons, mais vous avez raison.

Dans mon expérience, manquent de PHB la partie du cerveau nécessaire pour comprendre pourquoi Fail rapide mérite et « robustesse » telle que définie par do-it-tout-takes-manger-erreurs si-nécessaire est une mauvaise idée. Il est sans espoir. Ils ne disposent pas du matériel à grok il. Ils ont tendance à dire des choses « ok vous faites un bon point mais qu'en l'utilisateur » - il est juste leur version de penser aux enfants , et signale la fin d'une conversion avec moi chaque fois qu'il est élevé.

Mon conseil est de tenir votre terre. Éternellement.

Créé 28/01/2010 à 06:39
source utilisateur

voix
4

Je partage la préférence / principe « échec rapide ». Ne pensez pas cela comme un conflit de principes bien, il est plus un conflit de compréhension. Votre contrepartie a une certaine exigence non-dit ( « dont montrer à l'utilisateur un mauvais moment ») qui implique une certaine exigence manquée. Vous n'avez pas eu une chance de penser à / mettre en œuvre cette exigence préalable, si l'exigence a laissé un mauvais goût dans la bouche. Oubliez ce point de vue, re approche comme un nouveau projet avec une exigence fixe, vous pouvez travailler contre.

Peut-être le meilleur résultat est de donner un message d'erreur comme vous affiche. Mais il semble que vous avant d'avoir implémenté buy-in de votre homologue, quand ils avaient le choix de l'accepter. communication plus tôt ce que vous faisiez aurait pu aborder quelque chose comme ça.

Faites attention à la façon dont vous empêchez les idées. Constamment référence aux autres systèmes « trop complexes et fragiles » pourrait être les gens rebrousse. Qu'exprimer les systèmes sont nouveaux et prennent plus de temps à comprendre. Ne mettre le temps en les comprendre, de sorte que vous ne réduisez pas les peuples attentes de votre capacité.

Créé 28/01/2010 à 06:44
source utilisateur

voix
0

Cela dépend de la nature de la classe d'erreur que vous obtenez. Si la façon dont le système est des moyens de rupture, vous pouvez continuer à aller sans se nourrir de mauvaises données à d'autres parties du système, vous devez faire tout en votre pouvoir pour travailler avec ce entrée est donné.

A mon avis, si la pureté des données Trumps systèmes de travail, vous ne pouvez pas permettre à de mauvaises données de se propager ailleurs et d'autres systèmes corrompus. Dans la mesure où vous pouvez masser les données soient correctes puis continuer, vous devez le faire sur la théorie selon laquelle les données sont en sécurité et vous devez maintenir le fonctionnement du système ...

Je me plais à penser des choses en termes de flux de données. En passant de mauvaises données le long pollue tout le courant, et ce qui est mauvais parce que tout comme la pollution réelle une goutte peut gâcher une rivière toute des données (si un élément est mauvais, que pouvez-vous faire confiance à d'autre?). Mais aussi mauvais bloque le flux, ne rien laisser passer parce que vous avez repéré quelque chose que vous pouvez facilement supprimer. Filtrer dehors et si tout le monde à chaque étape est également filtrer, vous obtenez des données claires propres à l'autre bout, même si quelques impuretés ont commencé au milieu.

Créé 28/01/2010 à 07:11
source utilisateur

voix
0

La question de vos pairs est: « pourquoi ne travaillez-vous pas autour de ce problème »

Vous dites qu'il est possible pour vous détectez les mauvaises données et signaler une erreur à l'utilisateur. Telle est l'approche normale - une fois que vous connaissez les données à venir à vos fonctions est mauvaise, vous échouez rapidement (ce qui est la recommandation des autres réponses que j'ai lu ici).

Toutefois, votre question ne précise pas le domaine dans lequel votre logiciel fonctionne. Si vous connaissez les données à venir en est erronée, est-il possible pour vous de demander que les données à nouveau? Est-il réellement possible de récupérer de la situation?

Je l'ai mentionné que le « domaine » ici est important. Donc, si vous avez une application qui affiche des données vidéo transmises en continu par exemple, et peut-être votre signal sans fil est faible de sorte que le flux est corrompu, si le système « échec rapide » et affiche un message d'erreur? Ou si une moins bonne image est affichée, et une tentative de se reconnecter fait si nécessaire, en fonction de l'ampleur du problème?

En fonction de votre domaine, il peut être possible pour vous de détecter les mauvaises données, et de faire une deuxième demande pour les données sans incommoder l'utilisateur. (Ceci est clairement pertinent que dans le cas où vous attendez que les données soient mieux la deuxième fois, mais vous ne dites les problèmes que vous rencontrez sont intermittents et possibles concurrency liés) ...

Ainsi, l'échec rapide est bon, et est certainement quelque chose que vous devez faire si vous ne pouvez pas récupérer. Et vous ne devriez certainement pas propager de mauvaises données. Mais si vous pouvez récupérer, dans certains domaines, vous pouvez, puis n'est tout de suite pas nécessairement la meilleure chose à faire.

Créé 28/01/2010 à 07:40
source utilisateur

voix
1

Merci tout le monde. Le cas qui a poussé cette question se termine bien, et en partie grâce à des idées j'ai obtenu des réponses ci-dessus.

Ma première réaction a été de rester à l'échec rapide, mais je pensais à ce sujet un peu plus, et avait abouti à la conclusion que l'un des rôles de mon module est de fournir un point d'ancrage de stabilisation au reste du système. Cela ne signifie pas nécessairement accepter de mauvaises données, mais les problèmes de surfaçage, de les isoler et de les manipuler de manière transparente jusqu'à ce que nous trouvions une solution.

Je comptais ajouter un nouveau gestionnaire et le chemin de code pour ce cas, qui exécute correctement comme si elle était un cas particulier de l'utilisation qui était auparavant en situation irrégulière.

Nous avons eu une discussion où je réitère la nécessité de traiter le problème à la frontière, mais était également prêt à aider. Je décrit mon plan de l'autre côté, parce que je me doutais que ma position était considérée comme trop pédant, et que la solution était perçue comme moi que d'avoir à désactiver la validation fausse des données inoffensives, même si elle était incorrecte. En réalité, cependant, la façon dont je travaille est en grande partie guidée par les données, donc je lui ai expliqué la raison pour laquelle il doit être correct et la façon dont le comportement est entraîné par elle et comment en accueillir ces données, j'implantera un chemin de code spécial.

Je pense que cela a donné du poids à ma position et il a conduit à une discussion plus approfondie de l'aversion de l'autre côté pour fixer les données. Il est apparu qu'il était plus d'une lassitude de faire face à une erreur système existant sujette à un obstacle réel. Il y avait une solution relativement simple, il était effrayant de faire un changement, un état d'esprit qui est assez ancrée.

Mais après avoir diffusé tous les défis et les solutions possibles, nous avons finalement convenu de fixer les données, et jusqu'à présent, il semble avoir résolu notre problème. Nos tests d'intégration passent maintenant de manière cohérente, mais nous avons également ajouté l'exploitation forestière et continueront de le surveiller.

En résumé, je pense que pour moi, la synthèse des deux principes est qui ne jeûne est essentiel pour les problèmes de revêtement. Mais une fois qu'ils font surface, signifie la robustesse fournissant un chemin transparent pour continuer à fonctionner d'une manière qui ne compromet pas le système. Je suis en mesure d'offrir cela, et ce faisant, gagné une certaine bonne volonté de l'autre côté et a obtenu les données fixes à la fin.

Encore une fois, merci à tous ceux qui ont répondu. Je suis trop nouveau pour noter des commentaires, mais j'apprécie tous les points de vue présentés.

Créé 30/01/2010 à 07:36
source utilisateur

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more