Avez vous déja travailler sur des projets de bonne qualité ?

**Nee** · 12/07/2009, 14h21

Bonjour à tous;

En quelques mots, j'ai une expérience de quelques années dans le développement web (PHP, AS, JS).
Au fur et a mesur de mon expérience, j'ai amélioré mes compétences techniques (bonnes pratiques OO, design patterns, tests unitaires, ...).

Malheureusement, les projets sur lesquels j'ai travaillé dans différentes boites - et surtout la manière dont ils ont été gérés - sont toujours basés sur des choix technologiques tres discutables, des spécifications inéxistantes, une absence presque totale de documentation, et peu de recomandations sur la qualité du code, sans parler de l'absence de communication entre les différents projets qui pourrait permettre de mutualiser certains éléments.

Bien sûr, je connais les contraintes économiques d'un projet, mais je parle des choix qui vont faire gagner quelques jours à court termes, et en faire perdre des dizaines a plus long terme.

J'avoue que je désespere un peu de travailler dans de bonnes conditions.
Je vous demande donc votre retour d'expérience sur cette question : avez vous déja travaillé dans de bonnes conditions ?

merci.

**MetalGeek** · 12/07/2009, 15h27

Si par bonnes conditions tu entends faire les choses "dans les règles de l'art", comme on l'apprend à l'école, pour moi la réponse est non, jamais.
Le problème numéro un là ou je bosse est toujours le même, quel que soit le projet : un calendrier est défini avec le client, et ce calendrier comporte des jalons auxquels je dois présenter l'avancement du travail.
Et inutile d'espérer montrer au client un schéma UML, Merise ou quoi que ce soit, il veut un aperçu du logiciel un point c'est tout. Donc je me retrouve à coder des parties de l'interface avant de faire l'analyse de composants très importants.
Au final, dans 9 projets sur 10, la partie UML & co se résume à un diagramme de packages + quelques diagrammes de classe réalisés APRES avoir codé, histoire de dire qu'on est des pros, on fait de l'UML...
Et je ne parle pas des phases de testing qui sont réalisées à l'arrache par manque de temps et qui ne sont même pas prévues dans le calendrier...

**Nee** · 12/07/2009, 17h53

C'est plus une question de court et de moyen termes que de "règles de l'art".

Je n'ai encore jamais vu un projet ou l'on prévoit quelques heures de plus pour la rédaction de documentation, ou encore quelques heures pour des vrais tests, avec des cas d'utilisations bien définis. Tout le monde le sait : les quelques heures investient dans ces pratiques seront rentabilisés rapidement (nouvel arrivant, pause dans le projet, ...).

Je parle bien de bonnes pratiques de gestion de projet, et non pas de bonnes pratiques "théoriques" (:p).

En fait, j'ai l'impression de travailler en mode "extreme programming" (conception a la volée, nombreuses releases, ...), mais sans les garde-fou (tests unitaires, documentation, communication, ... ).

Malgrès tout, les projets fonctionnent, mais leur cout de maintenance est délirant par rapport aux fonctionnalités ajoutées et aux bugs corrigés.

**HerQuLe** · 12/07/2009, 18h19

Je vois ce que tu veux dire et j'ai également pu effectuer un stage ou c'etait un peu comme tu dis...

Actuellement je suis sur un projet sympa et on prend bien le temps pour faire de la doc, des tests unitaires, de charge et http.

Sur chaque projet il devrait y avoir une plateforme d'intégration continue + batterie de tests lancés a chaque commit.

Bon on a pas un cahier des charges de 100 pages mais d'un autre coté je crois que c'est assez rare... En général la spec évolue toujours un peu en cours de route, et je pense que c'est également a toi de savoir poser les bonnes questions (si tu es en contact direct), tirer un peu les vers du nez de la moa et de bien t'imprégner de la problématique pour pouvoir anticiper les éventuels besoins...

En tout cas a mon avis une chose est fort probable: c'est pas dans les projets PHP que tu as le plus de chance de trouver des projets cleans a mon avis... rien que le langage n'invite pas forcement a la rigueur je trouve

