Discussion :

[dragonjoker59]

Moi je pense que le code pourri n'est pas un frein pour qu'une entrerprise se développe.
En disant cela, je pense à Autodesk et 3D Studio Max. Ayant eu à développer un plugin d'export, je me suis rendu compte qu'il est codé avec les pieds. Un bel exemple : la classe Animatable qui contient les déclarations de toutes les fonctions de tous les objects de 3DSMax, ainsi que toutes les variables de tous les objets de 3DSMax, ce qui est magique, c'est que chaque objet (même les vertex et les faces) étend cette classe, et on en arrive a un vertex qui doit bien peser dans les 4Ko dans la RAM...
Non, décidément, le code pourri n'est pas un frein a la bien portance d'une entreprise (et c'est malheureux)...

[sneb5757]

De ma petite expérience je dirai oui et non.

Je ne travaille pas dans une entreprise commerciale mais dans une administration. Cette administration possède un intranet assez conséquent. Et il faut bien le dire, le code n'est pas top du tout. Peu docummenté, foullie c'est pas forcémment un plaisir à lire, de plus elle n'est absolument pas modulaire. Par exemple, il n'y a aucune fonction d'abstraction du SGBD , donc le jour de changement de SGBD bonjour les dégats. Ce n'est qu'un exemple.

L'Intranet fonctionne sans problème, le code "sale" n'est pas un problème pour l'utilisateur. Par contre pour le seul et unique développeur ( qui est arrivé recemment ) c'est pas la joie. Il passe son temps à nettoyer le code. A chaque fois qu'un utilisateur demande une amélioration c'est la croix et la bannière pour aller faire une modification d'un champs de formulaire dans une application développée par 3 stagiaires différents. Résultat l'intranet stagne et il est clair et net que si tout le service informatique de l'administration cette application finira à la corbeille (developpé depuis 4 ans ). Mais bon on ne peut pas non plus dire que le SI de l'administration puisque cette application fonctionne malgré tout trés bien.

Donc je pense qu'un jour ou l'autre avoir un code sale se paie surtout pour ce genre d'application.

[rakakabe]

Moi je suis aussi deja tombe sur des codes sales programmer par les professionnel du metier ayant plusieurs annees d'experience. Mais c'est fait aussi express. Quelques fois je le fais aussi. Pour que mon entreprise soit attacher a moi. Et ainsi meme en quittant l'entreprise, ils auront recours a vous.
Et voila une raison

Amen mon frere . Je vais vous raconter l'histoire de 2 étudiants venant de deux écoles différentes qui travaillent maintenant dans une boite appelée REALITE. Souvent, ces étudiants fréquentent les deux écoles pour parfaire leurs études et avoir deux beaux diplômes, afin d'être embauchés par la société :

1. l'un qui vient de l'ecole des artistes (donc un idéaliste), qui code bien pour aider ses futurs prochains remplaçants (qui iront plus tard lui casser la gueule à cause de ses codes sales - parce c'est pas eux qui l'on fait). Que Dieu lui bénisse et qu'il ne part pas bosser dans les SSII soucieux "de leurs clients" (je veux dire par là : temps de dev minimum = peu de pactoles deboursés et produit dispo de suite pour le client + profit max pour la boite). En général, ce gars est jugé par ses collègues codeurs qui iront lui féliciter de ses travaux d'orfèvres (il serait ainsi satisfait bien que le projet ai pris du temps à rendre fou les clients (utilisateurs finaux ou chef de projet ou ...));
   
2. et l'autre qui vient de l'ecole des "je veux gagner mon pain quotidien moâ" (les réalistes). Son cher monsieur chef le couvre d'éloges car il est super productif , dans le temps et donc il est très compétent (donc c'est un geek ).
   Le jugement vient souvent ici de son supérieur et il bosse en solo dans la majorité des cas.

Bon j'arrète mon histoire. Pour te répondre SlashEne, je coirs que tout dépend de la politique de la société (SSII ou non) en la matière (vision court ou long terme des choses), de ton chef de projet (qui est un mec dans le genre de ce smiley ), et de tes collègues (qui n'existent pas souvent).

a+ les gars,

NB : ah ! j'oubliais, j'appartiens à ces deux écoles selon la boite qui m'emploie et je suis sûr que plusieurs sont avec moi.

[deadalnix]

NB : ah ! j'oubliais, j'appartiens à ces deux écoles selon la boite qui m'emploie et je suis sûr que plusieurs sont avec moi.

Ça se pourrait Il faut noter que ce n'est pas dans l'intérêt de la boite, mais que celle-ci ne s'en rend pas forcement compte et te pousse a faire des choses sales.

