Ce qui fait la différence entre un simple projet et un bon projet

Citation:

---

Envoyé par Franck SORIANO

Enfin dernière remarque, tu sembles penser qu'il est effectivement possible de trouver tous les bugs existants dans une application. Pourtant, tout le monde sait qu'en informatique, le 0 défaut n'existe pas. S'il existait une méthode miracle qui t'assure qu'un programme ne contient aucun bug, tout le monde s'en servirait et le mot "bug" n'existerait que dans son sens premier...

---

Tu peux utiliser un outil comme Coq, qui peut vérifier à 100% qu'un code donné en Coq correspond bien à une spécification de haut-niveau (évidemment si celle-ci est incorrecte...), la solution existe donc, mais le coût d'utilisation d'une telle méthode pour écrire des programmes non-triviaux est énorme et complètement disproportionné par rapport aux bénéfices pour une entreprise normale. Maintenant il y a des cas où tu préfères que ton code soit certifié conforme à la spécification (le domaine médical, les logiciels d'avions de ligne, ... tous les cas mettant en jeu la vie humaine), mais même dans ces cas, les outils de certifications ne sont pas toujours utilisés. (J'ai parlé de Coq, mais ce n'est qu'un exemple, d'ailleurs mal adapté à un certain nombre d'autres contraintes souvent rencontrées dans les cas critiques (temps réel), il existe par exemple des méthodes de certification pour du C (ex : Caduceus), ...)

--
Jedaï

Citation:

---

si l'expert guide bien l'analyse statique, ça peut réduire les fausses alertes, et permettre aux développeurs de se consacrer sur les vraies erreurs

---

Tien, je n'avais même pas pensé que l'analyse statique pouvait signaler de fausses erreurs...

Citation:

---

à l'époque de Pasteur, tout le monde savait que la génération spontanée était une évidence, à celle de Copernic que le Soleil tournait autour de la Terre... on a même tué ou failli tuer ces hommes pour avoir dit le contraire. Pourtant, force est de constater que notre conception de ces problématiques a bien changé depuis

---

Bonne réponse. Mais c'était une façon rapide de dire que depuis le début de l'informatique, les mathématiciens essaient de traiter l'informatique comme s'il s'agissait de mathématiques.
A ce titre, ils ont tenté les spécifications formelles. Pour arriver très vite à la conclusion que dans la pratique, il y a tellements de cas que c'est très vite incompréhensibles et inutilisables, même sur des problèmes simples.
Dans le même ordre d'idée, ils ont démontré que du fait de l'explosion combinatoire dont tu parles, même le programme le plus simple devient très vite intestable de façon exhaustive car le nombre de cas de figure à tester devient vite astrosnomique. Ce qui fait qu'on ne peut jamais garantir qu'un programme est sans bug.


Peut-être qu'un jour, on découvrira que c'est tout à fait possible, ou que les machines seront tellement puissantes qu'on pourra traiter l'explosion combinatoire sans problèmes. Mais la majorité des développeurs ne travaille pas dans un labo de recherche et doit se contenter de solutions réalisables, rapides fiables et surtout rentables...

D'autant plus que rien de tout ça ne permet de détecter les erreurs de conception ni les erreurs de spécifications. Et je ne parle même pas du client qui a dit blanc tout en pensant noir alors qu'en réalité, il voulait violet...

Citation:

---

Envoyé par Franck SORIANO

D'autant plus que rien de tout ça ne permet de détecter les erreurs de conception ni les erreurs de spécifications. Et je ne parle même pas du client qui a dit blanc tout en pensant noir alors qu'en réalité, il voulait violet...

---

De toute facon, les specifications changent toujours et ne restent jamais figees. L'informaticien (le maitre d'oeuvre) a la responsabilite de bien savoir ce que le client lui a demande (maitrise d'ouvrage) pour ne pas se faire avoir. Et bien lui faire comprendre quand changement il y a. La gestion des exigences est aussi un metier a part...

Citation:

---

Envoyé par _vince_

Et bien lui faire comprendre quand changement il y a. La gestion des exigences est aussi un metier a part...

---

8O

NON.. Le rôle d'un utilsateur n'est PAS de savoir qu'il y a un changement dans le logiciel.

On en revient à ce qu'on disait au-dessus : si une nouvelle demande génèrera côté logiciel un travail énorme, c'est qu'il y a une erreur de conception (ou d'analyse de départ) fondamentale.

