Discussion :

[kisitomomotene]

Salut à tous

Je développe une application qui me semble "interminable". Voici ce qui se passe :
- Je fais une conception globale, puis je code directement les détails.
- Très souvent, lorsque j'ajoute une nouvelle fonctionnalité, ou bien lorsque je détaille certaines fonctionnalités conçues, je me retrouve soit avec certaines incohérences avec ce qui a déjà été fait, soit avec un code "sale" et je me trouve obliger de réfactorer tout le code.
Ce refactoring fait que les délais de développement sont largement dépassés et, au lieu d'avoir une évolution linéaire, je me retrouve avec une évolution cyclique.
Je reste sur place parce que presque tout le temps est consacré au refactoring pour que le code soit "propre", cohérent, logique.

Est ce que vous avez déjà eu ce problème ?
Et comment y faire face ?

[Franck SORIANO]

Il faut avoir énormément d'expérience pour être capable de tout faire juste du premier coup.
Et même après, tu peux être très doué et faire une conception parfaite tout de suite, ça ne t'empêchera pas de devoir tout refaire parce que les besoins étaient mal définis au départ, parce que le client (ou les utilisateurs en général) ne savent pas ce qu'il veut.

Ce que tu décris ne me surprend pas beaucoup. C'est ce que j'ai souvent vu. A une exception près : Très souvent on code un truc d'une façon. On se rend compte que ça ne tien pas la route. Et au lieu de le refactorer pour que tout soit propre et robuste, on le garde en l'état et on insiste avec, en ajoutant une verrue... Plus les deadline approchent, et moins on est regardant sur le code.

Comme on dit, avant de faire un chef d'oeuvre, il faut faire un brouillon
Personnellement, je fais la plupart de mes dev au moins deux fois :
- La première fois, je bacles le tout le plus vite possible, pour avoir une première version qui fait vaguement ce qu'elle est censée faire. Ca permet d'affiner l'analyse, d'avoir été confronté une fois à tout les problèmes, d'avoir une meilleure compréhension du problème global.
- Puis une fois que j'ai quelque chose qui tourne, je le montre à mes utilisateurs, je leur fait tester, voir ce qui leur convient, ce qui ne leur plait pas...
- Enfin, je refais tout proprement. Comme cette fois ci, les problèmes ont tous été bien identifiés par la première réalisation, que les utilisateurs ont compris ce dont ils ont besoin et ce qu'ils veulent, ça va finalement très vite.
Et au final je me retrouve avec quelque chose qui convient au plus grand nombre tout en étant assez bien écrit !

[el_slapper]

Les lois d'airain du développement

en Français :

1)on ne sait pas donner d'estimation tant qu'on a pas une conception précise
2)on a pas de conception précise tant qu'on a pas compris l'intégralité des exigences
3)on a pas compris toutes les exigences tant qu'on a pas fini le projet
4)quand on a fini le projet, les exigences ont changé

Il est préférable d'avoir le temps de refactoriser, mais ça n'est pas toujours possible. La méthode de Franck est idéale, mais il faut pouvoir se le permettre.

[Maximil ian]

Salut,

Un conseil : essaie d'avancer par petits pas sûrs plutôt que de te lancer dans le développement d'une grosse fonctionnalité d'une seule traite qui va générer un mini effet tunnel. En d'autres termes, essaie de partir du plus trivial et d'ajouter itérativement du code pour aboutir à la construction complexe qui couvre tous les besoins. Plus les pas seront petits, plus le niveau d'"incohérence avec ce qui est déjà fait" ou de "saleté" sera à chaque fois minime et facilement réparable.

Comment garantir que tes petits pas sont sûrs ? En ayant un filet de sécurité de tests unitaires qui t'informe si ce que tu es en train de coder ne casse pas d'autres fonctionnalités. Comment t'assurer que si tu trébuches ça sera facilement réparable ? En ayant une couverture de tests complète et fine qui te permettra de mettre tout de suite le doigt sur l'endroit précis où des corrections sont nécessaires.

Concernant les refacto, effectivement on tombe très facilement dans un effet domino où un refacto en entraine un autre et on n'en voit plus la fin. Une bonne façon de rationnaliser cela et d'éviter de passer 90% de ton temps dessus est de les rendre les refactos eux aussi les plus atomiques possibles et de leur donner une place précise et restreinte dans le déroulement de ton processus de développement.

Jette un oeil à TDD, je pense que tu y trouveras pas mal de pistes pour répondre à tes questions.

[souviron34]

je crois que tu as un problème de base :

tu n'as pas fait une bonne analyse ni une bonne conception..


Ensuite, je ne sais pas avec quel outil/langage/paradigme tu programmes.




