Discussion :

[nfluch]

Dans les sociétés (clients finaux) ayant un service info de développement en interne (j'entends des salariés de la société pas des prestataires)
Chez les éditeurs ça dépend de la taille, plus il est petit en terme de salariés plus il y a de chance de trouver du code de qualité.

[deadalnix]

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.

On a clairement pas la même définition du code qualité. Par exemple, si tu as besoin de mass doc, il y a probablement un truc qui ne tourne pas rond. Si ton code est bien architecturé, rien ne sert de faire des doc débile du genre :

User : La class qui gère les utilisateurs.
- id : l'identifiant de l'utilisateur
- email : l'address email de l'utilisateur
. . .

Note qu'on m'a pondu une doc du genre un jour. Grand progrès, c'est vrai que c'était un travail vraiment nécéssaire . . .

De même, on bassine les devs en leur disant que commenter c'est bien. Du coup on passe du temps à faire du code de merde, puis on commente la merde pour se donner bonne conscience. Les commentaire, ça doit être réservé aux trucs un peu tricky (une astuce pour gagner des perfs par exemple), ou a donner des choix de plus haut niveau (pouquoi tel algo a été choisis au lieu de tel autre). Mais si ton commenatire explique le code, oublie l'étape commentaire et refactore direct.

Les tests, ça paye trèèèèès vite. Surtout quand tu refactores, pour t'assurer que tu n'a rien cassé. Sans les tests unitaire, c'est bien plus dur de refactorer, donc tu finis par le payer.

[deadalnix]

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

Il y a une grande parti psychologique dans ce que tu racontes. Certe aller vite est important. Mais faire du code propre fait GAGNER du temps.

Le truc, quand on est trop pressé, c'est qu'on pense qu'on va gagner du temps en adoptant des mauvaises pratiques. Quand tu mesures, tu vois qu'au bout, ce n'est pas vrai du tout.

Chez un dev habitué à faire du code propre (ça se fait rare et ça demande du temps pour bien maitriser les techniques), tu remarques un gain de temps en simplement quelques jours.

[deadalnix]

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

Au contraire, ça évolue très vite. La compétition est aux trousses et il faut innover. Il y a des bugs, mais de moins en moins au fil du temps. Il y a de nouvelles fonctionnalité qui sortent tout le temps.

La boite n'est pas du genre à capitaliser et à se reposer sur ses acquis. Il y a un peu de code de merde, mais tout le code récent est très clean, et le code de merde tends à réduire au fil du temps.

[gangsoleil]

Si ton code est bien architecturé, rien ne sert de faire des doc débile du genre :

User : La class qui gère les utilisateurs.
- id : l'identifiant de l'utilisateur
- email : l'address email de l'utilisateur
. . .

Nous sommes d'accord, la doc debile de ce type ne sert a rien.

Par contre, un minimum de doc bien faite est necessaire :

• Specifications client
• Specifications internes (architecture, plus technique que la premiere)
• Doc utilisateur (configuration et utilisation)

[Guilp]

Vous parlez de documentation et de tests unitaires... Alors oui, ça fait partie de ce qu'on appelle un code "propre". Et oui, comme on le voit encore dans cette discussion, c'est un sujet à débat lorsqu'il s'agit de projets à court terme, en urgence...

Mais ça n'est pas ça, que le post du départ critique! Ce qui lui ruine sa journée systématiquement, c'est le code fait complètement à l'arrache, spaghetti, bordélique! Le code où on a des fonctions de 500 lignes, où on a des classes c++ ou java de 3000 lignes à l'intérieur desquelles tout a été programmé de manière procédurale comme en C (mais mal fait évidemment). Le code où le dev a eu le "bon goût" d'appeler ses variables avec des héros de sa série favorite, ou qu'il a trop eu la flemme de renommer ses variables "truc". Le code intouchable sous peine de faire péter la planète jusqu'en Inde si on touche à un fil.

Seulement voilà, le fait que les tests unitaires et la documentation sont des sujets à débats (dans certains cas), ça donne la légitimé à plein de développeur de coder à l'arrache. C'est la bonne excuse pour lui donner raison de ne pas être rigoureux dans rien du tout du coup. Seulement, les tests unitaires et la doc, si vous lisez un bouquin du genre "codez proprement", ça ne fait pas 5% du bouquin! Mais osef, on code à l'arrache des projets urgents, en se donnant un air ultra à la bourre, occupé et sérieux, en parlant fort dans l'open space, et puis on passe pour un pro.

Voilà pourquoi je disais que si vous voulez aller dans une entreprise où le code est bien fait, allez dans une entreprise où les développeurs ne pensent pas comme ça. Parce que celui qui va penser "les tests unitaires, c'est un gain de temps", même s'il n'aura en fin de compte pas le temps de les faire car le projet est ultra urgent, il va au moins essayer de coder proprement. Alors que le gars qui est déjà convaincu à l'avance qu'être consciencieux, rigoureux, et coder proprement c'est une perte de temps, alors lui, c'est sûr, dans tous les cas, tu préfèreras démissionner que de passer derrière lui.

[gangsoleil]

celui qui va penser "les tests unitaires, c'est un gain de temps", même s'il n'aura en fin de compte pas le temps de les faire car le projet est ultra urgent, il va au moins essayer de coder proprement.
Alors que le gars qui est déjà convaincu à l'avance qu'être consciencieux, rigoureux, et coder proprement c'est une perte de temps, alors lui, c'est sûr, dans tous les cas, tu préfèreras démissionner que de passer derrière lui.

Entierement d'accord, c'est pour ca que je suis persuade que tous ces elements sont lies -- meme si beaucoup de projets n'accordent pas suffisamment de temps aux developpeurs pour tout faire correctement.

[ArchitecteNet]

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!

Le pire c'est que quant t'as le DSI ou ton manager qui est l'auteur du code merdique, et qui sur le papier a 15 ans de dev dérriére lui alors qu'il ne connais pas ni les bases de la POO et qui est encore au stade d'appeler les champs d'une table SQL rst(1) au lieu de rst("id") (Expérience vécue )

Je te recommande ce bouquin
http://www.amazon.fr/Working-Effecti.../dp/0131177052

[ArchitecteNet]

On a clairement pas la même définition du code qualité. Par exemple, si tu as besoin de mass doc, il y a probablement un truc qui ne tourne pas rond. Si ton code est bien architecturé, rien ne sert de faire des doc débile du genre :

User : La class qui gère les utilisateurs.
- id : l'identifiant de l'utilisateur
- email : l'address email de l'utilisateur
. . .

Note qu'on m'a pondu une doc du genre un jour. Grand progrès, c'est vrai que c'était un travail vraiment nécéssaire . . .

De même, on bassine les devs en leur disant que commenter c'est bien. Du coup on passe du temps à faire du code de merde, puis on commente la merde pour se donner bonne conscience. Les commentaire, ça doit être réservé aux trucs un peu tricky (une astuce pour gagner des perfs par exemple), ou a donner des choix de plus haut niveau (pouquoi tel algo a été choisis au lieu de tel autre). Mais si ton commenatire explique le code, oublie l'étape commentaire et refactore direct.

Les tests, ça paye trèèèèès vite. Surtout quand tu refactores, pour t'assurer que tu n'a rien cassé. Sans les tests unitaire, c'est bien plus dur de refactorer, donc tu finis par le payer.

dans le dev on est un artiste ou on ne l'est pas , un artiste regarderas le moindre détail, ne feras rien passer et le résultat seras parfait (en terme de code = maintenance qui tends vers 0) et y'as les autres ...

Heureusement pour nous, un mauvais programmeur peut facilement créer du boulot pour au moins deux developpeurs chaque année

[XSeneque]

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.

- je pense que le probleme dans la boite ou je suis viens a plusieurs sources: jamais eu d'architecte logiciel (uniquement pour la solution, niveau integration des systemes, et encore les interfaces ne sont pas documentées), le code a ete fait par des codeurs de niveaux tres differents, sans standards, et souvent externalisé en inde

- pas en prod: la boite A fait un logiciel, le vend a la boite B, qui elle le met en prod. je pense que le code du logiciel fait dans la boite A sera beaucoup plus elegant que tout ce que créer la boite B autour du logiciel fait par la boite A.

[XSeneque]

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.

apres qlq millions d'utilisateurs, c'est kiff-kiff.
la probleme c'est que notre platforme gere la facturation de ces clients; le moindre bug peut corrompre les donnees, et generer des factures incorrectes, couper le cash flow de la boite... bref... que du bonheur

Aussi, la boite n'est pas une boite IT, le metier n'est pas faire du logiciel, bien qu'en interne on a des centaines de developpeurs, testers, architectes, designers....

en consequence le business n'a pas beaucoup d'appetit pour le risque purement pour des raisons technique. si ca marche on change pas; si on doit changer, change le moins possible

[staticx]

J'ai eu la chance de travailler avec des développeurs/architectes de haut-niveau sur des projets très importants au niveau mondial, avec un niveau d'études très très poussé.

Ben y'a pas photo, tu vois la différence tout de suite.

Et quand tu es un développeur avec des connaissances théoriques "basique" comme moi, qui "pompe" les bonnes informations et les bonnes manières de travailler, tu te rends compte que quelques bons développeurs "rayonnent" leurs compétences autour d'eux.

Donc, la formation des développeurs(attention, ça peut être autodidacte, pas uniquement des écoles) est très importante...