Là tu parles avec une "équipe interne" d'utilisateurs.

Mais toi, par exemple en tant qu'utilisateur Windows, tu acceptes d'être convaincu par M$ qu'il faut que tu changes ta manière de faire ?????????

Citation:

---

Envoyé par souviron34

(.../...)On en revient à ce qu'on disait au-dessus : si une nouvelle demande génèrera côté logiciel un travail énorme, c'est qu'il y a une erreur de conception (ou d'analyse de départ) fondamentale.(.../...)

---

ben non, on est pas d'accord sur le sujet. On ne peut pas tout demander à une application existante. Quand tu conçois une application, c'est dans un cadre donné. 20 ans plus tard, le cadre n'a rien à voir. Et les modifications deviennent hyper-couteuses. A tel point qu'une refonte devient nécéssaire.

Surtout, ça nécéssite de surdimensionner certains points. On m'a répondu qu'il fallait faire du N-N partout. Mais c'est gourmand en ressources machines et en temps de développement. Quand tu as 80 tables, et qu'à chaque fois tu dois te farcir le N-N avec tout ce que ça implique, tu facilites peut-être les évolutions futures, mais tu ne finiras jamais ton projet. Utilité?????

Je ne dis pas qu'il ne faille pas laisser de place aux évolutions ultérieures. Mais des choix doivent être faits, à un moment ou un autre. Aucune application ne peut TOUT faire. Toutes, cependant, peuvent être amenées à subir des modifications majeures qui obligeront à les repenser(ce qui est long et couteux).

Ce que tu appelles erreur fondamentale, moi j'appelle ça évolution de la société. On ne sait pas ce que sera la loi, le marché, ou l'activité économique dans 10 ans. Si certaines évolutions sont prévisibles(genre l'an 2000), d'autres sont moins anticipables(le changement de référentiel monétaire de 2002, par exemple). Peux tu prétendre que si tu avais bossé avant 1997(date de vote du passage à l'Euro, si mes souvenirs sont exacts), tu aurais implémenté dans tout tes programmes un grigri permettant de changer de monnaie d'un claquement de doigts? Moi, je n'ai pas cette prétention. Et j'aurais mangé des modifs merdiques pendant 2 ans pour migrer tout ça. Cela fait de moi un concepteur minable?

Et si tu sais faire l'application ultime auto-adaptatrice, je suis preneur de la méthode......

Citation:

---

Envoyé par souviron34

Mais toi, par exemple en tant qu'utilisateur Windows, tu acceptes d'être convaincu par M$ qu'il faut que tu changes ta manière de faire ?????????

---

Ca dépend si la nouvelle manière de faire est plus rentable.

Citation:

---

Envoyé par el_slapper

...

---

Mais pourquoi etre susceptible comme ca ?? je ne parlais pas de toi, mais en general..

Et d'autre part, je maintiens, comme je l'ai dit plus haut, que, meme si on ne ferais pas du N*N, on ferait du dynamique..

n = GetLeftRelations("TOTO")

m = GetRightRelations("TOTO");

ou quelque chose du genre...

En quoi est-ce impossible ????

Citation:

---

Envoyé par davcha

Ca dépend si la nouvelle manière de faire est plus rentable.

---

absolument, mais ca n'etait pas la maniere de dire ;)

Et ne pas oublier en vrac:

• le plan de test
• La tracabilité depuis les besoins utilisaters aux tests de validation en passant par les spécifications fonctionelles, les specifications détaillées
• Les indicateurs de qualité

Citation:

---

Envoyé par Graffito

Et ne pas oublier en vrac:

• le plan de test
• La tracabilité depuis les besoins utilisaters aux tests de validation en passant par les spécifications fonctionelles, les specifications détaillées
• Les indicateurs de qualité

---

Aurais-tu des conseils à donner pour les deux premiers?

et qu'est-ce que "les indicateurs de qualité" ?
(désolé, je débute...)

Je vais essayer de résumer, pour plus de détails, il faudra se référer aux diverses méthodologies de dévellopement.

Pour la traçabilité, on donne une référence unique :

1. à chaque élément des besoins utilisateur,
2. à chaque élement des spécifications fonctionnelles,
3. à chaque élement des spécifications détaillées.

et on vérifie pour chaque document que chaque élement de l'étape précédente est couvert par un élément de l'étape en cours (=> matrice de tracabilité)

Pour le plan de tests, on référence chaque test élémentaire, on indique la méthode de test et les résultats attendus (et évidemment on trace vers les spécifs détaillées).
Pour les résultats de test, on identifie les sesssions de tests par une référence, l'environnement, la date.
Face à chaque test élémentaire, on met la session, le résultat pour cette session et un éventuel commentaire.

Pour les idicateurs qualité, voir wikipedia.Measurement_of_software_quality_factors
Exemples pratiques de "mesures":
- nombre de problèmes constatés par période,
- temps d'indisponibilité,
- délai de correction des erreurs.

Merci!

Je dois dire que je suis surpris de ce que je lis, dommage que j'arrive à la fin du débat.
Déjà on parle de programmation défensive, et je ne suis que moyennement d'accord avec ce que je lis.

1) Lorsqu'on parle de saisie utilisateur, je suis entièrement d'accord que ces données doivent être soigneusement validées avant d'être utilisées. Il est clair que s'il en a la possibilité, l'utilisateur sera capable de saisir un 30 février dans un champ date.

2) Concernant les données internes au programme, celles qui ne sont pas saisies par l'utilisateur. Est-ce que cela a forcément toujours un sens de procéder à une validation des paramètres? Pour reprendre un exemple cité ci-dessus, vérifier qu'une collection passée est non-nulle avant de faire un foreach?