[SlashEne]

Je me suis intéressé a l'extreme programming, je ne l'ai jamais mise en pratique, mais j'ai lu un bouquin intéressant dessus.

J'ai été vraiment persuadé par son efficacité, et j'espère pouvoir travailler dans une boite qui met en place toute ces pratiques.
Toutes ces problématiques de motivation, documentation, maintenance paraisse se résoudre.

L'une de leur philosophie est de faire la chose la plus simple qui puisse marcher quitte a refactorisé souvent.
A mon sens c'est le juste milieu entre un code propre (puisqu'il sera repensé en fonction des besoins), et le faible temps de développement.

Personne n'a deja vu l'extrem programming pratiqué de A à Z dans son entreprise ?

[slevy]

L'extreme programming est rarement appliqué de A à Z. Le but je pense est de choisir parmi les techniques XP celles qui s'adaptent le mieux à un contexte de projet.

Ce qui me semble très important, c'est effectivement de "faire la chose la plus simple qui puisse marcher", de ne pas faire d'"over-engineering".
Par exemple, écrire du code propre (modules découplés, forte cohésion, utilisation systématique d'interfaces, encapsulation etc...) ne veut pas dire utiliser des design pattern à tort et à travers. Les cas d'utilisation des design pattern sont limités, surtout depuis que les frameworks "maison" se font plus rares grâce à l'apparition de frameworks open source de qualité (Spring, Hibernate...) qui eux-même utilisent massivement ces design pattern.

[Faiche]

J'apporte mon grain de sel à la conversation :

Il y a quelques temps, je travaillais dans une très petite boite, dirigée par (un connard) quelqu'un qui ne connaissait rien à l'informatique et qui de temps en temps, en se levant le matin, se cognait la tete et changeait totalement l'idée du projet sur lequel je travaillais.

D'abord, je devais fixer à la va vite un programme. Puis j'ai du ajouter une "fonctionnalité" sur ce même programme, qui était, en terme de code, plus importante que le programme lui même. Puis il a fallu que ce même programme, qui était conçu pour tourner à la main, avec IHM et compagnie, devienne un client dans une archi clients/server, genre mode daemon. A chaque fois, il ne fallait surtout pas revenir en arrière, et il fallait que tout soit fait pour la veille. J'ai échappé de peu au changement de langage en cours de route.

Je vous raconte pas la tronche de ce logiciel.

Tout ça pour dire que, si sur la partie fonctionnelle il n'y a que des glands, le code sera tout aussi dégeu que si c'est un élève de Seconde qui développe le logiciel.

[Garulfo]

J'apporte mon grain de sel à la conversation :

Il y a quelques temps, je travaillais dans une très petite boite, dirigée par (un connard) quelqu'un qui ne connaissait rien à l'informatique et qui de temps en temps, en se levant le matin, se cognait la tete et changeait totalement l'idée du projet sur lequel je travaillais.

D'abord, je devais fixer à la va vite un programme. Puis j'ai du ajouter une "fonctionnalité" sur ce même programme, qui était, en terme de code, plus importante que le programme lui même. Puis il a fallu que ce même programme, qui était conçu pour tourner à la main, avec IHM et compagnie, devienne un client dans une archi clients/server, genre mode daemon. A chaque fois, il ne fallait surtout pas revenir en arrière, et il fallait que tout soit fait pour la veille. J'ai échappé de peu au changement de langage en cours de route.

Je vous raconte pas la tronche de ce logiciel.

Tout ça pour dire que, si sur la partie fonctionnelle il n'y a que des glands, le code sera tout aussi dégeu que si c'est un élève de Seconde qui développe le logiciel.

Sauf que ton exemple, est un exemple de logiciel mal spécifié et mal conçu. C'est pour ce genre de chose (modification des besoins) qu'on doit prendre tant de précautions en amont.

Attention, je ne t'accuse pas toi de quoi que ce soit, mais je dis juste que ce qui t'est arrivé arrive régulièrement dans tous les projets du monde. Il y a des raisons (bonnes ou mauvaises d'ailleurs) pour lesquelles ça arrive.

D'où l'importance d'une analyse correcte du domaine et des besoins, d'une spécification abstraite et bien faite et d'une conception de qualité. Certains parlent de « surconcevoir » comme d'un problème, mais en général, ça n'est jamais assez. Et il est plus aisé de retirer des indirections inutiles d'une conception trop modulaire (par exemple) que de rendre modulaire ce qui ne l'est pas.

Jeune analyse/concepteur, faite un effort. Car si vous prenez les mauvais travers, vous donnerez toujours les mêmes logiciels de qualité incroyablement faible qu'on voit dans l'industrie. Et je vous assure qu'en général, c'est merdique.

[el_slapper]

Mouais, sauf qu'effectivement quand on part sur l'idée d'un truc très simple fait pour dépanner, et qu'il finit en mégamonstre qui passe même l'aspirateur, je ne vois pas comment le développeur peut anticiper une structure qui gère tout ça. Surtout sous pression de délai.....

Quand on a à faire à des demandeurs sérieux, one peut faire des choses sérieuses. Quand la demande est farfelue, on s'adapte. On peut chercher à refactoriser l'ensemble à chaque fois, mais ça prend du temps.

[SlashEne]

D'où l'importance d'une analyse correcte du domaine et des besoins, d'une spécification abstraite et bien faite et d'une conception de qualité. Certains parlent de « surconcevoir » comme d'un problème, mais en général, ça n'est jamais assez.

Les livres sur la programmation agile (surtout XP enfet je dirais) parte d'une idée simple (Steve MCConnel fait la même remarque dans l'un de ses bouquin sur Software estimation il me semble) :
Le moment ou les clients et les concepteurs en connaissent le moins sur un projet, c'est precisement au début.
Pour moi c'est un argument clé en faveur de la pratique : "ne pas faire trop de conception ni de spécification dès le début", puisque ceux ci s'affineront au fur et à mesure du projet.
D'ou l'intérêt du "Faire le plus simple qui puisse marcher".

Quand on a à faire à des demandeurs sérieux, one peut faire des choses sérieuses. Quand la demande est farfelue, on s'adapte. On peut chercher à refactoriser l'ensemble à chaque fois, mais ça prend du temps.

Ca signifie donc que ce qu'on a trop tendance à appeller "over engenering", peut être utile si l'on a des demandeurs qui savent précisement ce qu'ils veulent des le début (j'ai cru comprendre que ça courait pas trop les rue).

