Discussion :

[ravakhasina]

Bonjour,

Je vais écrire mon mémoire de fin d'études sur : "Pourquoi un projet informatique peut tendre à devenir une usine à gaz et comment l'éviter".

Je me suis posée cette question durant mon stage où j'ai dû utiliser des applications (frameworks java) complexes et lourdes, bien évidemment, j'étais obligée de m'adapter et que de toute façon, ce n'est pas à moi de refaire toute l'architecture.

Je ne suis pas experte mais j'opte toujours pour la simplicité tant que c'est possible.

J'aimerais avoir votre avis sur ces 2 questions et si possible des exemples.

J'espère que ma question n'est pas mal placée dans cette branche ...

Merci d'avance.

[william44290]

a) un cahier des charges est en général prescrit pour encadrer un dev.

b) la simplicité est souvent source d'impasses dont la conséquence s'appelle souvent une usine à gaz

c) vous parler de 2 questions puis d'une. Bref ce qui ce conçois bien s'exprime clairement. C'est aussi un élément de réponse.

[Patriarch24]

un cahier des charges est en général prescrit pour encadrer un dev.

C'est justement une des principales causes d'échec : un cahier des charges super détaillé -> suivre un plan. En matière d'architecture, c'est catastrophique.

la simplicité est souvent source d'impasses dont la conséquence s'appelle souvent une usine à gaz

Là encore je ne suis absolument pas d'accord : plus la conception reste simple, plus tu as de chances de pouvoir modifier ton application sans qu'elle devienne une usine à gaz (ça tombe sous le sens) !


Pour t'aider, je te propose de te documenter sur les méthodes classiques de développement (cascade, cycle en V), puis sur les méthodes agiles. Tu verras notamment que l'architecture d'une application n'est pas figée dans ces dernières : la conséquence, c'est que ton application est bancale, et au fur et à mesure devient une usine à gaz !

Pour conclure, je dirai que pour éviter qu'une application ne devienne une usine à gaz, il faut la refactorer en permanence !

[montesq]

b) la simplicité est souvent source d'impasses dont la conséquence s'appelle souvent une usine à gaz

Attention, simplicité ne veut pas dire "première chose qui vient à l'esprit". C'est ça le plus dur! Il faut faire un design simple (en terme de résultat) mais qui va pouvoir/devoir s'adapter avec le temps, ce qui en terme de démarche intellectuelle est tout sauf ... simple!
Cf le précepte KISS: Keep it simple and smart, à ne pas confondre avec le précepte KISS: Keep it, simple and ... stupid

[william44290]

Un cahier des charges n'est pas forcément détaillé.

Faire simple pour pouvoir modifier, il y là quelque chose d'incongrus pourquoi faire puis refaire ?

Il me semble qu'entre avoir un cahier des charges trop détaillé ou une pseudo méthode agile. Il existe un juste milieux.

L'imagination est par définition sans limite, se refuser à l'encadrer c'est à coup sûre s'engager sur une pente dangereuse.

Faire preuve de nuances et d'ouverture d'esprit évite bien souvent les malentendus.

[montesq]

Faire simple pour pouvoir modifier, il y là quelque chose d'incongrus pourquoi faire puis refaire ?

Parce que les besoins à l'instant T ne sont pas les besoins à l'instant T+...
Donc rien ne sert à l'instant T de tout développer si à l'instant T+... on se rend compte que le besoin a changé et que la fonctionnalité est remplacée par une autre...

[william44290]

Désolé d'insister mais d'expérience j'évite régulièrement d'encoder des choses simples.

Je préfère coder flexible, pour exemples :

a) j'ai besoin d'une série de valeur -> j'ajoute une table

b) j'ai besoin d'un bouton > j'ajoute un conteneur et un bouton

c) j'ai besoin d'une fonctionnalité > je factorise et je crée une class/interface

etc...

[souviron34]

Bonjour,

Je vais écrire mon mémoire de fin d'études sur : "Pourquoi un projet informatique peut tendre à devenir une usine à gaz et comment l'éviter".

