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: 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%
Débats sur le développement - Le Best Of Discussion :

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


Sujet :

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

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Mars 2013
    Messages
    8 916
    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 : 8 916
    Points : 206 674
    Points
    206 674
    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
    6 807
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 807
    Points : 32 103
    Points
    32 103
    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".

  3. #3
    Membre confirmé Avatar de heid
    Profil pro
    Inscrit en
    Mai 2002
    Messages
    388
    Détails du profil
    Informations personnelles :
    Localisation : France, Indre et Loire (Centre)

    Informations forums :
    Inscription : Mai 2002
    Messages : 388
    Points : 597
    Points
    597
    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 confirmé
    Profil pro
    Inscrit en
    Janvier 2011
    Messages
    120
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Janvier 2011
    Messages : 120
    Points : 461
    Points
    461
    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 actif
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Août 2015
    Messages
    45
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    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 : 45
    Points : 221
    Points
    221
    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 éclairé
    Profil pro
    Inscrit en
    Décembre 2006
    Messages
    614
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2006
    Messages : 614
    Points : 714
    Points
    714
    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 expérimenté Avatar de Cincinnatus
    Homme Profil pro
    Développeur d'applications métier
    Inscrit en
    Mars 2007
    Messages
    592
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur d'applications métier
    Secteur : Service public

    Informations forums :
    Inscription : Mars 2007
    Messages : 592
    Points : 1 681
    Points
    1 681
    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 sénior
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2005
    Messages
    4 413
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Août 2005
    Messages : 4 413
    Points : 19 609
    Points
    19 609
    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.

  9. #9
    Membre émérite
    Avatar de Voyvode
    Profil pro
    Inscrit en
    Mars 2007
    Messages
    476
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2007
    Messages : 476
    Points : 2 678
    Points
    2 678
    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
    139
    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 : 139
    Points : 516
    Points
    516
    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...

  11. #11
    Membre averti
    Profil pro
    Inscrit en
    Juin 2006
    Messages
    187
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2006
    Messages : 187
    Points : 433
    Points
    433
    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 expérimenté

    Homme Profil pro
    retraité
    Inscrit en
    Novembre 2004
    Messages
    389
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : retraité
    Secteur : Service public

    Informations forums :
    Inscription : Novembre 2004
    Messages : 389
    Points : 1 595
    Points
    1 595
    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
    841
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Ille et Vilaine (Bretagne)

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

    Informations forums :
    Inscription : Juin 2003
    Messages : 841
    Points : 1 474
    Points
    1 474
    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!

  14. #14
    Expert éminent
    Avatar de Matthieu Vergne
    Homme Profil pro
    Consultant IT, chercheur IA indépendant
    Inscrit en
    Novembre 2011
    Messages
    2 270
    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 : 2 270
    Points : 7 792
    Points
    7 792
    Billets dans le blog
    3
    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.

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

    Informations forums :
    Inscription : Décembre 2006
    Messages : 614
    Points : 714
    Points
    714
    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 éclairé
    Profil pro
    Inscrit en
    Décembre 2006
    Messages
    614
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2006
    Messages : 614
    Points : 714
    Points
    714
    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 éminent
    Avatar de Matthieu Vergne
    Homme Profil pro
    Consultant IT, chercheur IA indépendant
    Inscrit en
    Novembre 2011
    Messages
    2 270
    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 : 2 270
    Points : 7 792
    Points
    7 792
    Billets dans le blog
    3
    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.

  18. #18
    En attente de confirmation mail

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

    Informations forums :
    Inscription : Septembre 2013
    Messages : 639
    Points : 2 347
    Points
    2 347
    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
    Inactif  
    Profil pro
    Inscrit en
    Août 2008
    Messages
    238
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2008
    Messages : 238
    Points : 620
    Points
    620
    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
    Membre émérite

    Profil pro
    Inscrit en
    Décembre 2003
    Messages
    3 995
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2003
    Messages : 3 995
    Points : 2 522
    Points
    2 522
    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.

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