Mouais, sauf qu'effectivement quand on part sur l'idée d'un truc très simple fait pour dépanner, et qu'il finit en mégamonstre qui passe même l'aspirateur,

A mon avis dans ces cas la, la refactorisation est essentiel même si sa prend du temps, un code qui devient trop lourd car il n'est pas refactorisé par faute de temps... ca peut tuer un développeur !

Personnellement, j'ai l'impression que plus l'on se déchire à coder vite, plus l'environnement nous impose de coder vite (j'entends par "coder vite" l'aspect du bout de code dégueux).

C'est un peut comme si le mantra du management était : "si vous pouvez faire 100 000 ligne de code en 2 mois, vous pouvez le faire en 2 mois - 1 jours".
Pas étonnant que sa puisse générer du turn over, et de la frustration...

A l'exception du manager qui connait parfaitement l'industrie logiciel, je pense que c'est un peu au développeur de parler de ces problèmes de code puant à "ceux du dessus".

Ca me parait plutôt un manque de communication des développeurs aux management qu'un réel coup de fouet pour aller plus vite.

Je ne pense pas qu'ici, il y ai beaucoup de développeur qui pense que coder proprement (par coder proprement j'entends simplement un ensemble de classe que l'on pourrait faire comprendre à quelqu'un sans problème, et dont on a de la fierté) fait perdre du temps.

[Garulfo]

Mouais, sauf qu'effectivement quand on part sur l'idée d'un truc très simple fait pour dépanner, et qu'il finit en mégamonstre qui passe même l'aspirateur, je ne vois pas comment le développeur peut anticiper une structure qui gère tout ça. Surtout sous pression de délai.....

Mais on ne parle pas d'un projet industriel là ?

Quand on a à faire à des demandeurs sérieux, one peut faire des choses sérieuses. Quand la demande est farfelue, on s'adapte. On peut chercher à refactoriser l'ensemble à chaque fois, mais ça prend du temps.

Tu parles d'un jouet. Le forum ici est pour les professionnels a priori. Je me plaçais donc dans le cadre d'un tel projet. Pas d'un truc pour s'amuser ou pour dépanner. De toute façon, faire « un truc pour dépanner » sous-entend qu'il y a eu problème avant.