Je dirai que cela dépend de la fonction, si celle-ci est exposée sur une façade telle qu'un webservice, une dll mise à disposition d'une autre équipe ou d'un tiers, alors oui c'est indispensable.
En revanche, si cette fonction se situe dans un contexte maitrisé de l'application, suivant comment ça ne fait qu'ajouter des lignes de codes superflues qui nuisent à la lisibilité et que l'on aurait tendance à copier-coller de gauche à droite entre les overloads et les fonctions *qui ont à peu près la même gueule*.
Soyons clairs, si la fonction est documentée correctement, c'est à dire que l'on précise que les paramètres ne sont pas nullables, le développeur qui appelle cette fonction et se prend un nullpointerException il saura à quoi s'en tenir.

3) Si vous devez écrire une valeur dans le fichier de configuration de votre application, devez-vous forcément vérifier des situations telles que le manque d'espace disque ou l'absence de droits d'écriture avant d'appeler les méthodes File.Write ou autres ???
Personnellement, je me contente de mettre tout cela dans une méthode de haut niveau qui catche un éventuel IOException pour le décorer d'une exception personnalisée "ConfigFileException" que je laisse remonter jusque dans le handler global de mon application, après quoi celle-ci se termine avec une joli message d'erreur "(....) Un problème est survenue avec le fichier de configuration", le message de l'exception vient ensuite.

D'ailleurs c'est un cas tellement rare que l'on pourrait presque laisser l'IOException brute remonter.

Comme dit plus haut, l'important est de relier les tests et les exigences entre eux pour etre sur que tu testes bien les fonctionnalites demandees dans les specs.

@Frank:
On n'utilise pas les meme vocabulaire. Voici ce que j'entends par programmation par contrat:
http://en.wikipedia.org/wiki/Asserti...gn_by_contract

@skip:
Ce que j'essaie d'expliquer, c'est que le programmeur doit aussi se proteger de ses propres erreurs de logique. Par exemple en C++, un programmeur utilise un pointeur qui pointe sur rien alors qu'il pense que le pointeur pointe sur quelque chose de valide.

@souviron34:
Je veux dire que les developpeurs doivent faire attention a ce que le client ne fasse pas passer un bug alors que c'est un changement de specs.

Citation:

---

Ce que j'essaie d'expliquer, c'est que le programmeur doit aussi se proteger de ses propres erreurs de logique. Par exemple en C++, un programmeur utilise un pointeur qui pointe sur rien alors qu'il pense que le pointeur pointe sur quelque chose de valide.

