Affichage des résultats du sondage: Votre avis

Votants
52. Vous ne pouvez pas participer à ce sondage.
  • En voulant coder vite, on perd toujours plus de temps à corriger ses erreurs

    34 65,38%
  • Il faut d'abord convaincre le management

    11 21,15%
  • La norme c'est de livrer rapidement, des patchs suivront pour corriger les bogues

    15 28,85%
  • Les développeurs ne sont jamais assez rapides pour le management

    21 40,38%
  • Aller lentement sera interprété comme de la paresse ou de la sous-performance

    28 53,85%
  • Un développeur rapide est vu comme un développeur motivé

    22 42,31%
  • Autre (à préciser)

    1 1,92%
  • Pas d'avis

    2 3,85%
Sondage à choix multiple
+ Répondre à la discussion Actualité déjà publiée
Page 2 sur 2 PremièrePremière 12
  1. #21
    Expert confirmé
    Homme Profil pro
    Analyste/ Programmeur
    Inscrit en
    juillet 2013
    Messages
    2 204
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Analyste/ Programmeur

    Informations forums :
    Inscription : juillet 2013
    Messages : 2 204
    Points : 4 890
    Points
    4 890

    Par défaut

    Citation Envoyé par Pyramidev Voir le message
    C'est étrange que ton message focalise la lenteur à court terme sur le développement itératif alors que c'est surtout le binômage qui ralentit le plus à court terme. Développes-tu vraiment en eXtrem Programming ?
    Tu as raison: c'est plus eXtrem :
    • il n'y a pas de "pair programmaing". Parce que je suis tout seul ou même à 2 -3 c'est chacun son projet, même si on peut donner une idée/ un conseil.
    • il n'y a pas beaucoup de tests (développement IHM en C et C++)


    Et tu ne parles pas non plus des réunions d'avancement, des "milestones", ...

    Mais après coup, je me dis que ma lenteur est surtout liée à l'environnement :
    • Pas de cahier de charges. 1) tu ne sais jamais exactement les fonctionnalités à coder, surtout les secondaires qui peuvent être importantes 2) évolutions des fonctionnalités (c.-à-d. suppression ou ajout)
    • Tout seul ou à 2-3 pour tout coder, même pour faire de la R&D.
    • Bonus : des vieux outils qui t'obligent à coder beaucoup en "bas niveau"


    Mais je me demande si ma lenteur n'est pas liée aussi à cette méthode incrémentale Parce que si toutes les fonctionnalités été codées en 1 grosse fois avec les dépendances les plus nécessaires, cela m'éviterait de "refactoriser"/ concevoir aussi souvent (<- en fait pas vraiment, on peut ensuite "refactoriser" mais cela sera en ultra prioritaire avec un blocage du projet plus ou moins long/ ou un "fork". Mais cela arrive sur tout projet déjà conséquent)

    Après la qualité du code? Difficile de la dire, c'est du cas par cas . C'est sûr, il ne sera aussi "premium", mais pas forcément mauvais, peut-être même très bon, même si certaines fonctionnalités sont insérées au pied-de-biche.
    Et pour faire un parallèle avec les SC2I (ESN), je pense que le problème c'est le "turn-over" qui est important. Je pense que si les "cadres" du projet durent, même si on code les projets en mode bourrin, il y aura toujours cette vision d'ensemble.

    Et enfin Matthieu Vergne (et moi aussi), on dit que plus une fonctionnalité est importante plus cela fera du code à jeter/ recoder.
    Mais plus le code est gros, plus il y aura de choses à repiquer ... même si des fois, après coup, cela peut être une mauvaise idée parce qu'il ne correspond pas autant au besoin qu'on avait prévu.

  2. #22
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    4 787
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 4 787
    Points : 20 276
    Points
    20 276

    Par défaut

    Citation Envoyé par Pyramidev Voir le message
    (.../...)Le binômage (pair programming) : deux développeurs par PC ! Il y en a un qui code et l'autre qui surveille les erreurs et propose des alternatives.[*]Les binômes changent régulièrement de façon à ce que tout le monde connaisse un peu tout le programme. Ainsi, lors d'une itération, si la plupart des demandes se concentrent sur la même portion du programme, au lieu que seul le spécialiste de cette portion travaille dessus, une plus grosse partie de l'équipe peut intervenir.(.../...)
    Le surcout du pair programming est réel, mais bien moindre que ce à quoi on pourrait penser : en termes de charge, ça coute 15% plus cher.

    together the pairs only spent about 15% more time on the program than the individuals . Development costs certainly do not double with pair programming!
    the resulting code has about 15% fewer defects
    Et il fait une analyse complète du cout des bugs, qui est bien plus grand sur le cycle de vie du logiciel que le développement initial, pour au final arriver au résultat que le pair programming, c'est rentable, en fait. Mais allez convaincre.....
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  3. #23
    Rédacteur/Modérateur

    Avatar de Lolo78
    Homme Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    mai 2012
    Messages
    3 170
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Conseil - Consultant en systèmes d'information
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : mai 2012
    Messages : 3 170
    Points : 10 347
    Points
    10 347
    Billets dans le blog
    1

    Par défaut

    Informatique: On a le temps de faire mal 3 fois mais on a pas le temps de faire bien 1 fois.
    C'est vraiment un point essentiel.

    On passe son temps à mal faire plusieurs fois que que l'on aurait pu bien faire du premier coup et en beaucoup moins de temps avec les bonnes conditions.

  4. #24
    Nouveau membre du Club
    Homme Profil pro
    Webmaster
    Inscrit en
    mai 2014
    Messages
    27
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 68
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Webmaster
    Secteur : Enseignement

    Informations forums :
    Inscription : mai 2014
    Messages : 27
    Points : 32
    Points
    32

    Par défaut

    Lorsqu'on pense avoir terminé une appli, c'est à ce moment qu'il faudrait tout effacer pour recommencer avec une nouvelle architecture du produit. En effet, l'architecture idéale de l'appli ne se dévoile généralement qu'au cours de la première mouture. Perso, je fais des petites appli web gratuites sur internet, je doute que dans le cadre d'une entreprise on ait le temps de tout refaire.

  5. #25
    Membre à l'essai
    Profil pro
    Inscrit en
    février 2010
    Messages
    29
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2010
    Messages : 29
    Points : 11
    Points
    11

    Par défaut

    je programme depuis 30 ans. Je regarde la façon de faire des jeunes loups. Sans avoir lu le sujet jusqu'au bout il commence à coder, son but : fournir un exe le plus vite possible. Oui il doit montrer au chef qu'il peut le faire. Et il le fait. bon c'est un peu bancale, y'a des bout de ficelle partout, y'a qu'une fonction, bon elle a 5000 lignes; mais il en en fière, ça marche !!! Et quand je lui dit que je préfère de loin un code bien écrit et qui ne marche pas à un code qui marche mais mal écrit, il ne comprend pas. Mais six mois plus tard, quand il doit modifier son code dont il était assez fière, je le vois s'arracher les cheveux c'est la qu'il comprend la nécessité de découper son code en de nombreuses fonctions et de bien lire le cahier des charges. Comme le dit le proverbe c'est en forgeant que l'on devient forgeron. Il faut du temps pour devenir un pro. Quand devient on pro ? Quand on a compris que l'important en programmation n'est pas un exe qui marche ni un minimum de temps pour le faire mais un code que même un débutant peu comprendre et modifier, quand le code écrit est votre fierté et non l'exe, quand vous avez compris que vous êtes capable de faire. Alors il ne vous reste plus qu' à bien faire et la vitesse viendra d'elle-même.

  6. #26
    En attente de confirmation mail

    Profil pro
    Inscrit en
    septembre 2013
    Messages
    642
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2013
    Messages : 642
    Points : 2 280
    Points
    2 280

    Par défaut

    Citation Envoyé par jovanovic.radoslav Voir le message
    (...) l'important en programmation (...) un code que même un débutant peu comprendre et modifier (...)
    Bonjour,

    D'accord avec l'ensemble de votre propos, mais le passage que je cite me semble un peu extrême et idéaliste. Dès qu'une application dépasse un certaine complexité, il n'est jamais facile de comprendre et modifier, que l'on soit débutant ou pas. Je parle d'une complexité "irréductible", pas d'une complexité superflue due au fait qu'on n'a pas réussi à écrire du code maintenable. C'est dur de modifier du code, en particulier à cause des "effets de bords"... malheureusement les langages populaires sont ceux qui encouragent à en mettre partout !

  7. #27
    Expert confirmé
    Avatar de Matthieu Vergne
    Homme Profil pro
    Consultant IT, chercheur IA indépendant
    Inscrit en
    novembre 2011
    Messages
    1 871
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Consultant IT, chercheur IA indépendant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2011
    Messages : 1 871
    Points : 5 939
    Points
    5 939
    Billets dans le blog
    2

    Par défaut

    Toute la question étant de savoir si ce que tu appelles "complexité irréductible" est effectivement irréductible par nature ou du fait des compétences du programmeur. Pour ma part, je tend à penser qu'une complexité n'est jamais irréductible par nature, même si c'est loin d'être une des tâches les plus simples. C'est de l'ordre du modèle conceptuel, et quand on touche à des paradigmes cela rend la chose d'autant plus difficile, mais pas impossible.
    Site perso
    Recommandations pour débattre sainement

    Références récurrentes :
    The Cambridge Handbook of Expertise and Expert Performance
    L’Art d’avoir toujours raison (ou ce qu'il faut éviter pour pas que je vous saute à la gorge {^_^})

Discussions similaires

  1. Pourquoi les développeurs travaillent-ils la nuit ?
    Par Gordon Fowler dans le forum Humour Informatique
    Réponses: 122
    Dernier message: 06/10/2013, 02h30
  2. Réponses: 22
    Dernier message: 29/12/2010, 10h44
  3. Les pirates ont-ils compris avant les autres l'avantage du Cloud?
    Par Hinault Romaric dans le forum Actualités
    Réponses: 9
    Dernier message: 24/11/2010, 15h34
  4. les jeux ont-ils un voir plusieurs points communs ?
    Par Invité dans le forum Modélisation
    Réponses: 2
    Dernier message: 04/11/2010, 16h20
  5. Les sessions ont-ils une taille limite?
    Par wormseric dans le forum Sessions
    Réponses: 1
    Dernier message: 26/03/2008, 11h11

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