Donc, dans le cadre d'un vrai projet de taille normale, les gens font de la sous-spéc et de la sous-conception. Dans les projets jouets que j'ai déjà vu, c'est aussi majoritairement le cas. Exceptionnellement, il y a des gens qui font de la sur-conception. C'est très rare et c'est qu'ils conçoivent mal de toute façon. Ce qui renforce l'idée qu'un informaticien devrait apprendre à faire du vrai travail. Dans aucune autre discipline similaire à l'informatique, on ne fait de travail aussi dégueulasse. Et c'est principalement dû au manque de sérieux de beaucoup de professionnel et aussi, reconnaissons-le, à la jeunesse du domaine.

[el_slapper]

@Garulfo, merci d'insulter mon professionalisme.

J'ai la chance, aujourd'hui, de bosser pour un client qui me demande de coder "propre". C'est aussi parcequ'il se trimballe un vieux nanard Cobol de 30 ans d'âge, écrit comme si c'était de l'assembleur, et que ses couts de maintenance explosent. Il a compris.

Ca n'a pas toujours été le cas. J'ai connu des contextes ou les décisions étaient prises à très haut niveau, avec des projets de refonte(pour faire du propre à la place du sale) foutus en l'air après avoir consommé 1500 jours(1 tiers du projet) parcequ'il fallait faire des économies et "un cadeau aux actionnaires"(le projet était rentable en moins de 2 ans). Dans ces contextes-là, tu as beau être un profesionnel, tu fais ce que tu peux. Tu fais au mieux, mais "au mieux" quand on a pas le temps de penser à tout, c'est rarement aussi propre que l'on aurait souhaité.

Sans compter qu'il peut y avoir des urgences : un code à faire dans la journée pour faire passer une privatisation qui va prendre 2 jours de retard sinon(et le ministre qui a la presse aux fesses ne veux rien entendre), parceque personne avant n'a vu que la volumétrie exceptionelle va faire sauter un compteur clef.....une fois la privat passée(et la presse passée à autre chose), tu demandes à refaier "propre", et on t'explique gentiment que tu as raison, sauf que le budget n'est pas disponible.....