La procédure "normale" à suivre est d'une part de faire une analyse approfondie, et d'identifier les fonctionalités essentielles, ainsi que leur arborescence..


A partir de là, tu as une architecture de base.


Ensuite, dans la programmation, il vaut mieux toujours prévoir... et y aller pas à pas..

Donc programmer l'arborescence où au fur et à mesure tu inclues toutes les fonctionalités essentielles, sous forme de méthodes/procèdures suivnt ton paradigme, vides.



Tu pêches par ce qui avait été mis en évidence dans un autre post ici-même (je crois que c'était "développement brouillon")..


Dans le cycle en V traditionnel, une fois l'analyse faite, la Conception Préliminaire devait produire l'ensemble des prototypes des fonctions du logiciel, avec le détail de leurs interfaces.

Même en développement Agile, l'étape entre l'analyse et le codage passe par cette étape...

Visiblement, tu n'as pas réfléchi suffisamment à la conception...






Ensuite, je pense que (mais c'est un sentiment personnel, que je ne peux appuyer de statistiques) les langages objets avec leurs classes et héritages, rendent l'évolution d'un logiciel mal défini bien plus lourde et nécessitant beaucoup plus de re-factoring que des langages procéduraux, qui, grâce aux procédures, et donc au découpage fonctionnel et non objet, sont plus à même d'être "évolutifs par morceaux".




En conclusion, pour t'aider, je dirais :

• Vraiment reprendre toute ton analyse de base
• Vraiment reprendre toute ta conception de base
• Prévoir des pointeurs ou des actions éventuelles (du style des callbacks) partout où tu l'identifies, même si pour l'instant tu n'en vois pas l'urgence.

Maintenant, comme l'a dit Franck, il y a TOUJOURS des modifications qui peuvent même être transversales jusqu'à la fin.

Mais plus on en minimise l'impact à l'avance, mieux on se porte..



Enfin, un dernier point : "interminable" est vague.. Tout dépend de l'envergure du projet. PEut-être avais-tu sous-estimé l'envergure ?

Mais dans les développemens de softs professionnels, il n'est pas rare d'atteindre 5 à 10 ans de développement...

[Nebulix]

Pose toi d'abord la question : à quoi servira mon programme ?
Prends le temps, avec un papier et un crayon de répondre précisément.
Ce n'est pas simple, loin de là, mais
tout le reste en découle (relativement) simplement

[Mat.M]

Pose toi d'abord la question : à quoi servira mon programme ?

c'est rare de voir d'excellentes remarques et pertinentes comme cela.

tu n'as pas fait une bonne analyse ni une bonne conception..

entièrement d'accord

Ensuite, je pense que (mais c'est un sentiment personnel, que je ne peux appuyer de statistiques) les langages objets avec leurs classes et héritages, rendent l'évolution d'un logiciel mal défini bien plus lourde et nécessitant beaucoup plus de re-factoring que des langages procéduraux, qui, grâce aux procédures, et donc au découpage fonctionnel et non objet, sont plus à même d'être "évolutifs par morceaux".

je ne suis pas trop d'accord ; la POO ça permet tout de même de conceptualiser et de structurer du code et un projet...
les langages procéduraux c'est bien si tu veux faire de la programmation système ( ça y est va y avoir des mécontents )

[millie]

c'est rare de voir d'excellentes remarques et pertinentes comme cela.

J'ai déjà vu plusieurs projets qui ont bien répondu à cette question au moment où elle a été posée. Cela n'empêche pas d'exploser les budgets au bout de plusieurs années.

Car la vrai question pour compléter serait : A quoi servira mon programme dans 1 ou 5 ans ? Et là, je n'ai malheureusement pas trouvé le moyen de répondre à cette question.
Si vous avez une technique, je suis preneur, mais je constate que les plus gros problèmes sont dû à des besoins qui sont en total contradiction avec les premiers besoins 5 ans auparavant.

[davcha]

Tu réponds à ta propre question, en fait, millie.

Si les nouveaux besoins sont en totale contradiction avec les anciens, le nouveau programme qui doit répondre à ces besoins est un nouveau programme, différent de l'ancien.

[millie]

Si les nouveaux besoins sont en totale contradiction avec les anciens, le nouveau programme qui doit répondre à ces besoins est un nouveau programme, différent de l'ancien.

Je parlais sur un point spécifique (qui peut impacter pas mal de partie), pas sur toute l'application.

Et dans ce cas, je n'ai que rarement vu (en fait jamais ?), que l'on se permettait le luxe de recommencer une autre application qui date d'il y a 5/10 ans pour certaines parties qui changeaient (et donc repasser d'une modification estimée à 1 année homme par exemple à un recommencement qui vaut beaucoup plus).

[souviron34]

Tu réponds à ta propre question, en fait, millie.

Si les nouveaux besoins sont en totale contradiction avec les anciens, le nouveau programme qui doit répondre à ces besoins est un nouveau programme, différent de l'ancien.

j'avais pondu une réponse hier, mais quand j'ai voulu la poster.. "Forums en maintenance"...


Comme millie a répondu, je vais a faire plus courte :


Le problème est ici, mais pas seulement ici, il est (à mon avis de plus en plus) propagé par les "nouvelles" théories, méthodologies, langages, et bref par ce qui est propagé dans l'air du temps de ces dernières années : "tout ce qui a plus de 3 ans est obsolète", "on peut faire bien mieux qu'avant", "ce nouveau langage est LA solution", "ce nouveau (ou pas si nouveau) paradigme est LA solution"...

Je ne peux que bondir quand je lis :

je ne suis pas trop d'accord ; la POO ça permet tout de même de conceptualiser et de structurer du code et un projet...
les langages procéduraux c'est bien si tu veux faire de la programmation système

QUEL QUE SOIT LE PARADIGME, une bonne analyse/conception tient la route, une mauvaise non..

Que ce soit les librairies de maths IMSL, les trucs comme le compilateur gcc, X11, et 250 000 "vieux" programmes, ils tiennent la route PARCE QUE l'analyse et la conception étaient bonnes.


Dire "la POO permet de mieux gérer" est aussi stupide que de dire "les 4*4 sont mieux que les voitures normales".


Et c'est le cas malheureusement de la plupart de l'industrie depuis une 10aine d'années, prise dans un tourbillon de "jeunisme" et de "nouveautés"....

La vision à très courte vue a remplacé une vision pérenne....


Ce qui a l'air de coûter peu car vite fait (avec un IDE, le langage "in", la méthode machin-truc) revient en fait beaucoup plus cher qu'avant car on le recommence tous les 2 ans...


En réponse à la remarque de Mat.M, un exemple de ce que j'entend par ma "pensée" à propos de la POO dans le cadre d'un développement "brouillon" est celui-ci : vu que du coup le développement n'est pas dirigé par la fonctionalité mais par les classes, et leurs héritages, si il s'avère au bout d'un certain temps que l'une des classes "hautes" a été mal conçue, le re-factoring nécessaire sera très lourd... car l'impact "d'hértage" peut être très très lourd.. Encore plus lorsqu'il y a surcharge plus ou moins cachée...
Alors que dans le cas d'un découpage fonctionnel, et d'appels du style procédural, il est plus que probable que seules une ou 2 fonctionalités seront touchées... n'entraînant que peu d'impact sur le reste...

Et ceci ne mentionne même pas l'adoption d'un langage X considéré comme le Nec Plus Ultra aujourdh'ui et qui sera ridiculisé dans 3 ans... Tout en étant "POO"...



Et en ce qui concerne le sujet initial, et la remarque de millie et celle de davcha, je dirais que :

Très souvent, une mauvaise analyse/conception identifie un "besoin" alors que ce n'est qu'une partie d'un besoin . Du coup, on fait un logiciel répondant à ce besoin (surtout avec la volonté d'aller vite), pour s'apercevoir 3 ou 4 ans plus tard que ce n'était qu'une partie... Et là, casse-tête...



La grande force des développements "traditionnels" était l'importance de la phase d'analyse..

Leur grande faiblesse était le temps passé entre l'analyse et les tests...


Ce qui devrait être la force de développements dits agiles est justement de raccourcir ce délai, mais pas au détriment de la phase d'analyse...

Ce qui malheureusement ne semble par être ce que la plupart des gens (et compagnies) font...


Ce n'est pas pour rien que dans les courbes de développements "traditionnels", la phase d'analyse/conception rentrait pour plus de 40%, voire 60%, dans l'estimation du temps....

[davcha]

Sauf que tu ne peux pas toujours identifier un besoin qui n'existera pas avant plusieurs années.

Sinon, l'histoire des classes mal conçues et du concept d'héritage qui t'oblige à tout refactorer... Faudrait être plus précis là-dessus, parce qu'à priori, c'est pas forcément vrai non plus.
T'aurais un exemple concret en tête ?

[souviron34]

j'en ai un mais que je ne peux divulguer.

Pour le reste, ce que j'en dis est justement du bon sens, et, je le rappelle, pour des développements dits brouillons tel que celui du PO..


C'est uniquement justement un point de vue paradigmatique :

vu que une analyse/conception OO est basée sur un découpage en classes, méthodes, attributs, et en sous-classes ou classes héritées, les "actions" étant propres à chaque classe, il y a beaucoup plus de chances dans un tel développement brouillon de s'être pris les pieds dans les fleurs du tapis, et que une correction soit beaucoup plus longue, qu'en sens inverse, où les objets manipulés sont simples, et l'analyse/découpage du soft est fait par fonctionalité...


(admettons par exemple qu'une méthode Affiche s'avère manquer d'un paramètre , et que le logiciel manipule 1500 classes ayant la méthode Affiche, il faudra aller vérifier 1500 fois (et vraisemblablement 1500 fichiers différents). Dans une approche procédurale, la méthode sera peut-être grosse mais ne figurera qu'en un seul endroit, avec de plus très vraisemblablement un découpage en "classes" bien plus restreint)



PS: il est bien entendu qu'ici je ne parle pas de gros développements sérieux, qui, comme je l'ai dit, dans une approche ou une autre seront corrects. Ce dont je parle peuvent être des petits ou moyens devs (voir le PO), ou des plus gros, industriels, qui, pour une des raisons citées plus haut, ont été entachés d'un court-circuit de l'analyse ou de la conception...

[davcha]

Oui, j'ai bien saisi qu'on parlait de développements avec une approche brouillon.

Mais justement, dans ton exemple, si ta méthode Affiche manque un paramètre, et que tu t'en rends compte seulement maintenant, c'est que cette méthode manque d'un paramètre dans des cas bien précis. Et sûrement rarement, sinon tu n'aurais pas 1500 classes dérivant ou implémentant ta méthode affiche. Déjà rien que là, 1500 classes... ouch... On parlait bien de développements de taille petite à moyenne, hein ?

Qu'est-ce qui t'empêcherait de surcharger ta méthode ?

[Nebulix]

Pose toi d'abord la question : à quoi servira mon programme ?
Prends le temps, avec un papier et un crayon de répondre précisément.
Ce n'est pas simple, loin de là, mais
tout le reste en découle (relativement) simplement

Pardonnez moi cette auto citation mais je mets l'accent sur un autre point, trop vite évoqué.
Déterminer le vrai besoin d'un demandeur est une démarche difficile et longue et qui demande un dialogue approfondi avec le demandeur. Mais elle conditionne la réussite d'un projet.
Celà est vrai dans tous les domaines, est connu depuis Socrate et très souvent négligé.
Si vous n'êtes pas convaincus, allez voir sur les forums de dépannage comment sont formulées les demandes d'aide.

[souviron34]

Oui, j'ai bien saisi qu'on parlait de développements avec une approche brouillon.

Mais justement, dans ton exemple, si ta méthode Affiche manque un paramètre, et que tu t'en rends compte seulement maintenant, c'est que cette méthode manque d'un paramètre dans des cas bien précis. Et sûrement rarement, sinon tu n'aurais pas 1500 classes dérivant ou implémentant ta méthode affiche. Déjà rien que là, 1500 classes... ouch... On parlait bien de développements de taille petite à moyenne, hein ?

Qu'est-ce qui t'empêcherait de surcharger ta méthode ?

Non, comme on l' a dit dès le début, si c'est un besoin qui n'avait pas été assez clairement identifié dès le début, cela peut être un paramètre général...

M'enfin, comme je le dis, c'est une impression, mais, au vu des remarques que je vois ici et là, et des modélisations que je vois dans le forum Conception ou Méthodes, etc etc, je trouve personellement que c'est le cas....

Pardonnez moi cette auto citation mais je mets l'accent sur un autre point, trop vite évoqué.
Déterminer le vrai besoin d'un demandeur est une démarche difficile et longue et qui demande un dialogue approfondi avec le demandeur. Mais elle conditionne la réussite d'un projet.
Celà est vrai dans tous les domaines, est connu depuis Socrate et très souvent négligé.
Si vous n'êtes pas convaincus, allez voir sur les forums de dépannage comment sont formulées les demandes d'aide.

Absolument...

Il suffit de se reporter aux divers débats et threads ici-même, que ce soit à propos des écueils à éviter, de "qu'est-ce qu'un bon projet", et autres....

[davcha]

En fait, j'ai un peu l'impression aussi que la question pourrait être reformulée comme suit :

"Comment faire du bon avec du mauvais ?"

Parce que, globalement, si la conception est mauvaise au début (pour cause d'incompétence ou pour cause de mauvaise identification des besoins) il faudra très probablement casser pas mal de choses (si on a le temps/budget) ou faire beaucoup de bidouillage.

[apieum]

Pose toi d'abord la question : à quoi servira mon programme ?

Je ne suis pas vraiment d'accord.

A mon avis la première question à se poser est à QUI sert mon programme ?

Et j'utilise bien le présent, car on a une meilleure visibilité de son projet. (on fait comme si le programme avait déjà été développé)

La vision du produit ou du projet est un des facteurs d'échecs les plus importants et qui peut induire des effets tunnels.

Dans le cas d'un projet en cours, cela peut-être nécessaire de commencer par se recentrer sur les objectifs à atteindre et donc de revoir sa vision du projet ou du produit.
Je crois qu'il n'est jamais trop tard pour le faire. (en excluant les délais de livraison, dans le sens ou c'est faisable à n'importe quel moment du projet si on ne l'a pas fait avant)

J'aime beaucoup l'exercice de l'Elevator Statement (Geoffroy Moore) qui consiste à être capable de donner une vision complète de son projet en 2 min.

Un modèle de réponse est :

L'utilisateur....
... avait un besoin ...
... le produit que nous avons développé ( spécifier le type de produit)....
... y répond de telle façon ...
... contrairement à / par rapport à l'ancienne solution ...
... donc se positionne de telle façon.

Un exemple :
kisitomomotene souhaitait sortir d'un cycle de développement interminable,
une discussion sur le forum développez et les réponses que nous lui avons donné lui a permis de :
- se recentrer sur les objectifs de son projet
- récupérer une partie du travail déjà accompli
- redémarrer son projet avec une meilleure analyse
- terminer son projet avec un peu de retard mais avec la satisfaction de son client
au lieu de continuer son développement comme il l'avait commencé et terminer son projet avec beaucoup de retard ou ne pas le terminer car son client aurait renoncé.
La solution que nous lui avons proposé consiste à :
- définir correctement les utilisateurs de son programme
- définir qui participe à son projet (parties prenantes)
- définir quel est le contexte, le périmètre, les contraintes actuels et futurs de son projet
- définir quel est l'objectif des utilisateurs du programme
- définir à quoi sert son programme (quels besoins <-> quelles fonctionnalités)
- prioriser ces besoins ou fonctionnalités (important)
- à rédiger des tests d'acceptance et unitaires avant de reprendre son développement (BDD et TDD)
- à exécuter ces tests pour valider les parties déjà réaliser qui sont utiles et supprimer celles qui ne servent à rien
- continuer son développement en privilégiant les fonctionnalités qui apportent une réelle valeur ajoutée aux utilisateurs et en fournissant à intervalles réguliers (les plus courts possible) des livrables "inachevées" mais fonctionnels.


Parfois aussi cela peut aider et être motivant d'avoir un tableau avec "ce qui a été réalisé" et "ce qui reste à faire".
Le principe de GTD (Getting Things Done) par exemple se base sur le fait qu'il faut sortir de sa tête tout ce qu'il y a faire ou tout ce qui peut nous encombrer pour se concentrer uniquement sur ce que l'on fait.
Je te conseillerai donc de prendre le temps de rédiger cette "vision" comme le disait Nebulix et de développer à partir des fonctionnalités attendues (comme il a été dit par d'autres).

Je reconnais que c'est plus dur à mettre en pratique.

[Nebulix]

La façon la plus simple me parait celle proposée par Kaeru No Uta, dans un autre débat .
Elle tient en une phrase :
Commencer par le manuel utilisateur

[apieum]

Personnellement, je ne suis pas pour commencer par rédiger un manuel utilisateur, car il peut arriver beaucoup trop de changements au cours d'un développement.

Surtout dans le cas d'un développement brouillon qu'on veut reprendre en main, je ne pense pas que ce soit ce qu'il y a faire.

Je n'ai peut-être pas été trop clair pour les tests.

Bien évidemment, il ne faut pas rédiger des tests pour ce qui a été fait car si on doit le refactorer il va falloir refactorer les tests avec.

Il vaut mieux écrire des tests pour ce que l'on veut faire en tenant compte (si cela ne nous encombre pas) de ce qui a été fait.

Ensuite en exécutant les tests, on fait remonter ce qui ne va pas afin de le corriger au fur et mesure.

Avec un peu d'expérience, il est possible d'orienter les tests pour faire les corrections en fonction de la priorité des fonctionnalités.

Mais avant cela il faut savoir ce qui est vraiment prioritaire (infos que ne donne pas un manuel utilisateur) et donc avoir au moins un document de vision.

J'aime beaucoup et recommande cet article de JC Grosjean sur le sujet. (voir aussi le plan de projet dans les liens)

Je cite : "... court, simple et facile à lire ..."

Ce n'est pas LA solution mais c'en est une.