Une conception ou un code sale est il un danger pour une entreprise ?

**gexian** · 22/09/2008, 14h36

Mouai, avec les stratégies "à court terme" c'est pas pour aujourd'hui ni demain. Je passerai les éternelles "décisions politiques".

Finalement, le déroulement d'un projet prend assez peu en compte les conseils des techos. Ce qui importe plus c'est l'avis du commercial, du manager et du client... C'est frustrant.

**Garulfo** · 22/09/2008, 20h51

Envoyé par gexian

Mouai, avec les stratégies "à court terme" c'est pas pour aujourd'hui ni demain. Je passerai les éternelles "décisions politiques".

Finalement, le déroulement d'un projet prend assez peu en compte les conseils des techos. Ce qui importe plus c'est l'avis du commercial, du manager et du client... C'est frustrant.

De moins en moins. C'est pourquoi les postes de conseillers en informatique sont de plus en plus nombreux. Les petites entreprises utilisent ceux qui ont une vue indépendante et qu'ils payent juste pour un projet.

Mais on est loin d'une panacée.

**SlashEne** · 24/09/2008, 11h16

Faire du code sale a cause de la pression sur les deadline,
ca me fait penser a <a href="http://www.dilbert.com/dyn/str_strip/000000000/00000000/0000000/000000/20000/2000/200/24383/24383.strip.gif/">ce comic</a>.

Si le but du développeur est de produire un bon code, le but des manager est de leur permettre de faire du bon logiciel.

Si une deadline n'est pas atteinte le problème vient :
-soit de la personne qui l'a imposé.
-soit d'une mauvaise équipe de développeur.
-soit des développeur qui sont sur une "courbe d'apprentissage" (nouvelle techno, methode...).

J'ai l'impression que l'on met toujours les retards sur la gueule des développeurs !

**souviron34** · 24/09/2008, 11h31

tu oublies :

mauvaise estimation du temps
deadline indépendante de ta volonté
deadline "catastrophe" (bug opérationnel)
développeurs optant pour respect horraires de travail <-> respect du deadline

**diva-bibi** · 28/09/2008, 20h09

J'ai peur de penser que serait ce monde la sans le code sale... Tous au chômage ?

Quant aux experts de XP à mon avis ce sont les gens ultra compétents en extorsion d'argent de la poche des pauvres développeurs.

Faudrait que je écrive un livre sur SCRUM, XP, LEAN, EAA ou SDRL, MAM, VDF où encore autre chose, puis je vais me convertir au consulting sur le méthode que je viens d'inventer

**SlashEne** · 30/09/2008, 20h06

Quant aux experts de XP à mon avis ce sont les gens ultra compétents en extorsion d'argent de la poche des pauvres développeurs.

ton avis rejoint ce post d'un gars qui travaille chez google et qui fait la critique des méthodologies logiciels. (très intéressant, si vous avez le temps !!)

Cependant pour en revenir à XP, je pense que certaine de ses pratiques sont plus des bonnes pratiques qu'une méthodologie, et a mon sens il y a quelque chose à en tirer (test de recette, unitaire, integration continue, convention uniforme ces pratiques sont difficilement reprochable).

**lonycc** · 09/10/2008, 16h01

Je rencontre 2 cas de figures :

A mon boulot, le code est pourri, je bosse pour un site en asp3 et en mise en page en tableau (pas le temps de changer le site entierement, on reste à la vieille méthode)
Pourtant j'ai déja proposer à mon patron de faire évoluer le site mais non,il faut faire du chiffre alors on code, on code, on code, pas le temps de s'attarder sur ce qu'il y a de nouveaux ect... Bref le code est de plus en plus pourri et en fin de compte on perd de plus en plus du temps.

A la maison, sur mon site perso fait en php, code propre, mise en page en css, table propre. J'ai le temps de m'attarder sur des choses nouvelles.
Je suis pas pressé. Tout est nickel

Voilà ma propre expérience.

**Heaven2K8** · 15/10/2008, 13h52

Mdr biensur que c'est grave,niveau sécurité on peut exploiter des failles dans ton codes

**millie** · 15/10/2008, 14h23