---

C'est bien vrai, cependant il faut faire très attention à ne pas utiliser de tests qui occultent des situations imprévues.
-Une application qui plante à cause d'une situation imprévue, c'est gênant.
-Une application qui continue de s'exécuter malgré une situation imprévue, c'est encore pire car c'est dangereux!
Donc conclusion ce qui n'est pas prévu ne doit pas être géré, ou alors doit être reporté correctement, que ce soit sous forme d'une exception ou autre.

On a différent moyen de se préparer aux erreurs de dévs. Le conseil que je donne et qui pour moi fait une bonne partie de la différence entre un pro et un bricoleur est le suivant : Utilisez toujours sauf exceptions du code fortement typé.
Préférez toujours taper un
String.getBytes( System.Encoding.Charset.UsAscii.getName() )
plutot qu'un String.getBytes( "UsAscii").

C'est un exemple assez gros, mais vous avez l'avantage que la première solution est vérifiée à la compilation, la deuxième n'est qu'une chaine littérale qui se plantera en runtime si par malheur elle est écrite fausse.
Plus vous avez de code vérifié à la compilation, moins vous aurez de chance que le client trouve des bugs avant vous.

Une deuxième chose qui rejoint la première, les tests unitaires. Très important pour tester la non-régression du code. Parfois onéreux en temps, mais sur le moyen terme on y gagne.
On peut aussi faire du développement piloté par les tests, une excellente approche selon moi, hélas elle est pas toujours évidente à mettre en oeuvre lorsque l'on a une source de donnée derrière.

Citation:

---

Envoyé par _skip

(.../...)
On peut aussi faire du développement piloté par les tests, une excellente approche selon moi, hélas elle est pas toujours évidente à mettre en oeuvre lorsque l'on a une source de donnée derrière.

---

Tu peux détailler ce point-là? Je ne vois pas ce que ça peut être.....:(

En cherchant Test-driven development on trouve un paquet de ressources là dessus, c'est un peu ce qui est parfois mis en avant dans le développement agile.
En gros, l'idée générale c'est d'écrire des cas de test AVANT l'implémentation de la fonctionnalité.

ça me fout les jetons, ça. J'ai eu l'exemple VRAI d'un forfait ou les cas-tests étaient écrits à l'avance. Sur certaines fonctions, les types avaient codé en dur les réponses au cas test(par exemple, pour une somme de 1000, avec 4,5% d'interêt, le cas-test attendait 45. Alors le programme donnait toujours 45. Quel que soit le montant ou le taux d'interêt).

Plus généralement, je me suis aperçu en faisant l'aller-retour entre les fonctions de développeur et de testeur, que(spécifiquement en transactionnel) des cas-tests complets(établi suivant les règles de l'art, et couvrant l'ensemble des besoins) étaient très insuffisants. Et que les utilisateurs avaient l'art de taper sur l'apli jusqu'à ce qu'elle casse. Et que les autres applications avaient aussi tendance à faire des choses plus évoluées que ce que l'on pense au départ(cas typique du client qui décède ou change de banque entre les 2 parties de l'application). En bref, même avec des équipes de bonne foi, se baser sur le résultat attendu me semble insuffisant pour prétendre avoir tester la robustesse de l'appli.....(N.B. - en Batch, ce genre de problèmatique est beaucoup moins forte, et si on ne se fait pas piéger par du codage en dur, la démarche ne me parait pas aberrante).

Citation:

---

Envoyé par _skip

En cherchant Test-driven development on trouve un paquet de ressources là dessus, c'est un peu ce qui est parfois mis en avant dans le développement agile.
En gros, l'idée générale c'est d'écrire des cas de test AVANT l'implémentation de la fonctionnalité.

---

Je me demande combien de developpeurs pratiquent le TDD ? Et si oui, est-ce que c'est la meme personne qui teste et qui code ?

Citation:

---

Et si oui, est-ce que c'est la meme personne qui teste et qui code ?

---

Surtout pas ! Il faut un regard exterieur, un point de vue différent. Sinon, on va tester "pour que cela marche" et c'est tout (à moins d'avoir une excellente rigueur/méthode).