Je me suis posée cette question durant mon stage où j'ai dû utiliser des applications (frameworks java) complexes et lourdes, bien évidemment, j'étais obligée de m'adapter et que de toute façon, ce n'est pas à moi de refaire toute l'architecture.

Je ne suis pas experte mais j'opte toujours pour la simplicité tant que c'est possible.

J'aimerais avoir votre avis sur ces 2 questions et si possible des exemples.

J'espère que ma question n'est pas mal placée dans cette branche ...

Merci d'avance.

Sur le pourquoi, c'est assez simple.. Il faut lire les docs servant d'introduction aux diverses méthodologies agiles...

En général, le pourquoi se résume à :

• Des délais absurdes
• Des gens peu formés
• Une non-intervention des utilisateurs dans le processus d'analyse/conception
• Donc une mauvaise analyse et conception
• Des tests effectués uniquement à la fin
• Des grosses équipes (sous le prétexte de "10 font 10 fois le travail de 1")
• Des décisions prises soit par des geeks soit par des gestionnaires
• Et donc une adhérence aux modes, qu'elles soient technologiques ou de gestion

Quant à la question de "simplicité", comme le dit le vieil adage "le bon sens est la chose du monde la moins partagée"...

En conséquene, "pourquoi faire simple alors qu'on pourrait faire compliqué" est l'état d'esprit le plus répandu dans la profession...

Car, pour faire simple (et donc "beau", et donc surtout "sûr" et maintenable), cela demande de la réflexion, de la généralisation, de la réflexion sur les algorithmes, etc etc, ce qui n'est ni l'état d'esprit général technique ("on code et ça marche"), ni l'état d'esprit des gestionnaires ("je veux une solution dans 1 semaine")...

Pour atteindre ce but, il faut des chefs de projets intelligents, ayant des c.uilles, c'est à dire simultanément dominant leur sujet et capable d'imposer des limites et à l'équipe technique et à la hiérarchie au dessus (dire "non")...

Très très difficile à trouver....

Désolé d'insister mais d'expérience j'évite régulièrement d'encoder des choses simples.

Je préfère coder flexible, pour exemples :

a) j'ai besoin d'une série de valeur -> j'ajoute une table

b) j'ai besoin d'un bouton > j'ajoute un conteneur et un bouton

c) j'ai besoin d'une fonctionnalité > je factorise et je crée une class/interface

etc...

Et quand on voit les exemples que tu donnes, on ne parle pas des mêmes choses... Tes exemples sont liés à une IHM, et à un langage/paradigme...


La question posée est générale...

Et tu tombes dans les travers que je dénonce plus haut..

[william44290]

et toi tu tombes dans quel travers ?

[Patriarch24]

+1 souviron34.

pseudo méthode agile

Tu entends quoi par là ?

[william44290]

Désolé je ne souhaite pas polémiquer, je souhaitais uniquement réagir sur le coté "je fais simple".

Je ne crois pas que la simplicité soit la panacée universelle.

Je ne pense pas que les informaticiens soient des idiots inconséquents et forcément enclin à coder des trucs compliqués.

IL me semble au contraire qu'un effort important est consacré pour rationaliser la pratique.

Je ne prétends pas savoir comment faire pour éviter qu'un projet devienne une usine à gaz.

Dans ma pratique, j'ai acquis la conviction qu'il fallait plutôt coder "flexide" que "simple".

[souviron34]

Dans ma pratique, j'ai acquis la conviction qu'il fallait plutôt coder "flexide" que "simple".

D'une part l'un n'empêche pas l'autre...

Mais surtout, comme on l'a dit au dessus, simple ne veut pas dire simpliste...


J'ai eu (il y a longtemps ) un prof de maths qui disait "plus une théorie est simple, plus elle est belle"..

Il en va de même de la conception.. (et de la réalisation)


Dans le cadre des logiciels en général, c'est parfaitement vrai..




