Affichage des résultats du sondage: Quel est le paramètre à privilégier lors de la rédaction du code ?

Votants
48. Vous ne pouvez pas participer à ce sondage.
  • La vitesse

    1 2,08%
  • La qualité du code

    29 60,42%
  • Aucun des deux ne doit primer sur l'autre

    15 31,25%
  • Un autre paramètre (à préciser en réponse)

    3 6,25%
+ Répondre à la discussion Actualité déjà publiée
Page 1 sur 2 12 DernièreDernière
  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    mars 2013
    Messages
    2 593
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : mars 2013
    Messages : 2 593
    Points : 54 275
    Points
    54 275

    Par défaut Que devons-nous privilégier dans la rédaction de notre code ? La vitesse ou la qualité ?

    Que devons-nous privilégier dans la rédaction de notre code ? La vitesse ou la qualité ?
    Étude du cas de Facebook

    Si ces deux notions sont importantes, laquelle doit primer ? Pour le développeur Graham King, la qualité semble être le facteur le plus important. Il essaye de le montrer en donnant trois éléments qui le conduisent à penser que Facebook a des problèmes dans la qualité de son code. « Je ne travaille ni chez Facebook ni chez la concurrence. Je suis juste un observateur », précise-t-il.

    Élément numéro 1 : « iOS ne peut pas gérer notre taille »

    Il y a près d’un mois, Simon Whitetaker, ingénieur logiciel Facebook à Londres, a fait la présentation « iOS at Facebook » qui parlait de l’application Facebook sur l’écosystème iOS. Il était notamment question d’expliquer la raison pour laquelle Facebook se trouvait être volumineux chez les utilisateurs des iDevices et il avançait que « il y a plus de 18 000 classes dans l’application (…) raison pour laquelle l’application binaire elle-même fait plus de 114 Mo ».

    Après avoir rappelé que l’application Facebook sur la plateforme iOS a plus de 18 000 classes Objective-C, King a précisé qu’en une seule semaine 429 personnes y ont contribué : « c’est-à-dire que 429 personnes ont en quelque sorte travaillé sur l’application iOS de Facebook. Au lieu de réaliser l’évidence qui veut qu’il y ait eu trop de personnes qui ont travaillé sur cette application, la présentation blâme tout, du git jusqu’au Xcode, pour ces 18 000 classes ».

    D’ailleurs un commentaire de l’utilisateur ChadBan sur Reddit le résume assez bien : « tout ce à quoi je peux penser quand je lis ça c’est à Design Stamina Hypothesis de Martin Fowler sur ce qui arrive sur un système sans architecture. Il devient plus difficile et cela prend plus de temps d’ajouter de nouvelles fonctionnalités contrairement à un système pour lequel l’architecture est d’or. La solution de Facebook pour une courbe en baisse semble de balancer plus de développeurs dessus jusqu’à ce qu’elle se plie vers l’orientation désirée. Je ne voudrais pas que qui que ce soit dans ma petite équipe pense c’est ce que les enfants cool font. Je ne voudrais pas avoir à travailler de cette façon, même si elle marche pour eux ».

    Élément numéro 2 : peut-être penser à l’utilisation des RAMDisk ?

    En juin de l’année 2014, les ingénieurs Facebook ont publié un article intitulé « Fast Database Restarts at Facebook » qui parlait du redémarrage des serveurs qu’ils utilisent en étudiant le cas du plus rapide d’entre eux : Scuba. Si King s’y est intéressé, c’est en particulier parce que dans le synopsis, les ingénieurs ont noté que « notre principale observation est que nous pouvons dissocier la durée de vie de la mémoire de la durée de vie du processus ».

    King rappelle que l’idée est semblable à la sauvegarde des données dans la mémoire cache distribuée ou dans Redis, le système de gestion de bases de données clef-valeur scalable, puis redémarrer votre processus et enfin aller récupérer les données que vous avez sauvegardées, la seule différence étant qu’ils gardent les données dans la mémoire partagée au lieu de Memcached ou Redis. « La partie de la mémoire partagée est juste un leurre, mais il faut lire l’article jusqu’à la conclusion pour le comprendre », avance-t-il.

    Ils maintenaient déjà les données sur le disque entre les redémarrages, mais la recharge à partir des disques étaient trop lente : « la lecture de près de 120 Go de données sur le disque prend entre 20 et 25 minutes, la lecture de ces données dans leur format disque et les convertir dans le format en mémoire peut prendre 2,5 ou 3 heures », ont expliqué les ingénieurs. Le disque ne les ralentit pas, c’est plutôt le format de conversion comme le montre la conclusion : « la conversion du format disque pour le format mémoire est une surcharge de récupération importante. Nous envisageons d’utiliser le format de la mémoire partagée décrite dans ce document comme étant le format du disque ». Aussi, King précise que ce qu’ils ont fait c’est d’écrire un nouveau code pour sauvegarder/recharger qui fonctionne avec la mémoire partagée avec son propre nouveau format de conversion.

    « Si vous avez lu Kerrisk, vous remarquerez à la page 275 (section 14.10) que la mémoire partagée sur Linux est implémentée avec le système de fichiers tmpfs et tempfs est la façon dont Linux fait des disques virtuels, qui « ne consomment qu’autant de mémoire et d’espace d’échange qu’actuellement requis par les fichiers qu’ils détiennent » précise King.

    Aussi, si vos routines de conversion de format de sauvegarde sur le disque ralentissent votre code, que vous deviez avoir à les réécrire de toutes les façons et que vous vouliez « dissocier la durée de vie de la mémoire de la durée de vie du processus », ne préféreriez-vous pas juste écrire vos fichiers de disque sur un disque virtuel ? Ils ont sans nul doute dû le remarquer, mais alors il devait être trop tard, ils devaient avancer rapidement et publier des choses ».

    Élément numéro 3 : notre site fonctionne quand nos ingénieurs vont en vacances

    « Étant donné que Facebook encourage ses ingénieurs dans la philosophie ‘Move Fast And Break Things’, il est aisé de s’attendre à plusieurs erreurs d’origine humaine. Nos données suggèrent que l’erreur humaine est un facteur de nos échecs. La figure 1 comprend des données issues d’une analyse de la chronologie des évènements suffisamment sévère pour être considérées comme étant une violation SLA. Chaque violation indique une instance où nos objectifs de fiabilité interne n’ont pas été atteints et ont provoqué la génération d’une alerte. Parce que nos objectifs sont stricts, la plupart de ces incidents sont mineurs et ne vont pas causer de changements perceptibles par l’utilisateur », va rapporter Fail at Scale.


    « La figure 1a montre comment les incidents se sont beaucoup moins produits le samedi et le dimanche, même si le trafic est resté consistant tout au long de la semaine. La figure 2b montre une période de six mois durant laquelle seules deux semaines n’ont pas enregistré d’incidents, notamment la semaine de Noël et la semaine où les employés sont tenus de faire des peer reviews ».

    Pour King, malgré le succès de Facebook, ses ingénieurs talentueux, ses ressources illimitées, le réseau social a quand même de grosses difficultés avec la qualité du code. Il tire donc deux leçons :

    • la culture de l’entreprise importe : la culture qui veut que les employés suivent la philosophie « Move Fast And Break Things » qui fait que les développeurs se concentrent difficilement sur la qualité ;
    • la qualité importe : étant donné que si vous ne vous concentrez pas sur la qualité, cela pourrait se faire à vos dépens. Tout d’abord parce que faire des changements, aussi petits soient-ils, pourrait s’avérer très pénible, mais également parce que les publications pourraient provoquer des bogues parce que vous ne comprendrez plus suffisamment bien les relations.



    Quoi qu’il en soit, en avril 2014, lors de la conférence F8, le PDG de Facebook a fait évoluer la philosophie « Move Fast and Break Things » qui est devenue « Move Fast With Stable Infra ». Il a expliqué que « nous avons utilisé ce fameux mantra et l’idée était qu’en tant que développeurs, être rapides était si important que nous étions même prêts à tolérer quelques bogues mineurs pour y parvenir. Ce que nous avons réalisé avec le temps c’est que cela ne nous aidait pas à être rapides parce que nous devions ralentir pour corriger ces bogues, et cela n’améliorait en rien notre vitesse ».



    Source : billet de blog Graham King, Simon Whitaker, Fast Database Restarts at Facebook, Fail at Scale

    Et vous ?

    Que pensez-vous des arguments qu'il a avancés ? Pensez-vous qu'ils suffisent pour pouvoir parler d'un problème dans la qualité du code de Facebook ? Partagez-vous son avis ?

    De la vitesse et de la qualité, quel est le paramètre à privilégier ? Pourquoi ?

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 4 434
    Points : 17 943
    Points
    17 943

    Par défaut

    Je ne connais pas Facebook et je m'abstiendrait prudemment de porter le moindre jugement sur la qualité de leur code ou de leurs méthodes. Par contre, "De la vitesse et de la qualité, quel est le paramètre à privilégier ? Pourquoi ?", ça, ça me fait réagir. Parceque c'est une mauvaise question.

    La seule réponse possible est : "ça dépend". Si vous êtes sur un marché concurrentiel à la dynamique rapide, alors sortir la fonctionnalité à tout prix avant les autres est une question de survie. Dans la plupart des autres cas, si on peut se projeter à plus de 3 mois dans l'avenir, la qualité sera primordiale. Et encore, il peut y avoir des milliards d'exceptions. La seule stratégie valable, c'est celle qui colle à nôtre position actuelle. Pas une stratégie prédéfinie "parce que".
    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. #3
    Membre confirmé Avatar de heid
    Profil pro
    Inscrit en
    mai 2002
    Messages
    379
    Détails du profil
    Informations personnelles :
    Localisation : France, Indre et Loire (Centre)

    Informations forums :
    Inscription : mai 2002
    Messages : 379
    Points : 551
    Points
    551

    Par défaut

    En fait a règle est simple, à réaliser dans l'ordre :

    • Make it work
    • Make it clean
    • Make it fast

  4. #4
    Membre averti
    Profil pro
    Inscrit en
    janvier 2011
    Messages
    106
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : janvier 2011
    Messages : 106
    Points : 414
    Points
    414

    Par défaut

    Ce que nous avons réalisé avec le temps c’est que cela ne nous aidait pas à être rapides parce que nous devions ralentir pour corriger ces bugs, et cela n’améliorait en rien notre vitesse.
    Ils ont pas inventés l'eau chaude chez Facebook. Je pense que tout développeur, contrairement à certains dirigeant, considèrent évident que quand on néglige la qualité du code on le paye plus tard. Le "Move fast" à l'air plutôt une politique managériale d'un autre temps où on met en concurrence les employés sous pression.

  5. #5
    Membre régulier
    Homme Profil pro
    Développeur .NET
    Inscrit en
    août 2015
    Messages
    14
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : août 2015
    Messages : 14
    Points : 76
    Points
    76

    Par défaut

    Je ne connais pas Facebook et je m'abstiendrait prudemment de porter le moindre jugement sur la qualité de leur code ou de leurs méthodes. Par contre, "De la vitesse et de la qualité, quel est le paramètre à privilégier ? Pourquoi ?", ça, ça me fait réagir. Parceque c'est une mauvaise question.

    La seule réponse possible est : "ça dépend". Si vous êtes sur un marché concurrentiel à la dynamique rapide, alors sortir la fonctionnalité à tout prix avant les autres est une question de survie. Dans la plupart des autres cas, si on peut se projeter à plus de 3 mois dans l'avenir, la qualité sera primordiale. Et encore, il peut y avoir des milliards d'exceptions. La seule stratégie valable, c'est celle qui colle à nôtre position actuelle. Pas une stratégie prédéfinie "parce que".
    Il n'y a rien à ajouter. Le dogmatisme fait des ravages et plante de nombreux projets. Savoir faire preuve d'un minimum de pragmatisme, savoir utiliser la bonne méthode au bon moment est peut être la seule règle à ne jamais enfreindre.
    Le quick and dirty est quelque fois salvateur. J'ai de nombreux exemples de code de production, avec des parties vraiment écrites à l'arrache, qui n'ont au final jamais posé le moindre soucis après des années (il aurait été donc vraiment stupide de perdre du temps à refactoriser tout ça proprement). Mais on peut trouver autant ou plus d'exemple ou cela mène à la catastrophe.
    L'expérience et surtout le bon sens sont là pour nous guider.

  6. #6
    Membre averti
    Profil pro
    Inscrit en
    décembre 2006
    Messages
    402
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2006
    Messages : 402
    Points : 408
    Points
    408

    Par défaut

    Comme certains ici, je trouve la question est un peu absurde surtout lorsque avec terme comme "Qualité" qui veut tout et rien dire dans le domaine de l'IT. Si je prends l'"élément N°1", l'architecture n'est pas de la qualité.

    Là dessus, la question reste le contexte. Sur un marché concurrentiel et innovant (sauf biotech), la devise est "you ship then you debug". Mais ça ne veut pas dire manquer de "qualité". Par contre, on sait très bien que plus on fait "sale", plus la maintenance et l'évolution sont compliqués (donc lents).

    Par contre, je trouve amusant la remarque du point 1 où l'intervenant "n'aimerait pas avoir à travailler de cette façon". Moi non plus, pourtant en SSII aussi bien en interne que chez le client, j'ai toujours vu travailler comme ça... Il faut dire que le point abordé (volume gargantuesque qu'une app) a été une petite révolution depuis le mobile vu que pour le backend, le volume de l'applicatif, on s'en fiche (fichait ?) Après tout, si manque de perf, il suffirait de rajouter un serveur au cluster (réellement entendu...).

    Après plus de 15 ans dans le domaine, je dirai qu'en pratique, la "qualité" est primordiale pour animer les discussion à la machine à café et que la "vitesse" est primordiale pour satisfaire le management.

  7. #7
    Membre averti Avatar de Cincinnatus
    Homme Profil pro
    Développeur Java
    Inscrit en
    mars 2007
    Messages
    159
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : Service public

    Informations forums :
    Inscription : mars 2007
    Messages : 159
    Points : 437
    Points
    437

    Par défaut

    La qualité fait au final gagner du temps. Bien sûr, la qualité nécessaire, pas de la sur-qualité, synonyme de surcoûts, de perte de temps...
    La sous-qualité amène directement à la case "Dette technique".

  8. #8
    Expert éminent Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2005
    Messages
    2 344
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : août 2005
    Messages : 2 344
    Points : 6 740
    Points
    6 740

    Par défaut

    Je trouve que c'est une bonne question mais elle date pas d'hier.

    De mon point de vue qualité signifie : code propre, lisible, documentation à jour, TU à jours, peu de bugs en attente, intégration continue, peu de dette technique, etc ... Je pourrais continuer longtemps. Il ne s'agit pas simplement de la qualité du code en lui même mais de ce qui est autour du projet du recueil du besoin jusqu'à la livraison.

    Meilleure est la qualité, moins couteuse est la TMA, plus rapide est le TTM.

    Si on privilégie la vitesse, on dégrade la qualité, donc on augmente le cout de la TMA, et on perd de plus en plus en réactivité (TTM qui s'allonge).
    Les managers préfèrent donc la vitesse parce qu'ils ne voient pas plus loin que le bout de leur nez pour la plupart. Et c'est une erreur parce que cette décision ne peut pas être du ressort d'un seul type de personnel. Ca doit nécessairement être un consensus technique (dangerosité de la dégradation de la qualité) et commercial (réactivité sur tel ou tel point de livraison pour des raisons commerciales).

    De plus une dégradation de la qualité induit une augmentation du cout des prochaines itérations. Cela doit également être pris en compte.

    Bref, sur un tel sujet dommage de se focaliser sur un aspect du problème (le code), c'est plus vaste et plus intéressant que ça.
    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

    Trust me, i'm an engineer !
    https://www.youtube.com/watch?v=rp8hvyjZWHs

  9. #9
    Membre émérite
    Avatar de Voïvode
    Profil pro
    Inscrit en
    mars 2007
    Messages
    432
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2007
    Messages : 432
    Points : 2 476
    Points
    2 476

    Par défaut

    Citation Envoyé par Stéphane le calme Voir le message
    « il y a plus de 18 000 classes dans l’application (…) raison pour laquelle l’application binaire elle-même fait plus de 114 Mo »
    Inutile d’aller plus loin. Un blogueur a déchiffré l’application pour en obtenir la liste des 18 847 entêtes de classe. (Attention, la page peut mettre du temps à charger.)

    Par comparaison, Cocoa et Java SE ne dépassent même pas les 5 000 classes.

    On comprend mieux pourquoi ils avaient du mal avec les applications web…

    Citation Envoyé par Stéphane le calme Voir le message
    De la vitesse et de la qualité, quel est le paramètre à privilégier ? Pourquoi ?
    La qualité et la clarté sont indispensables pour faciliter l’analyse et savoir quoi optimiser.

    Une exception : au-delà de 18 000 classes, on transcende ces considérations vulgaires et bassement techniques de qualité et de performance. C’est la métaphysique qui prend le relai.

  10. #10
    Membre confirmé
    Avatar de vinmar
    Homme Profil pro
    Développeur Web
    Inscrit en
    août 2012
    Messages
    131
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : Service public

    Informations forums :
    Inscription : août 2012
    Messages : 131
    Points : 505
    Points
    505

    Par défaut

    De toute manière, peu importe l'environnement si la qualité n'est pas au rendez-vous, on se retrouvera toujours face à une montagne : évolution impossible, solutions de contournement, bricolage, application anxiogène, chef de projet pas content, client pas content, dev pas content, ... => dépression collective.

    Après, il faut définir ce que le mot qualité cache...
    M. Lebowski : Avez-vous un emploi, monsieur ?
    Le Duc : Un emploi ?
    M. Lebowski : Ne me dites pas que vous cherchez un emploi dans cette tenue un jour de semaine ?
    Le Duc : Un jour de… Quel jour on est ?

  11. #11
    Membre actif
    Profil pro
    Inscrit en
    juin 2006
    Messages
    152
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2006
    Messages : 152
    Points : 288
    Points
    288

    Par défaut

    Qualité à privilégier, y compris sur le fait que ça fonctionne.

    Un code propre avec quelques bugs ça se corrige et ça s'optimise, un code immonde mais qui fonctionne c'est une dette technique pour l'avenir.

  12. #12
    Membre confirmé

    Homme Profil pro
    Privacy, EBusiness, Bases de données, Sécurité, ...
    Inscrit en
    novembre 2004
    Messages
    138
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Privacy, EBusiness, Bases de données, Sécurité, ...
    Secteur : Service public

    Informations forums :
    Inscription : novembre 2004
    Messages : 138
    Points : 507
    Points
    507

    Par défaut

    Mark Zuckerberg est un radin.

    429 personnes ont produit un binaire de 114 Mo concernant plus de 18000 classes Objective-C
    Il aurait pu engager*:
    2x3x429 =2574 développeurs travaillant en 3x8h/jour, le travail aurait été fait en 1 jour au lieu d'une semaine*!
    Et chaque développeur n'aurait eu à s’occuper que de 18000/2574= +/-7 classes par développeur*!!!

    Absurde n'est-il pas*?

  13. #13
    Membre expérimenté Avatar de shkyo
    Homme Profil pro
    Développeur Robotique - Administrateur systèmes
    Inscrit en
    juin 2003
    Messages
    831
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Développeur Robotique - Administrateur systèmes

    Informations forums :
    Inscription : juin 2003
    Messages : 831
    Points : 1 396
    Points
    1 396

    Par défaut

    Je plussois la plupart de ce qui est dit, la qualité d'un code fera TOUJOURS gagner du temps à court, moyen, et long (!) terme...

    Pour avoir parfois du mettre le nez dans des bricolages fait à l'arrache, sans doc, sans rien, avec le dév qui n'est plus là depuis un bon bout de temps, c'est très clair que les trucs pondus en vitesse, tôt ou tard, tu le payes cash!
    L'homme sage apprend de ses erreurs, l'homme plus sage apprend des erreurs des autres. - Confucius -

    Pour les fans de SF "à l'anglo-saxone", voici un bon roman de SF, (écrit par ma moitié... ), il suffit de s'inscrire au panel des lecteurs pour le lire gratuitement et l'évaluer... Il est là: L'Archéofoetus

    Si vous avez quelques minutes, passez donc voir mon site http://www.photospicsandco.fr/
    Envie de tee-shirts (et goodies!) originaux et sympa ? Visitez mon site... http://www.zazzle.com/shkyo30

  14. #14
    Expert confirmé
    Avatar de Matthieu Vergne
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    novembre 2011
    Messages
    1 726
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2011
    Messages : 1 726
    Points : 5 454
    Points
    5 454
    Billets dans le blog
    2

    Par défaut

    J'ai répondu aucun des deux car je considère le cas général, mais si je me limite à ma propre personne c'est qualité d'abord. Si je bosse dans une entreprise où la rapidité prime et parler de qualité se conclue par des rires bien gras, je plie bagage sur le champs. Si la rapidité prime en sachant bien que la qualité est importante (question de contrainte donc), je vois ce que je peux apporter avant de plier bagage (en faire un peu ne peut pas faire de mal).

    Les cas où la rapidité se doit de primer sur la qualité sont avant tout des cas de survie, et je ne parle pas de survie d'une entreprise (si une entreprise meurs, c'est qu'on a mal fait les choses, donc on arrête les bêtises, on tire des leçons et on repart d'une base saine, y'a pas mort d'homme) mais bien de survie humaine (i.e. cas critique qu'on voit dans l'armée, le médical, etc.). En dehors de ces cas là, la rapidité est surtout de l'ordre de la masturbation : on aime se sentir être le premier. C'est comme bachoter à fond pour avoir une super note au contrôle de demain en sachant pertinemment que le mois prochain on ne se souviendra plus de rien.

    Donc oui ça dépend, mais dans mon cas ce ne sont pas les cas critiques qui m'intéressent, la qualité est donc n°1 sur ma liste. Et je pense que c'est le cas pour beaucoup vu la tête du sondage : si on est très dispersés entre qualité d'abord et ça dépend, on est au moins tous d'accord que la rapidité n'a pas à passer d'abord.
    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 {^_^})

  15. #15
    Membre averti
    Profil pro
    Inscrit en
    décembre 2006
    Messages
    402
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2006
    Messages : 402
    Points : 408
    Points
    408

    Par défaut

    Citation Envoyé par Washmid Voir le message
    Qualité à privilégier, y compris sur le fait que ça fonctionne.

    Un code propre avec quelques bugs ça se corrige et ça s'optimise, un code immonde mais qui fonctionne c'est une dette technique pour l'avenir.
    "Y compris sur le fait que ça fonctionne" ???

    Là j'aimerai bien savoir quel profil de personne publie ça... Un code qui ne tourne pas est un code qui ne sert à rien. Écrire un "beau code de qualité" n'a en soi aucun intérêt tant qu'il n'est pas en production. Je développe juste ci-dessous du fait du besoin d'une autre citation.

  16. #16
    Membre averti
    Profil pro
    Inscrit en
    décembre 2006
    Messages
    402
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2006
    Messages : 402
    Points : 408
    Points
    408

    Par défaut

    Citation Envoyé par Matthieu Vergne Voir le message
    Les cas où la rapidité se doit de primer sur la qualité sont avant tout des cas de survie, et je ne parle pas de survie d'une entreprise (si une entreprise meurs, c'est qu'on a mal fait les choses, donc on arrête les bêtises, on tire des leçons et on repart d'une base saine, y'a pas mort d'homme) mais bien de survie humaine (i.e. cas critique qu'on voit dans l'armée, le médical, etc.). En dehors de ces cas là, la rapidité est surtout de l'ordre de la masturbation : on aime se sentir être le premier. C'est comme bachoter à fond pour avoir une super note au contrôle de demain en sachant pertinemment que le mois prochain on ne se souviendra plus de rien.
    C'est tout de même une vision très réductrice du développement logiciel. La "rapidité", c'est une question de délais, et il ne s'agit pas uniquement d'être les "premiers", mais également simplement "d'y être". Pour une app/site promotionnel lié à un évènement, si le service n'est pas en ligne lors du lancement de cet évènement, le développement n'a servi à rien, poubelle, personne ne verra le résultat du "beau code de qualité sous-jacent". Si le service lié à l'e-commerce n'est pas en ligne pour le Black Friday et la période avant Noel, le site d'e-commerce perd de l'ordre de 10% de ses revenus annuels. Si, ça peut signifier la mort de l'entreprise ou au moins quelques emplois...

    Dans le contexte de mon premier cas, le plus souvent, la "qualité", on s'en fiche complètement. Le service est ponctuel, la maintenance inexistante et le tout sera benné à la fin de l'évènement. Certains peuvent argumenter sur la réutilisabilité... Bonne chance... Dans le second cas... Ça dépend et en effet, ça peut conduire à une dette technique et les couts associés. Reste à voir si cette dette a un cout inférieur que ne pas être présent sur le marché.

    Je suis développeur (à la base), je suis en faveur d'un "code de qualité", mais il faut que les développeurs comprennent que le code est écrit pour être exécuté, pas admiré. La première priorité d'un dev devrait être de mettre en production, à lui d'assurer la qualité qui va avec.

  17. #17
    Expert confirmé
    Avatar de Matthieu Vergne
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    novembre 2011
    Messages
    1 726
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2011
    Messages : 1 726
    Points : 5 454
    Points
    5 454
    Billets dans le blog
    2

    Par défaut

    Citation Envoyé par martopioche Voir le message
    Je suis développeur (à la base), je suis en faveur d'un "code de qualité", mais il faut que les développeurs comprennent que le code est écrit pour être exécuté, pas admiré. La première priorité d'un dev devrait être de mettre en production, à lui d'assurer la qualité qui va avec.
    Faut pas être de mauvaise foi non plus : qui a parlé d'admirer du code ? On parle de vision sur le long terme plutôt que court terme. Je suis d'accord qu'un site prévu pour un événement doit être fonctionnel le jour J, mais le truc est que ceux qui devront faire rapidos sont ceux qui en auront espéré trop étant donné le temps disponible (i.e. trop gourmand ou préparé trop tard). Ceux qui s'y seront pris en avance ou qui sauront définir leurs priorités auront tout le loisir de faire un site avec un code de qualité (indépendamment de la qualité du rendu qui fait appel à d'autres compétences).

    J'ai dû par exemple faire un site pour une conférence (dates fixées donc) et ce fut une partie de plaisir malgré que ça s'ajoutait à mon travail quotidien et que je reprenais un code existant (une des tâches les plus difficiles, semble-t-il) : réécriture de certaines parties, factorisation pour éviter les répétitions, petites automatisations, ... j'ai pris le temps de le faire, comme ça si quelqu'un souhaite le réutiliser pour une future conférence ça sera d'autant plus facile.

    Ce n'est pas parce que le code est jetable qu'il faut le faire rapidement, c'est parce qu'on le fait rapidement que ça se limitera à du code jetable. Fait du bon code et tu verras de nouvelles occasions pour le réutiliser, au moins en partie. Il est très rare qu'un besoin ne se présente qu'une seule fois dans une vie.
    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 {^_^})

  18. #18
    Membre expérimenté Avatar de CodeurPlusPlus
    Profil pro
    Inscrit en
    septembre 2013
    Messages
    515
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2013
    Messages : 515
    Points : 1 629
    Points
    1 629

    Par défaut

    N'oublions pas non plus qu'il y a en poste des développeurs totalement infoutus d'écrire du code maintenable... et qui trouveront toujours des excuses pour se justifier.

  19. #19
    Membre actif
    Profil pro
    Inscrit en
    août 2008
    Messages
    110
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2008
    Messages : 110
    Points : 288
    Points
    288

    Par défaut

    La qualité/clarté du code, bien sûr. Il n'y a pas débat.
    car tout développeur qui se respecte sait que l'exécution d'une logiciel passe 90 % du temps dans 10 % du code.
    Les profilers, un peu oubliés, semble-t'il sont là pour vous dire où.

  20. #20
    Expert éminent sénior

    Inscrit en
    décembre 2003
    Messages
    3 965
    Détails du profil
    Informations forums :
    Inscription : décembre 2003
    Messages : 3 965
    Points : 10 149
    Points
    10 149

    Par défaut

    Voila bien une discussion de notre époque, où on cherche à avoir des réponses applicables dans tous les cas plutôt que de déterminer quelle est la bonne solution dans une situation réelle.
    J'appelle "Point Traroth" le moment dans une discussion où quelqu'un parle des Bisounours. A partir de ce moment, toute discussion sérieuse devient impossible, puisque la légitimité d'une des parties pour exposer son point de vue est mise en cause. C'est juste un anathème, un moyen de décrédibiliser les autres sans avoir à discuter.

Discussions similaires

  1. Un développeur estime que nous vivons dans l’âge des logiciels ratés
    Par Michael Guilloux dans le forum Débats sur le développement - Le Best Of
    Réponses: 111
    Dernier message: 07/12/2015, 13h32
  2. Que serons nous dans 100 ans?
    Par newbie57 dans le forum La taverne du Club : Humour et divers
    Réponses: 28
    Dernier message: 19/03/2008, 15h41
  3. est ce que un champs existe dans la base?
    Par cha_cha dans le forum Langage SQL
    Réponses: 9
    Dernier message: 03/10/2005, 11h25

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