Envoyé par Heaven2K8

Mdr biensur que c'est grave,niveau sécurité on peut exploiter des failles dans ton codes

Ce n'est pas parce qu'un code est sale qu'il n'est pas sûr

**buggen25** · 15/10/2008, 14h28

Envoyé par millie

Ce n'est pas parce qu'un code est sale qu'il n'est pas sûr

C vrai ça surtout quand on se retrouve avec des methodes de 600 lignes de codes

**millie** · 15/10/2008, 14h46

Envoyé par buggen25

C vrai ça surtout quand on se retrouve avec des methodes de 600 lignes de codes

Par contre, il est plus simple de vérifier qu'un code bien concu et bien écrit est sûr (évidemment)... Je n'ai jamais dit le contraire

**el_slapper** · 15/10/2008, 14h48

...ou une boucle if - end if avec 533 lignes de code. Je les avait comptées, j'avais un bug au milieu. y'avait un rigolo qui avait changé l'indentation lors d'une modif, et un autre derrière qui avait rajouté un if-enf if au milieu......en se fiant à l'indentation. Ca faisait planter dans un cas rare.....

**souviron34** · 15/10/2008, 15h20

Envoyé par buggen25

C vrai ça surtout quand on se retrouve avec des methodes de 600 lignes de codes

Dans certains cas (très particuliers) il n'est pas forcément possible de faire autrement ...

**Dsphinx** · 15/10/2008, 15h34

Le pire est souvent la reprise d'un code dont la méthodologie n'est pas la même que celle qu'on applique. Dans ce cas, l'inconvénient est la perte de temps pour s'adapter à cette structure.

**buggen25** · 15/10/2008, 15h44

Envoyé par souviron34

Dans certains cas (très particuliers) il n'est pas forcément possible de faire autrement ...

Bonjour
Oui, en vérité c'est le plupart du temps. on peut pas faire autrement, on aime bien avoir tout sous la meme fonction. comme ça on n'a pas a chercher dans d'autres fichiers ou dans le meme fichier

**souviron34** · 15/10/2008, 16h19

Envoyé par buggen25

Bonjour
Oui, en vérité c'est le plupart du temps. on peut pas faire autrement, on aime bien avoir tout sous la meme fonction. comme ça on n'a pas a chercher dans d'autres fichiers ou dans le meme fichier

Non..

C'est extrêmement rare, mais ça peut arriver..

(je ne l'ai pratiqué que 2 fois seulement..)

Cependant c'est très fortement à déconseiller...

D'un autre côté, surtout ne pas suivre des méthodes donnant un nombre de lignes max par fonction d'une manière stricte.. C'st absurde...

Le bon sens (et la conception "orientée objet") est la règle...

**buggen25** · 15/10/2008, 16h26

[QUOTE=souviron34;3704063]Non..

C'est extrêmement rare, mais ça peut arriver..

(je ne l'ai pratiqué que 2 fois seulement..)

Cependant c'est très fortement à déconseiller...
[QUOTE]
On peut aussi relire le code apres l'avoir rigourousement testé, et reformuler les longues fonctions pour les diviser en fonction de petite longueur , du moment que c'est possible

**souviron34** · 15/10/2008, 16h34

Envoyé par buggen25

du moment que c'est possible

C'est ce que je viens de dire dans les 2 messages précédents. C'est extrêmement rare, mais ça arrive qu'on ne puisse pas..

**Heaven2K8** · 15/10/2008, 17h08

C'est peut - etre aussi plus lent et le risque ne vient pas forcement du code mais de l'humain vous les developpeurs qui êtes perdu à 5h du mat à retouché des lignes de codes,et là PAF! l'erreur humaine est un critère à ne pas oublier

**el_slapper** · 16/10/2008, 09h05

Envoyé par buggen25, perfectionniste

(.../...)
On peut aussi relire le code apres l'avoir rigourousement testé, et reformuler les longues fonctions pour les diviser en fonction de petite longueur , du moment que c'est possible

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).

Une conception ou un code sale est il un danger pour une entreprise ?

Débats sur le développement - Le Best Of

Discussions similaires

Partager

Partager