Une conception simple (dans le sens où on l'entend) sera (par "définition", quasiment) flexible..

Simplement, par exemple au lieu de mettre tout un tas de classes et donc de méthodes (quitte à en avoir factorisé un certain nombre) peut-ête qu'une réflexion plus poussée aurait amené à une seule grande classe...

Pareil pour les modlisations des interactions, pour les liens avec les bases de données, pour la définition des données, des architectures, etc etc...


Or, la plus grande cause d'échec des logiciels est, outre l'inadéquation entre ce qui est proposé et le besoin, l'impossibilité ou l'immense difficulté à maintenir...

Une conception "simple" permet à un intervenant autre que l'auteur de "s'approprier" la structure (globale, mais aussi du code) rapidement, et par conséquent améliore grandement la maintenabilité... Et donc la vie du logiciel, et (dans beaucoup de cas) de l'entreprise le fabriquant...



Ce qui signifie (là encore un rappel de ce qui a été dit plus haut) que "faire simple" est tout le contraire d'être un acte simple...

C'est bien pour ça que il y a des "usines à gaz"....

[william44290]

J'ai du mal a comprendre votre démarche :

En l'occurrence, une question est posée et vous êtes plus intéressé à réagir sur une réaction que sur le sujet lui-même.

IL serait peut-être plus SIMPLE d'argumenter sur le sujet lui-même, non

Je ne sais pas, c'est juste une question de correction.

[souviron34]

J'ai du mal a comprendre votre démarche :

En l'occurrence, une question est posée et vous êtes plus intéressé à réagir sur une réaction que sur le sujet lui-même.

IL serait peut-être plus SIMPLE d'argumenter sur le sujet lui-même, non

Je ne sais pas, c'est juste une question de correction.

Ben, que ce soit mon post original ou le post précédent répond au PO, non ?

Sa deuxième question était bien à propos de la simplicité , non ?


J'ai fourni des arguments..


Et d'autre part, dans une conversation, si nous ne sommes pas d'accord, nous pouvons exposer pourquoi nous ne sommes pas d'accord, non ?

[montesq]

Voici un exemple très concret de la solution simple et non flexible que j'ai rencontré récemment :
Nous avons fait développer une application il y a 2 ans avec des contraintes de temps très importantes. Il n'était prévu que 2 sortes d'utilisateurs (=profils). A l'époque, la sécurité au niveau des pages a donc été géré directement au niveau des profils, càd "si l'utilisateur a le profil ... alors il peut accéder à cette page" ou encore "si l'utilisateur a le profil ... on affiche le bouton 'modifier'".

Aujourd'hui, le client souhaite ajouter un nouveau profil avec des droits différents et donc pour satisfaire ce besoin, il faut repasser sur tous les écrans (soit une 50aine) pour ajuster les droits.

Si dès le début, nous avions établi la sécurité en terme de droits plutôt qu'en terme de profils (1 profil est associé à n droits), alors nous n'aurions eu aucun problème pour rajouter facilement de nouveaux profils.
Cette dernière solution est/aurait été simple ET élégante, encore faut-il y avoir pensé au moment opportun...

[ravakhasina]

Merci à tous pour vos réponses/réactions, qui m'ont amené à regarder un peu plus loin que le bout de mon nez jusqu'à reformuler mon sujet de mémoire. J'hésite beaucoup car ce mémoire compte pour la moitié des UE pour obtenir mon master et donc je souhaite que mon sujet accroche. Je l'ai donc modifié ainsi : "Pourquoi adopter une démarche qualité relative à l'usage des technologies dans un projet informatique et comment la réussir ?"
Après avoir validé avec mon tuteur, j'ai eu les critiques de mes collègues comme: "qualité ne se marie pas avec usage des technologies".
Petit résumé de pourquoi j'ai reformulé : simplicité toute seule ne peut pas garantir qu'un projet ne devienne une usine à gaz. Il faut aussi, prendre en compte, la fiabilité, la performance, la portabilité, etc... Dans le terme "usine à gaz" je me suis dite, et pourquoi pas parler de qualité dans le sens technique? dans l'usage des technologies surtout.

PS: désolée si j'ai changé le sujet de cette discussion ...