IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Affichage des résultats du sondage: Que faites-vous le plus souvent ?

Votants
85. Vous ne pouvez pas participer à ce sondage.
  • J'essaie de comprendre le code puis je le fais évoluer

    22 25,88%
  • Je jette l'ancien code et je recommence tout à zéro

    1 1,18%
  • Ça dépend de la qualité du code à faire évoluer, parfois je le garde, parfois je le jette

    60 70,59%
  • Je refuse de travailler sur un autre code que ceux que j'ai créés de A à Z

    0 0%
  • Pas d'avis

    2 2,35%
Débats sur le développement - Le Best Of Discussion :

Pourquoi réécrire un projet en partant de zéro ? Parce que l'ancien code est un fatras ?


Sujet :

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

  1. #41
    Inactif  

    Homme Profil pro
    Freelance EURL / Business Intelligence ETL
    Inscrit en
    Avril 2005
    Messages
    5 879
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Freelance EURL / Business Intelligence ETL
    Secteur : Finance

    Informations forums :
    Inscription : Avril 2005
    Messages : 5 879
    Points : 26 145
    Points
    26 145
    Billets dans le blog
    3
    Par défaut
    En même temps qui a véritablement le choix d'éluder un tel luxe ? A moins d'être la rock-star de la boite, interne a priori, versus un jeune consultant de chez Altruc ou Choupa-Stevia qui arrive l'air complètement terrorisé et qui veut juste se faire une première expérience...
    - So.... what exactly is preventing us from doing this?
    - Geometry.
    - Just ignore it !!
    ****
    "The longer he lived, the more he realized that nothing was simple and little was true" A clash of Kings, George R. R. Martin.
    ***
    Quand arrivera l'apocalypse, il restera deux types d'entreprise : les pompes funèbres et les cabinets d'audit. - zecreator, 21/05/2019

  2. #42
    Inactif  

    Homme Profil pro
    Ingénieur test de performance
    Inscrit en
    Décembre 2003
    Messages
    1 986
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Ingénieur test de performance
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Décembre 2003
    Messages : 1 986
    Points : 2 605
    Points
    2 605
    Par défaut
    Bonjour.

    Développeur est un vrai métier qui demande de réelles compétences.

    Cela ne m'étonne pas qu'il faille reprendre à zéro 80% des projets informatiques.

    Selon moi, avec mon expérience actuelle et mes diverses rencontres avec des développeurs, le problème principal est la rigueur.

    Le deuxième problème est la capacité à architecturer un programme.

    Ces deux problèmes suffisent à mettre en péril un projet.

    Je ne parlerai pas des autres problèmes, parce que dépendant du langage et des technos.



    Il est possible aussi de repartir de zéro, tout en usant de l'expérience et des bénéfices du projet antérieur. Rien ne l'empêche.

  3. #43
    Inactif  

    Homme Profil pro
    Freelance EURL / Business Intelligence ETL
    Inscrit en
    Avril 2005
    Messages
    5 879
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Freelance EURL / Business Intelligence ETL
    Secteur : Finance

    Informations forums :
    Inscription : Avril 2005
    Messages : 5 879
    Points : 26 145
    Points
    26 145
    Billets dans le blog
    3
    Par défaut
    Citation Envoyé par moldavi Voir le message
    Il est possible aussi de repartir de zéro, tout en usant de l'expérience et des bénéfices du projet antérieur. Rien ne l'empêche.
    Je crois que tu oublies la pierre angulaire : le sponsor.
    Lorsqu'un projet est parti en vrille dès le début, qu'il a fallu rajouter des dizaines et centaines de milliers d'euros alors qu'à la première mise en production c'était une catastrophe, que les utilisateurs ont à peu près ce qu'ils veulent mais ils doivent quand même retraiter des choses à la main derrière... Penses-tu qu'ils seraient chaud pour repayer un an de dev supplémentaire quand on leur dit "on va tout raser, on va tout refaire ?"

    Citation Envoyé par moldavi
    Développeur est un vrai métier qui demande de réelles compétences.
    Non, c'est du charlatanisme.
    Désolé, je ne savais pas trop quoi répondre à ce truisme.

    Citation Envoyé par moldavi
    Selon moi, avec mon expérience actuelle et mes diverses rencontres avec des développeurs, le problème principal est la rigueur.

    Le deuxième problème est la capacité à architecturer un programme.

    Ces deux problèmes suffisent à mettre en péril un projet.
    A chacun ses expériences. Je pense que personnellement le problème principal suit simplement le flot du projet : les CDC sont rarement clairs. L'interview client est souvent limitée. La conception a des manquements. Coté technique, il y a souvent des oublis.
    Dans tous les cas ce n'est pas grave, si on ne mettait pas autant de temps à réagir. Quelqu'un m'a dit un jour : lorsqu'on découvre une anomalie à un point d'un projet, le facteur de résolution est de 10. Grosso modo, si un Business Analyst a mal fait son boulot et aurait pu réparer son erreur en un jour, ça produit quand même 10 jours côté dev.
    Maintenant, va dire à un utilisateur que tu interviews qu'il prenne un jour pour répondre à résoudre une problématique sinon ça en prendre 100 chez le développeur. Sa réaction ? "j'ai pas le temps et/ou c'est pas mon problème. On validera en prod et après je pèterai un câble, et c'est la TMA à Madrid qui va s'en occuper".

    En soit oui, tu n'as pas tort, on manque toujours de rigueur en développement. Que ce soit des gars qui testent à l'arrache ou mal faire l'inventaire des livrables... mais si le projet était déjà mal défini, si le business analyst s'entête à mélanger des choux et des carottes, si le business analyst est pas assez technique ou pas assez fonctionnel et n'arrive pas à décrire le besoin et établir un modèle ou travailler correctement avec l'architecture fonctionnelle... bah rigoureux ou pas le projet ne pourra que se planter et être un pataquès d'ajouts.



    Au passage, le postulat de l'article, à la base, c'est qu'une équipe de développement veut tout raser parce que c'est plus dur d'essayer de comprendre, maintenir, et faire évoluer un code sur lequel ils n'ont pas travaillé. Ton message sous-entend qu'on peut faire un ReX avec d'anciens acteurs du programme. Mais dans un monde lié à la prestation biennale / triennale et à la promotion interne express, nous n'avons plus ces acteurs et nous n'avons plus de ReX. Ou alors ils s'en dédouanent carrément.
    - So.... what exactly is preventing us from doing this?
    - Geometry.
    - Just ignore it !!
    ****
    "The longer he lived, the more he realized that nothing was simple and little was true" A clash of Kings, George R. R. Martin.
    ***
    Quand arrivera l'apocalypse, il restera deux types d'entreprise : les pompes funèbres et les cabinets d'audit. - zecreator, 21/05/2019

  4. #44
    Inactif  

    Homme Profil pro
    Ingénieur test de performance
    Inscrit en
    Décembre 2003
    Messages
    1 986
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Ingénieur test de performance
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Décembre 2003
    Messages : 1 986
    Points : 2 605
    Points
    2 605
    Par défaut
    Bonjour.

    Citation Envoyé par Glutinus Voir le message
    Je crois que tu oublies la pierre angulaire : le sponsor.
    Lorsqu'un projet est parti en vrille dès le début, qu'il a fallu rajouter des dizaines et centaines de milliers d'euros alors qu'à la première mise en production c'était une catastrophe, que les utilisateurs ont à peu près ce qu'ils veulent mais ils doivent quand même retraiter des choses à la main derrière... Penses-tu qu'ils seraient chaud pour repayer un an de dev supplémentaire quand on leur dit "on va tout raser, on va tout refaire ?"


    Non, c'est du charlatanisme.
    Désolé, je ne savais pas trop quoi répondre à ce truisme.



    A chacun ses expériences. Je pense que personnellement le problème principal suit simplement le flot du projet : les CDC sont rarement clairs. L'interview client est souvent limitée. La conception a des manquements. Coté technique, il y a souvent des oublis.
    Dans tous les cas ce n'est pas grave, si on ne mettait pas autant de temps à réagir. Quelqu'un m'a dit un jour : lorsqu'on découvre une anomalie à un point d'un projet, le facteur de résolution est de 10. Grosso modo, si un Business Analyst a mal fait son boulot et aurait pu réparer son erreur en un jour, ça produit quand même 10 jours côté dev.
    Maintenant, va dire à un utilisateur que tu interviews qu'il prenne un jour pour répondre à résoudre une problématique sinon ça en prendre 100 chez le développeur. Sa réaction ? "j'ai pas le temps et/ou c'est pas mon problème. On validera en prod et après je pèterai un câble, et c'est la TMA à Madrid qui va s'en occuper".

    En soit oui, tu n'as pas tort, on manque toujours de rigueur en développement. Que ce soit des gars qui testent à l'arrache ou mal faire l'inventaire des livrables... mais si le projet était déjà mal défini, si le business analyst s'entête à mélanger des choux et des carottes, si le business analyst est pas assez technique ou pas assez fonctionnel et n'arrive pas à décrire le besoin et établir un modèle ou travailler correctement avec l'architecture fonctionnelle... bah rigoureux ou pas le projet ne pourra que se planter et être un pataquès d'ajouts.



    Au passage, le postulat de l'article, à la base, c'est qu'une équipe de développement veut tout raser parce que c'est plus dur d'essayer de comprendre, maintenir, et faire évoluer un code sur lequel ils n'ont pas travaillé. Ton message sous-entend qu'on peut faire un ReX avec d'anciens acteurs du programme. Mais dans un monde lié à la prestation biennale / triennale et à la promotion interne express, nous n'avons plus ces acteurs et nous n'avons plus de ReX. Ou alors ils s'en dédouanent carrément.
    Si on lit tout ce que vous racontez, "c'est bancale dès le départ", oui, nous sommes tous d'accord.

Discussions similaires

  1. Réponses: 3
    Dernier message: 18/12/2017, 16h43
  2. [AC-2010] Forcer 'assistant de création à faire du code vba plutôt que des macros
    Par lololebricoleur dans le forum Access
    Réponses: 2
    Dernier message: 20/11/2013, 18h30
  3. Réponses: 7
    Dernier message: 01/09/2009, 21h24
  4. Réponses: 2
    Dernier message: 13/07/2008, 15h57

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo