Discussion :

[XSeneque]

Boujour

En tant que developeur, on manipule du code a longueur de journee. Au fil des années & des sociétés pour lesquelles j'ai travaillé que toutes avaient plus ou moins du code assez immonde, illisible par endroit, rempli de hacks, pas evolutif.... bref un jeu de Jenga geant ou la difficulté principale du job est de ne pas tout faire tomber au moindre changement. Ceci vaut aussi bien pour le code, que pour les tests, l'architecture, le deploiement....

Bref, avez vous deja travaillé pour une boite ou vous avez trouvé le code & les outils annexes de bonne qualité et adequat pour le support de l'evolution des fonctionnalites? (question annexe, est-ce qu'ils embauchent )

Ca serait interessant d'avoir une sorte de liste avec un index de la médiocrité du code

Merki a tous!

[LinuxUser]

Je comprends pas trop, tu cherches un emploi, ou tu lances juste une sorte de sondage?

[XSeneque]

Je comprends pas trop, tu cherches un emploi, ou tu lances juste une sorte de sondage?

plutot un sondage; je n'ai pas vu de forum plus approprié que celui-ci vu que ce n'est pas lié a une technologie specifique mais aux entreprises.

[HerQuLe]

Tu peux le constater aussi bien en entreprise que sur des frameworks opensource.

En Java:
Tu ouvres Hadoop ou CXF -> Beurk
Tu ouvres Spring c'est déjà beaucoup plus clean et mieux designé


Il faut de tout pour faire un monde

[gangsoleil]

Bonjour,

Bref, avez vous deja travaillé pour une boite ou vous avez trouvé le code & les outils annexes de bonne qualité et adequat pour le support de l'evolution des fonctionnalites?

Facile : il suffit de trouver une boite avec un budget infini.

En informatique comme partout ailleurs, il y a des problematiques de cout. Faire un logiciel parfait du point de vue de la conception, de l'evolution, de la maintenabilite, etc, ca demande un budget infini.

Apres, la tendance actuelle est au "tout le monde developpe tout et n'importe quoi, et surtout n'importe comment". Ainsi, tu te retrouves a maintenir en prod un script d'un commercial car tu n'as pas eu les moyens de faire ce projet correctement.

Je te dirai volontiers que les codes C que j'ai rencontres sont souvent relativement propre, probablement parce que quand tu merdes en C, il n'est pas possible de simplement catcher l'exception (enfin si, mais personne ne le fait). Contrairement aux langages de plus haut niveau, qui permettent souvent de plus "rattraper le coup".

[deadalnix]

Facile : il suffit de trouver une boite avec un budget infini.

En informatique comme partout ailleurs, il y a des problematiques de cout. Faire un logiciel parfait du point de vue de la conception, de l'evolution, de la maintenabilite, etc, ca demande un budget infini.

C'est complètement faux. Au contraire, faire du code de qualité coûte moins cher pour tout projet non trivial.

[XSeneque]

je prend l'exemple de ma boite... on bosse sur un system avec plus de 10 millions d'abonnes, le systeme est en prod depuis ~8 ans, fait en java, fait initialemenent par des programmeurs C qui connaissaient pas trop java ni le systeme sur lequel la couche applicative est basée... donc niveau conception c'est assez grotesque.

comme c'est en prod, on ne peut que changer ce qui est demandé par le business... c'est dur de "refactoriser" le code pour l'ameliorer, car c'est rarement approuvé (trop de risque). donc resultat, on ne fait que bidouiller pour implémenter les fonctionalites requises au cout minimum, mais ce cout est en general assez elevé a cause de la qualite merdique du code.

je pense que les boites qui font du software sans supporter directement des systemes en production ont la possibilité de refactoriser beaucoup plus aisement, et donc la qualite du code devrait etre bien meilleure. temoignagnes?

[HerQuLe]

je prend l'exemple de ma boite... on bosse sur un system avec plus de 10 millions d'abonnes, le systeme est en prod depuis ~8 ans, fait en java, fait initialemenent par des programmeurs C qui connaissaient pas trop java ni le systeme sur lequel la couche applicative est basée... donc niveau conception c'est assez grotesque.

comme c'est en prod, on ne peut que changer ce qui est demandé par le business... c'est dur de "refactoriser" le code pour l'ameliorer, car c'est rarement approuvé (trop de risque). donc resultat, on ne fait que bidouiller pour implémenter les fonctionalites requises au cout minimum, mais ce cout est en general assez elevé a cause de la qualite merdique du code.

je pense que les boites qui font du software sans supporter directement des systemes en production ont la possibilité de refactoriser beaucoup plus aisement, et donc la qualite du code devrait etre bien meilleure. temoignagnes?

Je valide.
Les projets avec dette technique et aucun budget pour corriger sont des traquenards. Tous ne sont pas comme ça...

J'ai été sur l'un d'eux récemment, horrible. Je suis passé sur un projet tout neuf donc les premières lignes de Java sont posées par une équipe de 2 architectes et 4 développeurs avec au moins 3 ans d'expérience et d'un bon niveau. Bon on se tape une base legacy de merde, mais le code Java n'a rien a voir
Le truc c'est de tenir sur la durée et d'avoir un management pas trop borné... on verra bien mais pour le moment ça se passe très bien.

Je ne comprends pas trop ton idée de "sans supporter une version en production". Les projets ont pour but de passer en production, alors à moins que tu bosses sur la fusée Arianne je sais pas ce que tu attends...


Je pense surtout qu'il faut avoir une bonne équipe, quitte a y mettre le prix, et même si les bénéfices sont pas immédiats, ils se font ressentir sur le long terme. Garder la règle a l'esprit: "toujours laisser le terrain plus propre après mon passage" permet de réduire la dette.

[deadalnix]

comme c'est en prod, on ne peut que changer ce qui est demandé par le business... c'est dur de "refactoriser" le code pour l'ameliorer, car c'est rarement approuvé (trop de risque). donc resultat, on ne fait que bidouiller pour implémenter les fonctionalites requises au cout minimum, mais ce cout est en general assez elevé a cause de la qualite merdique du code.

C'est marrant, parce qu'il se trouve que je travaille sur un système en prod depuis 10 ans, et si tu veux on en parle en MP, mais je suis à peu près sur qu'on a BEAUCOUP plus d'utilisateurs.

Et on arrive pourtant à refactorer. Ne pas le faire car c'est risqué, c'est éviter un risque maintenant, pour en assumer un plus grand plus tard. Et si l'on considère que diriger c'est prévoir, j'ai une mauvaise nouvelle pour le management de ta boite.

[ulspider]

C'est marrant, parce qu'il se trouve que je travaille sur un système en prod depuis 10 ans, et si tu veux on en parle en MP, mais je suis à peu près sur qu'on a BEAUCOUP plus d'utilisateurs.

Et on arrive pourtant à refactorer. Ne pas le faire car c'est risqué, c'est éviter un risque maintenant, pour en assumer un plus grand plus tard. Et si l'on considère que diriger c'est prévoir, j'ai une mauvaise nouvelle pour le management de ta boite.

Salut,

tu en reviens toujours à l'éternel débat. Faut-il faire évoluer le code pour que celui-ci deviennent de meilleur qualité (= moins de bug) et beaucoup plus maintenable sans l'accord du Business (qui aura tendance à refuser ces évolutions susceptibles de créer des bugs) ?

[gangsoleil]

faire du code de qualité coûte moins cher pour tout projet non trivial.

Faire du code de qualite coute moins cher, a moyen ou long terme, que de faire de la merde, c'est certain.

Mais faire du code parfait, avec tous les tests unitaires et fonctionnels, toute la doc bien ecrite et tout ce que j'oublie, ca coute cher, tres cher, et c'est la partie qui est toujours enlevee.

[Guilp]

Facile : il suffit de trouver une boite avec un budget infini.

En informatique comme partout ailleurs, il y a des problematiques de cout. Faire un logiciel parfait du point de vue de la conception, de l'evolution, de la maintenabilite, etc, ca demande un budget infini.

...

Faire du code de qualite coute moins cher, a moyen ou long terme, que de faire de la merde, c'est certain.

Mais faire du code parfait, avec tous les tests unitaires et fonctionnels, toute la doc bien ecrite et tout ce que j'oublie, ca coute cher, tres cher, et c'est la partie qui est toujours enlevee.

Voilà la raison des entreprises où le code est pourri : les développeurs qui pensent que coder salement fait gagner de l'argent (dans un premier temps) à leur entreprise.

Si tu (XSeneque) veux donc trouver une entreprise où il y a du code propre, il faut trouver une entreprise où les développeurs ne pensent pas comme ça...

[Invité]

Pour répondre à la question, je dirais les sociétés qui commercialisent des solutions/services en marque blanche. Pourquoi ? Tout simplement par certains clients exigeront des garanties solides : des audits de codes, de sécurité avec des contre audits derrière. Donc derrière tu peux être sur que le taff sera fait correctement et qu'on prendra le temps pour surtout. Y en a qui prennent cher, pas de doc/commentaire, méthode deprecated et j'en passe, faille de sécurité béante.
En gros, faut soit le "bâton" soit des boîtes ou la performance et la sécurité sont une priorité du à leur cœur de métier, typiquement le genre de boîte ou tu passes des tests techniques poussés et ou on insiste sur la doc en entretien.

[el_slapper]

Faire du code de qualite coute moins cher, a moyen ou long terme, que de faire de la merde, c'est certain.

Mais faire du code parfait, avec tous les tests unitaires et fonctionnels, toute la doc bien ecrite et tout ce que j'oublie, ca coute cher, tres cher, et c'est la partie qui est toujours enlevee.

Pour du code "jetable", c'est débatable. J'ai vu au moins un cas où un code à execution unique aurait couté moins cher a avoir été fait proprement avant les tests. Mais c'était un cas vraiment particulier. c'était une espèce de gros script pour mettre à jour des données, le premier programmeur était à une semaine de la sortie, on lui a demandé de faire "vite et sale", et il s'est aperçu juste avant de partir qu'on lui avait caché pas mal de complexités. Il se sentait un peu coupable de me passer un programme pareil. Et j'en ai chié pour ramasser les morceaux, et gérer la complexité nouvellement découverte.

