Discussion :

[buggen25]

Et tu imputes ça sur quelle ligne budgetaire? Evidemment, si on a encore du temps à brûler alors qu'on a fini le truc, alors on peut se permettre du fignolage(et quand je peux, je ne me prive pas de passer un coup de mirror sur mon code). Mais quand on est en limite de budget, ça n'est pas possible, hélas(ça se payera plus tard, mais ça, ça n'est pas un argument pour des chefs qui veulent leur prime tout de suite).

Je suis pas perfectionniste
Si on va dans ce sens, le developpement n'est qu'une partie minime d'un processus commercial remplit de bla bla.
Je parle de comment ça devrait se faire comme on le raconte dans la litterature, dans la réalité il faut que sa marche et basta.

[Floriang33]

Je pense que respecter de le design pattern et MVC est très important, pour toi et pour le client. J'aurais tendance à dire que ça fait partie d'un bon développeur.

Respecter ça permet de modifier une couche indépendamment des autres sans avoir de problèmes, ou à avoir a faire de modifications au seins des autres couches. De plus, il faut savoir que tu peux parfois rencontrer des codes très sales, car parfois ils peuvent être vieux (si tu fais de la modification d'application, avec nouvelles versions périodique en prenant la version précédente comme base), et il faut savoir que déjà un code datant d'environ 3 ou 4 ans pourrait te choquer. La technologie n'est plus la même, tu sors de l'école (ou pas ), et les développeurs précédant ne connaissaient peut être pas la technologie.

Je pense donc que maintenant que nous avons des normes de séparation des couches, et qu'on est tous conscient que cela facilite énormément les modifications sur l'application, surtout si il faut tout casser...(on le sait, les clients sont jamais content du premier coup ). Et ça permettra à n'importe qui de prendre ton relais plus simplement si tu es en arrêt ou affecté à une nouvelle mission. Si c'est pas le cas, j'aimerais pas être à la place du relayeur...

[tim974]

Salut, j'ai pas tout lu, mais dans les premiers messages tu dis qu'un chef de projet ne demande jamais de code propre...

Humm .. lorsque ton employeur te recrute, il te demande de prendre une douche tous les matins ?

Ce n'est pas la peine qu'il le demande, non? Tu le fais de toi même car c'est une chose normale. Le chef de projet, c'est pareil, lorsqu'il te recrute, il te demande de savoir coder bien et rapidement ( la propreté est inclut autant que faire se peut ).

Oui, je confirme que c'est 10 fois plus rapide de travailler avec du code propre, mais les normes changent tout le temps, donc la propreté du code reste relative selon les actions de maintenances effectuées.

[Garulfo]

[...]
Oui, je confirme que c'est 10 fois plus rapide de travailler avec du code propre, mais les normes changent tout le temps, donc la propreté du code reste relative selon les actions de maintenances effectuées.[...]

Ton argument n'est pas vraiment valide. En effet, si c'est encore plus sale, le changement induit par le changement de norme est, en général, encore plus couteux. Tu argumentes donc pour dire qu'il faut travailler avec du code bien écrit et documenté, avec une conception bien faite et une analyse précise.

Car, dans ce cas, le changement de norme coute moins cher. Beaucoup d'études le démontrent. C'est difficile de revenir sur ça, même en exprimant des cas particuliers dans lesquelles on peut avoir vécu un contre-exemple (enfin si ça t'est déjà arrivé).

[rakakabe]

Il y avait quelqu'un a dit auparavant : "j'ai l'impression que c'est le developpeur le responsable du retard"; Et je reconfirme que c'est la triste realite lorsqu'on cherche quelqu'un a pendre.

Tant que vos superieurs ne comprennent pas ce qu'est LE COUT DE LA MAINTENANCE et vous gueulent du retard pour cette SIMPLE fonctionnalite qui n'a rien de difficile, alors c'est le developpeur (vu par le chef de projet) ou le chef de projet (vu par ses superieurs) le coupable, mais JAMAIS le client qui ne sait meme pas en general ce qu'il veut (car c'est lui, parrait-il qui paie ton pain quotidien), et surtout qui ne voit que le bout de son nez (on se fout du futur (comment va evoluer ce systeme) car le probleme se conjugue au present).

Dommage pour nous les simples developpeurs ; Qui osera dire a son boss que le futur se fait au present sans se couper les ....

[tim974]

Garulfo, j'avoue, coder proprement et avec un langage à jour, prend 4 fois plus de temps.

Par contre, le déboguage et la reprise du code se sont 5 fois plus rapidement pour une personne externe.

Après, c'est le client qui décide, soit il veut quelque chose rapidement et un code fait à la sauve-qui-peut. Soit, il donne du temps et reçoit un code de qualité et durable.

Le problème, c'est qu'ils veulent du bon code a la vitesse du malpropre, c'est ça?

[rberthou]

J'arrive un peu tard sur ce sujet mais je ne peux m'empêcher de donner mon avis .

OUI, une conception ou un code sale est un danger pour une entreprise.
Cela est dangereux d'un point de vu :
- sécurité (risque de failles, de bugs dangereux, ...)
- temps de maintenance (on gagne un peu de temps avec une conception à la va vite et un code pourrie mais on en perd 10 fois plus quand viens l'heure de la maintenance).
- pérennité du soft,

OUI, cela est hélas très courant de rencontrer ce gros problème , je pense que les principales cause de cela sont :
- pour certain projet on ne s'intéresse qu'a la date de livraison
- pour des projets réalisés en externe on prévois rarement un audit de code, on spécifie pas de normes et standards, ... Quand on doit recetter le soft le sous-traitant demandera un avenant pour chaque oubli de notre part et cela est normal .
- Les technologies ont largement évolué et beaucoup d'informaticiens n'ont pas suivi le mouvement.
- Pour pas mal d'informaticiens (et pas que des développeurs) leur métier est uniquement "nourricier" donc on en fait le moins possible sans chercher a s'améliorer.



Je pense qu'il est facile plus de réaliser cela sur certaines technos plus récentes et ouvertes (php, java, .net, C, C++ ...) que dans les "vieillissantes" (Cobol, VBasic, ...) .
Dans tous les cas (même sur les technos vieillissantes) on devrais tous :
- définir des normes et standards (et bien sur les suivre)
- utiliser un gestionnaire d'incidents / de bugs ( bugzilla ou autre...)
- un planning
- un gestionnaire de code source ( SVN, ... ) pas toujours possible helas
- un automate de build ( maven, ant, ... ) pas toujours possible helas

[Matthieu Brucher]

Dans certains cas, le code sale est une bonne chose. Eh oui, quand il y a des stagiaires qui viennent et qu'ils ont accès à certains codes sensibles, si le code est sale, bon courage pour le comprendre et partir avec

[LittleBean]

Pour moi la définition d'un code sale, c'est un code non uniforme (présentation, nommage, ...) en gros une fois habitué au code on puisse en lire facilement chaque partie du projet .
Bien sur respecter les bonnes pratiques techniques est un plus

En gros pour moi un code sale c'est uniquement au niveau de l'apparence et pas du fond.

Attention je milite aussi pour un fond correct mais c'est un autre problème, question de définition

Une petite explication sur le business SSII :
- à l'appel d'offre :
- le client prend le moins cher sans regarder l'offre technique
- le client prend l'offre du commercial avec qui il s'entend bien
- les commerciaux ne consultent pas les techniques
- les délais offert sont intenables

- pendant le projet :
- les outils sont souvent mis en place ne fin de v1
- le suivi qualite technique n'est pas assuree
- la ssii ne fait pas/peu de benef

- la tma :
- le code est incompréhensible, le client prend la même ssi
- le client n'est pas techniquement compétant, la ssii facture ses stagiaires au titre d'expert

Voila en deux mots le système que j'ai observé chez les ssii pour l'instant.
Tout ça pour dire que coder de façon crade est au cœur du modèle économique actuel et que ça va pas changer de sitôt (que ce soit côté client ou service).

Bien sur c'est une présentation caricaturale vers le bas et il y a des projets là où ce n'est pas totalement vrais.

Bon pour finir sur une note optimiste , je dirais que l'XP fait son chemin et que ça va devenir la norme ... dans 10 ans

[hegros]

Dans certains cas, le code sale est une bonne chose. Eh oui, quand il y a des stagiaires qui viennent et qu'ils ont accès à certains codes sensibles, si le code est sale, bon courage pour le comprendre et partir avec

Faut-il encore les encadrer pour espérer refactorer des morceaux de code un peu à la mode des crados et apprendre quelque chose aussi en programmation tant qu'à faire.



concernant la conception sale cela rime avec code sale. mais la conception par défaut lorsque aucun moyen et outil n'est fourni aux programmeurs (entendez on ne vous dis pas comment faire la conception pour ensuite passer au code avec une projection dans le temps) alors la mode de conception c'est la tête dans le guidon du code et souvent chaque programmeur développe son petit bout de code à sa sauce (qui est une part de la conception générale au final ) lorsqu'il n'y a pas de mélée quotidienne (pour parler scrum)

[nicolofontana12]

Je crois que c'est la conception qui est plus interresant.Peux importe ( pas beaucoup ) la propriete du code