qu'est-ce qu'une bonne politique de gestion de bug (du point de vue
d=E9veloppement)? Perso je suis un fan de:
- assert
- g=E9n=E9ration d'exception
- laissez les exceptions se lancer: par exemple ne pas v=E9rifier qu'un
argument qui est d=E9f=E9renc=E9 dans une m=E9thode ne soit pas nul, car
=E7a va planterde toute fa=E7on
Seulement, mon boss lui pense:
- tu dois rajouter "if (arg =3D null) return null" (dans les grandes
lignes)
son objectif est de cacher les bugs =E0 l'utilisateur, et de les g=E9rer
de mani=E8re "intelligente". Ca complexifie le code et quand on a pas un
r=E9sultat n=E9cessaire, on ne peut rien faire de toute fa=E7on...
ce qui fait que partout dans l'appli, il y a des contr=F4les de ce
genre.
On ne sait donc jamais quand null est une valeur autoris=E9e ou pas.
Qu'en pensez-vous?
Connaissez-vous des livres qui parle sp=E9cifiquement de =E7a?
(anecdotes, exp=E9rience, etc.)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Hervé AGNOUX
Anonymous user wrote:
Bonjour,
qu'est-ce qu'une bonne politique de gestion de bug (du point de vue développement)? Perso je suis un fan de: - assert - génération d'exception - laissez les exceptions se lancer: par exemple ne pas vérifier qu'un argument qui est déférencé dans une méthode ne soit pas nul, car ça va planterde toute façon
Oui, dans tous les cas, le système de stacktrace de java est bien pratique. Il faut cependant prendre garde à pouvoir enregistrer ces stacktraces et que l'enregistrement parvienne à l'équipe de développement ; lorsque le bug apparaît chez un utilisateur lambda ce n'est pas toujours évident.
Egalement pour analyser ce stacktrace il faut retrouver le source, et donc cela impose un système de gestion des versions style CVS.
Donc il manque à ta liste un CVS ou un subversion, sans lequel la gestion des bugs relève du coup de bol.
Et il y a aussi des bugs qui ne génèrent aucune exception, et qu'il est difficile de matérialiser par un assert. Contre ceux là, la seule solution que j'ai pu trouver est d'essayer que l'utilisateur puisse repérer le fonctionnement du logiciel, mais c'est difficile. C'est une voie que je trouve très intéressante, pourtant : la capacité à faire des logiciels dont le fonctionnement se comprend par l'utilisateur.
Seulement, mon boss lui pense: - tu dois rajouter "if (arg = null) return null" (dans les grandes lignes)
son objectif est de cacher les bugs à l'utilisateur, et de les gérer de manière "intelligente". Ca complexifie le code et quand on a pas un résultat nécessaire, on ne peut rien faire de toute façon...
Loin de moi l'idée de donner raison ou tord à ton boss !
Il est exact qu'il est des cas où un logiciel doit fonctionner quelque soit les bugs ou les pépins qui se produisent.
Et l'on peut penser qu'il est mieux que le logiciel sache se récupérer d'un bug éventuel - peut être ce que ton boss appelle "gestion intelligente" - mais c'est tout de même très compliqué.
Par exemple cela m'arrive souvent que lors du recueil d'une exception, je sache écrire le code qui corrige tout seul le problème. Par exemple, pour une raison inconnue il manque un fichier ?... Alors j'écris le code qui va bien pour placer le ficher au bon endroit. Et je place un simple warning dans les logs. L'utilisateur ne voit rien ; de toutes façons le problème est résolu automatiquement. Je mets un warning dans les logs car, des fois, il y a des bugs dans la correction automatique de bug...
Mais avec ce système on a vite fait de faire des correctifs de correctifs automatiques, ou de traiter des problèmes inexistants.
Une meilleure approche, me semble-t-il, est de rendre certaines fonctions modulables par l'utilisateur (par configuration, par script, par GUI, etc...), et de se dire : quelque soit la configuration choisie par l'utilisateur, alors le logiciel doit être capable de s'en sortir, y compris si cette config est complètement idiote, voire incohérente, voire éronnée.
Avec cette approche tu gagnes sur les deux tableaux : l'utilisateur peut mieux travailler, et toi tu as un logiciel plus solide, car tu as une source inépuisable de "cas de test" de cette façon.
Donc, plutot 1 point de + pour ton boss, finalement.
ce qui fait que partout dans l'appli, il y a des contrôles de ce genre.
S'il ne s'agissait que de faire des contrôles pour avoir des logiciels solides...
On ne sait donc jamais quand null est une valeur autorisée ou pas.
Crée une classe "NullAutorise" ? (je crois que quelqu'un l'a déjà fait :-)
Qu'en pensez-vous? Connaissez-vous des livres qui parle spécifiquement de ça? (anecdotes, expérience, etc.)
Ah ! XP peut être ?...
-- Hervé AGNOUX http://www.diaam-informatique.com
Anonymous user wrote:
Bonjour,
qu'est-ce qu'une bonne politique de gestion de bug (du point de vue
développement)? Perso je suis un fan de:
- assert
- génération d'exception
- laissez les exceptions se lancer: par exemple ne pas vérifier qu'un
argument qui est déférencé dans une méthode ne soit pas nul, car
ça va planterde toute façon
Oui, dans tous les cas, le système de stacktrace de java est bien pratique.
Il faut cependant prendre garde à pouvoir enregistrer ces stacktraces et
que l'enregistrement parvienne à l'équipe de développement ; lorsque le bug
apparaît chez un utilisateur lambda ce n'est pas toujours évident.
Egalement pour analyser ce stacktrace il faut retrouver le source, et donc
cela impose un système de gestion des versions style CVS.
Donc il manque à ta liste un CVS ou un subversion, sans lequel la gestion
des bugs relève du coup de bol.
Et il y a aussi des bugs qui ne génèrent aucune exception, et qu'il est
difficile de matérialiser par un assert. Contre ceux là, la seule solution
que j'ai pu trouver est d'essayer que l'utilisateur puisse repérer le
fonctionnement du logiciel, mais c'est difficile. C'est une voie que je
trouve très intéressante, pourtant : la capacité à faire des logiciels dont
le fonctionnement se comprend par l'utilisateur.
Seulement, mon boss lui pense:
- tu dois rajouter "if (arg = null) return null" (dans les grandes
lignes)
son objectif est de cacher les bugs à l'utilisateur, et de les gérer
de manière "intelligente". Ca complexifie le code et quand on a pas un
résultat nécessaire, on ne peut rien faire de toute façon...
Loin de moi l'idée de donner raison ou tord à ton boss !
Il est exact qu'il est des cas où un logiciel doit fonctionner quelque soit
les bugs ou les pépins qui se produisent.
Et l'on peut penser qu'il est mieux que le logiciel sache se récupérer d'un
bug éventuel - peut être ce que ton boss appelle "gestion intelligente" -
mais c'est tout de même très compliqué.
Par exemple cela m'arrive souvent que lors du recueil d'une exception, je
sache écrire le code qui corrige tout seul le problème. Par exemple, pour
une raison inconnue il manque un fichier ?... Alors j'écris le code qui va
bien pour placer le ficher au bon endroit. Et je place un simple warning
dans les logs. L'utilisateur ne voit rien ; de toutes façons le problème
est résolu automatiquement. Je mets un warning dans les logs car, des fois,
il y a des bugs dans la correction automatique de bug...
Mais avec ce système on a vite fait de faire des correctifs de correctifs
automatiques, ou de traiter des problèmes inexistants.
Une meilleure approche, me semble-t-il, est de rendre certaines fonctions
modulables par l'utilisateur (par configuration, par script, par GUI,
etc...), et de se dire : quelque soit la configuration choisie par
l'utilisateur, alors le logiciel doit être capable de s'en sortir, y
compris si cette config est complètement idiote, voire incohérente, voire
éronnée.
Avec cette approche tu gagnes sur les deux tableaux : l'utilisateur peut
mieux travailler, et toi tu as un logiciel plus solide, car tu as une
source inépuisable de "cas de test" de cette façon.
Donc, plutot 1 point de + pour ton boss, finalement.
ce qui fait que partout dans l'appli, il y a des contrôles de ce
genre.
S'il ne s'agissait que de faire des contrôles pour avoir des logiciels
solides...
On ne sait donc jamais quand null est une valeur autorisée ou pas.
Crée une classe "NullAutorise" ? (je crois que quelqu'un l'a déjà fait :-)
Qu'en pensez-vous?
Connaissez-vous des livres qui parle spécifiquement de ça?
(anecdotes, expérience, etc.)
qu'est-ce qu'une bonne politique de gestion de bug (du point de vue développement)? Perso je suis un fan de: - assert - génération d'exception - laissez les exceptions se lancer: par exemple ne pas vérifier qu'un argument qui est déférencé dans une méthode ne soit pas nul, car ça va planterde toute façon
Oui, dans tous les cas, le système de stacktrace de java est bien pratique. Il faut cependant prendre garde à pouvoir enregistrer ces stacktraces et que l'enregistrement parvienne à l'équipe de développement ; lorsque le bug apparaît chez un utilisateur lambda ce n'est pas toujours évident.
Egalement pour analyser ce stacktrace il faut retrouver le source, et donc cela impose un système de gestion des versions style CVS.
Donc il manque à ta liste un CVS ou un subversion, sans lequel la gestion des bugs relève du coup de bol.
Et il y a aussi des bugs qui ne génèrent aucune exception, et qu'il est difficile de matérialiser par un assert. Contre ceux là, la seule solution que j'ai pu trouver est d'essayer que l'utilisateur puisse repérer le fonctionnement du logiciel, mais c'est difficile. C'est une voie que je trouve très intéressante, pourtant : la capacité à faire des logiciels dont le fonctionnement se comprend par l'utilisateur.
Seulement, mon boss lui pense: - tu dois rajouter "if (arg = null) return null" (dans les grandes lignes)
son objectif est de cacher les bugs à l'utilisateur, et de les gérer de manière "intelligente". Ca complexifie le code et quand on a pas un résultat nécessaire, on ne peut rien faire de toute façon...
Loin de moi l'idée de donner raison ou tord à ton boss !
Il est exact qu'il est des cas où un logiciel doit fonctionner quelque soit les bugs ou les pépins qui se produisent.
Et l'on peut penser qu'il est mieux que le logiciel sache se récupérer d'un bug éventuel - peut être ce que ton boss appelle "gestion intelligente" - mais c'est tout de même très compliqué.
Par exemple cela m'arrive souvent que lors du recueil d'une exception, je sache écrire le code qui corrige tout seul le problème. Par exemple, pour une raison inconnue il manque un fichier ?... Alors j'écris le code qui va bien pour placer le ficher au bon endroit. Et je place un simple warning dans les logs. L'utilisateur ne voit rien ; de toutes façons le problème est résolu automatiquement. Je mets un warning dans les logs car, des fois, il y a des bugs dans la correction automatique de bug...
Mais avec ce système on a vite fait de faire des correctifs de correctifs automatiques, ou de traiter des problèmes inexistants.
Une meilleure approche, me semble-t-il, est de rendre certaines fonctions modulables par l'utilisateur (par configuration, par script, par GUI, etc...), et de se dire : quelque soit la configuration choisie par l'utilisateur, alors le logiciel doit être capable de s'en sortir, y compris si cette config est complètement idiote, voire incohérente, voire éronnée.
Avec cette approche tu gagnes sur les deux tableaux : l'utilisateur peut mieux travailler, et toi tu as un logiciel plus solide, car tu as une source inépuisable de "cas de test" de cette façon.
Donc, plutot 1 point de + pour ton boss, finalement.
ce qui fait que partout dans l'appli, il y a des contrôles de ce genre.
S'il ne s'agissait que de faire des contrôles pour avoir des logiciels solides...
On ne sait donc jamais quand null est une valeur autorisée ou pas.
Crée une classe "NullAutorise" ? (je crois que quelqu'un l'a déjà fait :-)
Qu'en pensez-vous? Connaissez-vous des livres qui parle spécifiquement de ça? (anecdotes, expérience, etc.)
Ah ! XP peut être ?...
-- Hervé AGNOUX http://www.diaam-informatique.com
Laurent Bossavit
Cher Anonyme,
qu'est-ce qu'une bonne politique de gestion de bug
Tu en as identifiée une: "fail fast". Ne pas cacher les erreurs.
En voici d'autres en vrac:
* Ecrire des tests unitaires dans le langage de l'appli, conjointement à l'écriture du code.
* Lorsqu'on constate un bug, ajouter un test unitaire qui met le bug en évidence *avant* la correction. On sait que la correction est bonne lorsque le test, qui signalait un échec, signale un succès.
* Faire relire tout le code qu'on écrit par au moins un autre programmeur.
* Appliquer des techniques comme la programmation par contract (DbC)
Sur les tests, tu peux venir rencontrer des experts à la conférence XP Day: http://xpday.fr/
Laurent http://xpday.fr !
Cher Anonyme,
qu'est-ce qu'une bonne politique de gestion de bug
Tu en as identifiée une: "fail fast". Ne pas cacher les erreurs.
En voici d'autres en vrac:
* Ecrire des tests unitaires dans le langage de l'appli, conjointement à
l'écriture du code.
* Lorsqu'on constate un bug, ajouter un test unitaire qui met le bug en
évidence *avant* la correction. On sait que la correction est bonne
lorsque le test, qui signalait un échec, signale un succès.
* Faire relire tout le code qu'on écrit par au moins un autre
programmeur.
* Appliquer des techniques comme la programmation par contract (DbC)
Sur les tests, tu peux venir rencontrer des experts à la conférence XP
Day: http://xpday.fr/
qu'est-ce qu'une bonne politique de gestion de bug
Tu en as identifiée une: "fail fast". Ne pas cacher les erreurs.
En voici d'autres en vrac:
* Ecrire des tests unitaires dans le langage de l'appli, conjointement à l'écriture du code.
* Lorsqu'on constate un bug, ajouter un test unitaire qui met le bug en évidence *avant* la correction. On sait que la correction est bonne lorsque le test, qui signalait un échec, signale un succès.
* Faire relire tout le code qu'on écrit par au moins un autre programmeur.
* Appliquer des techniques comme la programmation par contract (DbC)
Sur les tests, tu peux venir rencontrer des experts à la conférence XP Day: http://xpday.fr/