Pour du code réutilisable, mon expérience, c'est que la plupart du temps, un code "bien fait" coute moins cher à la réalisation. Tout simplement parcequ'à la première anomalie détectée, on passe deux siècles à tout nettoyer et à comprendre ce qui se passe.

Un TU bien fait, dès l'homologation, avant même la mise en production, il est souvent rentable. La doc, c'est débatable. Mais un code modulaire, propre, et des TU biens faits....raaaaaah, le panard. La correction passe toute seule.

[gangsoleil]

Pour du code réutilisable, mon expérience, c'est que la plupart du temps, un code "bien fait" coute moins cher à la réalisation. Tout simplement parcequ'à la première anomalie détectée, on passe deux siècles à tout nettoyer et à comprendre ce qui se passe.

Un TU bien fait, dès l'homologation, avant même la mise en production, il est souvent rentable. La doc, c'est débatable. Mais un code modulaire, propre, et des TU biens faits....raaaaaah, le panard. La correction passe toute seule.

Soit je ne m'exprime pas clairement, soit nous sommes d'accord : vive le code propre, bien fait et teste et documente et tout et tout.

Ce que je rajoute simplement, c'est que ca demande du temps, et donc le budget qui va avec, et que les chers financiers qui dirigent les entreprises ne comprennent pas que prendre X temps en plus au depart permet d'economiser beaucoup plus apres. Ou ne veulent pas comprendre.

[el_slapper]

Soit je ne m'exprime pas clairement, soit nous sommes d'accord : vive le code propre, bien fait et teste et documente et tout et tout.

Ce que je rajoute simplement, c'est que ca demande du temps, et donc le budget qui va avec, et que les chers financiers qui dirigent les entreprises ne comprennent pas que prendre X temps en plus au depart permet d'economiser beaucoup plus apres. Ou ne veulent pas comprendre.

Mais est-ce qu'ils interviennent dans la vie du projet? Si je leur dit "c'est 170 jours" et que j'en ai consommé 172, est-ce qu'ils vont me plomber parceque j'ai pris le temps de faire des choses lisibles?

[quanta]

C'est complètement faux. Au contraire, faire du code de qualité coûte moins cher pour tout projet non trivial.

+1...
Tous se paye un jour ou l'autre dans ce monde o/

[Mat.M]

Facile : il suffit de trouver une boite avec un budget infini.

En informatique comme partout ailleurs, il y a des problematiques de cout. Faire un logiciel parfait du point de vue de la conception, de l'evolution, de la maintenabilite, etc, ca demande un budget infini.

Faire du code de qualite coute moins cher, a moyen ou long terme, que de faire de la merde, c'est certain.

Mais faire du code parfait, avec tous les tests unitaires et fonctionnels, toute la doc bien ecrite et tout ce que j'oublie, ca coute cher, tres cher, et c'est la partie qui est toujours enlevee.

100 % d'accord

[Mat.M]

C'est complètement faux. Au contraire, faire du code de qualité coûte moins cher pour tout projet non trivial.

c'est évident et on est tous d'accord.

Mais ces derniers temps , les choses ont totalement changé en SSII .
La tendance est à travailler dans l'urgence : le commercial il vend pour un client A , 5jours de développement ..

mais la personne qui t'encadre va te demander de travailler 2,5 jours si c'est pas 2 jours pour le client A et le reste soit 2/2.5 jours.. pour un client B
Comme ça la SSII gagne plus d'argent,c'est une bête loi de rentabilité économique.

Ce qui se passe souvent aussi c'est que le commercial facture à un client des prestations de développement qui seront réalisées...3mois après voire plus.
Comme ça ça permet aux petites sociétés de service informatique notamment de financer d'autres développements jugés plus prioritaires et de tenir la route économiquement , je l'ai constaté à maintes reprises.

Etant donné que Time is Money donc plus tu fournis de code et de prestations plus la société de service qui t'embauche gagne de l'argent ou...arrive à survivre face à la conjoncture économique.

De cette constatation plus on travaille dans l'urgence moins on a de temps pour faire du code structuré et propre, des tests unitaires qui vont bien comme l'écrit Gangsoleil

[Mat.M]

C'est marrant, parce qu'il se trouve que je travaille sur un système en prod depuis 10 ans, et si tu veux on en parle en MP, mais je suis à peu près sur qu'on a BEAUCOUP plus d'utilisateurs.

Et on arrive pourtant à refactorer. Ne pas le faire car c'est risqué, c'est éviter un risque maintenant, pour en assumer un plus grand plus tard. Et si l'on considère que diriger c'est prévoir, j'ai une mauvaise nouvelle pour le management de ta boite.

d'accord mais sur 10ans on peut capitaliser un système informatique, le stabiliser, le déboguer à fond, le structurer....
ce n'est pas comme une SSII qui reçoit un nouveau contrat de développement et qui doit lancer tout un chantier de projet informatique de A à Z...