**jabbounet** · 13/07/2009, 12h09

personellement j'ai connu les deux modes

mes 4 premières années d'expériences étaient dans l'informatique industrielle et dans la sureté de fonctionnement dans les systèmes embarqués ferroviaire.

Dans ces 4 années j'étais entouré de process normatif et on ne pouvais pas coder une ligne avant d'avoir fait des specs qui avaient été relue plusieurs fois par d'autres personnes, les cycles de développement d'un soft était assez long mais l'optique des soft était d'être robuste et fiable (j'ai eu notamment a travailler sur un soft dont l'une des contraintes était de fonctionner en 24/7 pendant 10 ans).

Ensuite je suis passé dans l'univers telecom, les méthodes et les outils étaient les mêmes, mais les cycles de vie etaient plus court donc forcement la doc le code était moins soigné, le but étant de livrer le soft dans les temps avec les fonctionnalité demandé (même si tout n'était pas complètement verrouillé avant)

bref deux univers totalement différent.

**el_slapper** · 15/07/2009, 10h03

bossé juste en banque/assurance, en tant que dev mais aussi en tant qu'homologateur. J'ai vu du meilleur et du pire.

Le meilleur : un projet ou le chef de projet connait le sujet, ou les specs sont rédigées par une personne qui connait son affaire, ou le dialogue avec les utilisateurs est permanent, ou l'architecte(un sale con très compétent) vérifiait régulièrement la bonne conformité du code, ou les développeurs sont motivés, et ou ils ne prennent pas pour une insulte personelle chaque anomalie que j'ai pu leur lever. Et en plus, une spec qui s'adapte quand on voit des trous ou des erreurs dedans. Avec malgré tout des points faibles : lot 1 rachitique en raison d'une exigence de délai délirante, livraisons en homologation une seule fois par semaine(livré le lundi matin, homologué dans la journée, anomalies corrigées le mardi, et ensuite on attend), environnement de travail plombé 3 semaines, utilisateurs qui se rendent compte devant l'outil développé suivant leurs désirs qu'en fait ça ne va pas du tout, etc.....mais c'était faisable, et on l'a fait. Proprement.

Le pire : projet ou les specs sont rachitiques, fausses, obsolètes, et rachitiques, mais validées donc intouchables. Ou les développeurs errent dans les couloirs sans savoir ce qu'ils doivent faire. Ou le client et le fournisseur "n'arrivent même pas à se mettre d'accord sur l'étendue de leur désaccords". Ou les choix technologiques sont aberrants. Ou les DP & CP se font virer à la queue leu leu. J'ai eu la chance de pouvoir me barrer avant le feu d'artifice final, d'après les survivants, ça a été sanguinaire.

Le plus démotivant : un projet ou les spécifications fournies au développeur étaient du niveau organique. Y'avait plus qu'à transformer "alimenter le numéro de contrat destinataire par celui de l'origine" en un "MOVE N-CTRT OF ORGN TO MOVE N-CTRT OF DSTR". Le niveau zéro de la programmation.

Le plus motivant : une chaine existante gère les éditions au client. On change de logiciel d'édition. On en profite pour refaire toute la chaine, car l'existante est un vieux nanar illisible. Tout le monde considère que c'est impossible, ou au moins délirant. "el_slapper, tu as carte blanche". J'en ai chié, les gens des métiers m'ont fort peu aidé, le cahiers des charges était rachitique, mais ça tourne nickel.

**HerQuLe** · 16/07/2009, 19h54

Envoyé par el_slapper

Le pire : projet ou les specs sont rachitiques, fausses, obsolètes, et rachitiques, mais validées donc intouchables. Ou les développeurs errent dans les couloirs sans savoir ce qu'ils doivent faire. Ou le client et le fournisseur "n'arrivent même pas à se mettre d'accord sur l'étendue de leur désaccords". Ou les choix technologiques sont aberrants. Ou les DP & CP se font virer à la queue leu leu. J'ai eu la chance de pouvoir me barrer avant le feu d'artifice final, d'après les survivants, ça a été sanguinaire.

L'entreprise commence par un P ?