Je suis un professionel, mais je vis dans le monde réel. Je fais au mieux, en fonction des contraintes du contexte et des moyens dont je dispose. Ici, maintenant, ça va : on me juge aussi sur la propreté de mon boulot. Ailleurs, on m'a déjà explicitement demandé de mettre des numéros de compte en dur dans un code.....alors soit je crée une table de paramétrage pour laquelle je passe outre mes ordres, je viole les règles locales d'urbanisme et j'explose ma charge, soit je fais de la merde. Comme j'ai femme et enfant à nourrir, je reste dans mon budget et je suis les instructions(non sans protester pour la forme, mais c'est tout).

[Garulfo]

@Garulfo, merci d'insulter mon professionalisme.[...]

Je n'ai jamais fait ça.
Tu as dit

Mouais, sauf qu'effectivement quand on part sur l'idée d'un truc très simple fait pour dépanner, et qu'il finit en mégamonstre qui passe même l'aspirateur…

d'où le fait que je dit que je ne parlais ici que de projets qui font plus que de dépanner.

Je suis désolé de t'avoir laissé entendre le contraire Je ne te connais pas et n'oserais certainement pas critiquer ce que tu fais.

Maintenant je t'assure que les études montrent que les problèmes naissent d'un manque de spécification correcte. Plus rarement, c'est la cause unique d'une mauvaise conception, mais en générale celle-ci provient d'une manque dans l'analyse des besoins. Finalement, les problèmes dues au code sont négligeables (dans le sens, peu couteux). Ce qui fait que la « surconception » est statistiquement rare et plus facile corrigée que l'erreur contraire. D'où ma préférence pour qqun qui en fait trop: c'est souvent aisé à lui montrer où s'arrêter. Le contraire est faux.

Finalement, il ne faut pas confondre « faire trop de conception » et « faire une mauvaise conception (détails trop avancée, architecture surdimensionnée etc. » Si la conception induit des problèmes c'est quelle est mauvaise. Si elle possède des avantages mais inintéressant pour la taille du projet (c'est donc ce dont tu voulais parler il me semble) alors elle peut quand même être utilisée, voir réduite (et en général assez facilement, puisque c'est une bonne conception ^_^)

En tout cas… encore une fois désolé de t'avoir vexé.

[SlashEne]

C'est un peu ce qui se passe trop souvent d'après ce que j'ai compris

[souviron34]

Maintenant je t'assure que les études montrent que les problèmes naissent d'un manque de spécification correcte.

D'où l'importance d'une étude basée sur l'ergonomie et l'utilisateur dès le départ..

Ne pas se fier aux papiers divers, et baser sa pré-conception sur une discussion et spécification serrée avec l'utilisateur..

[el_slapper]

D'où l'importance d'une étude basée sur l'ergonomie et l'utilisateur dès le départ..

Ne pas se fier aux papiers divers, et baser sa pré-conception sur une discussion et spécification serrée avec l'utilisateur..

Je suis bien d'accord, mais l'utilisateur final lui-même n'est pas toujours sur de ce qu'il veut. On peut organiser des réunions, faire valider des papiers, et le jour ou il a le "vrai" sous la main, en fait, rien ne va......C'est mieux que d'autres méthodes, mais ça n'est pas la panaçée.

@Garulfo : quand c'est le big boss lui-même qui te demande une "toutouille" rapide pour présenter un bilan "amélioré" suivant l'interlocuteur, c'est peut-être un jeu - mais le contexte est mortellement professionel(vécu par mon paternel). D'ou, peut-être, une réaction excessive de ma part......



Quand à rejeter toute la responsabilité sur les specs, ça n'est pas toujours exact. Parfois, nous ne sommes pas parfaits non plus.....même dans de bonnes conditions.

[souviron34]

Je suis bien d'accord, mais l'utilisateur final lui-même n'est pas toujours sur de ce qu'il veut. On peut organiser des réunions, faire valider des papiers, et le jour ou il a le "vrai" sous la main, en fait, rien ne va......C'est mieux que d'autres méthodes, mais ça n'est pas la panaçée.
.

C'est vrai, mais les techniques ergonomiques, ou plutôt User-Centered, te permettent 1) de mettre en évidence des "automatismes" nécessaires à l'informatique mais non analysées par les utilsateurs (car inconscientes), 2) d'identifier le vrai flux pratique (et non théorique) du cheminement des actions et de la pensée et des besoins, et 3) d'identifier directement les points de "fluctuations" possibles, et par conséquent les points où la programmation devra être souple et ouverte.

[Garulfo]

@Garulfo : quand c'est le big boss lui-même qui te demande une "toutouille" rapide pour présenter un bilan "amélioré" suivant l'interlocuteur, c'est peut-être un jeu - mais le contexte est mortellement professionel(vécu par mon paternel). D'ou, peut-être, une réaction excessive de ma part......

J'aurais dû être plus précis dans mon texte. Je m'en excuse encore une fois

En général d'ailleurs, le problème vient des commerciaux qui considèrent que la qualité du produit n'a pas besoin de tous ces « artifices » !

je suis convaincu que l'avenir va modifier la donne et que la rigueur va devenir de plus en plus nécessaire, comme ça a été le cas dans toutes les industries. Cependant, ça ne sera pas avant une 20 aine d'années au mieux.

J'en discutais il y a quelques jours avec Jean-Raymond Abrial (pour ceux qui ne le connaissent pas cf. sur wikipedia par exemple) et il me trouve un peu optimiste ^_^ Mais bon ça doit être ma nature.

[gexian]

La qualité du code c'est pas encore ça. Les entreprises "client" y pensent mais ne sont pas encore prêtes a y mettre les moyens. Celui qui gagne le contrat reste celui qui présente un dossier conforme au marché au coût minimum, donc celui qui aura souvent sous-évaluer le coût d'un respect de certaines normes et de qualité du code.

C'est comme ça qu'on se retrouve avec un contrat sur une qualité très exigeante dont la réalisation va être laissée à une équipe de gens peu formés et pas cher (non, je n'ai pas dit des stagiaires de SSII) ou, au mieux, externalisés dans du near/off shore par des personnes n'ayant pas à disponibilité l'historique du projet. J'exagère un peu, mais pas tant que ça.

Quand on ajoute à ça des contextes ou la phase de maîtrise d'ouvrage n'est pas forcément bien aboutie, je dirai qu'il est difficile par les temps qui courent de trouver du code propre en SSII (même avec la meilleur volonté du monde de la part des développeurs et experts).

[Garulfo]

La qualité du code c'est pas encore ça. Les entreprises "client" y pensent mais ne sont pas encore prêtes a y mettre les moyens. Celui qui gagne le contrat reste celui qui présente un dossier conforme au marché au coût minimum, donc celui qui aura souvent sous-évaluer le coût d'un respect de certaines normes et de qualité du code.

Ce qu'oublie les entreprises (parce que souvent elles ne le savent pas) c'est qu'un logiciel va couter plus à la maintenance qu'il n'a couté (environ 30% du coût pour le développement et 70% du coût pour la maintenance). Et que c'est justement la qualité de l'analyse des besoins, de la conception et du code qui en sont la cause.

Un jour, les entreprises l'apprendront, et ça changera.