Moralité : si vous investissez de votre temps à développer un logiciel de qualité, ne gâchez pas sa stabilité avec Berkeley DB !
Hum… c'est mon cas… enfin, j'essaie de faire de la qualité, et c'est pour ça que le dev prend un temps fou (au bout de presque un an, toujours pas utilisable pour un utilisateur réel, sachant que je "réécrit" un logiciel écrit en delphi pour le rendre portable…).
Pour le coup, niveau configuration j'ai opté pour un fichier pour l'appli, et deux arborescences de fichiers différentes pour l'interface (une pour les menus, une pour les toolbars amovibles, sachant que chaque item invoque l'action plug-in).
Si tu as des avis la-dessus, je suis preneur…
Sachant que, bien entendu, le coût que j'ai accepté de payer sur mon temps personnel, je doute très fortement qu'une entreprise ou même la plupart des logiciels libres acceptent de le payer, vu qu'on risque toujours de se planter, et dans ce cas, on s'expose au risque de perte de milliers d'heures de boulot tout de même (ben oui, 3H/jour pendant 1 an, on tape déjà le millier… j'en suis pas encore la, mais je dois bien être à 500-600 heures, pour un résultat non productif, si j'inclue les heures de recherche et d'apprentissage purs. ).
Et puis s’il ne s’agit que d’options non cruciales d’un logiciel pour utilisateur final, mieux vaut encore les réinitialiser que de bloquer le lancement du logiciel avec un message cryptique pour l’utilisateur lambda.
Mon humble avis:
Si vous développez un logiciel de qualité, commencez par vérifier chaque paramètre de configuration. Si le paramètre lu ne correspond pas, balancez une exception, qui explique d'où elle viens, et ce qui la cause.
Le jour ou vous aurez fini votre fonctionnalité, faites un tour dans vos exceptions (grep -lr throw devrait faire le taf) et implémentez des try…catch.
Du coup, je te contredis: dans un premier temps, les laisser planter tout le système est une bonne idée, ça permet de se concentrer sur l'ajout de fonctionnalités et l'amélioration des messages d'erreurs, qui sont au moins aussi importants que la stabilité.
Bien sûr, cette technique porte de meilleurs fruits si on se base sur des fichiers de texte brut, car l'utilisateur peut alors régler le problème… lui-même, sans télécharger de logiciels.
Faut pas oublier que les dev sont pas des bêtes de somme, surtout dans le libre ou la plupart font ça sur leur temps perso, et n'ont que peu voire aucun retour tant que le logiciel n'est pas utilisable. (Je ne peux pas parler de la phase du logiciel utilisable puisque le mien ne l'est pas encore…) Le problème, c'est qu'un logiciel de qualité, ça prend plus de temps à être utilisable qu'un truc mal codé, et pendant ce temps, le moral du dev joue énormément.
[^] # Re: Plantages...
Posté par freem . En réponse à la dépêche Gnumeric 1.12. Évalué à 2.
Hum… c'est mon cas… enfin, j'essaie de faire de la qualité, et c'est pour ça que le dev prend un temps fou (au bout de presque un an, toujours pas utilisable pour un utilisateur réel, sachant que je "réécrit" un logiciel écrit en delphi pour le rendre portable…).
Pour le coup, niveau configuration j'ai opté pour un fichier pour l'appli, et deux arborescences de fichiers différentes pour l'interface (une pour les menus, une pour les toolbars amovibles, sachant que chaque item invoque l'action plug-in).
Si tu as des avis la-dessus, je suis preneur…
Sachant que, bien entendu, le coût que j'ai accepté de payer sur mon temps personnel, je doute très fortement qu'une entreprise ou même la plupart des logiciels libres acceptent de le payer, vu qu'on risque toujours de se planter, et dans ce cas, on s'expose au risque de perte de milliers d'heures de boulot tout de même (ben oui, 3H/jour pendant 1 an, on tape déjà le millier… j'en suis pas encore la, mais je dois bien être à 500-600 heures, pour un résultat non productif, si j'inclue les heures de recherche et d'apprentissage purs. ).
Mon humble avis:
Si vous développez un logiciel de qualité, commencez par vérifier chaque paramètre de configuration. Si le paramètre lu ne correspond pas, balancez une exception, qui explique d'où elle viens, et ce qui la cause.
Le jour ou vous aurez fini votre fonctionnalité, faites un tour dans vos exceptions (grep -lr throw devrait faire le taf) et implémentez des try…catch.
Du coup, je te contredis: dans un premier temps, les laisser planter tout le système est une bonne idée, ça permet de se concentrer sur l'ajout de fonctionnalités et l'amélioration des messages d'erreurs, qui sont au moins aussi importants que la stabilité.
Bien sûr, cette technique porte de meilleurs fruits si on se base sur des fichiers de texte brut, car l'utilisateur peut alors régler le problème… lui-même, sans télécharger de logiciels.
Faut pas oublier que les dev sont pas des bêtes de somme, surtout dans le libre ou la plupart font ça sur leur temps perso, et n'ont que peu voire aucun retour tant que le logiciel n'est pas utilisable. (Je ne peux pas parler de la phase du logiciel utilisable puisque le mien ne l'est pas encore…)
Le problème, c'est qu'un logiciel de qualité, ça prend plus de temps à être utilisable qu'un truc mal codé, et pendant ce temps, le moral du dev joue énormément.