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

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Stéphane le calme

88PARTAGES

7  0 
Quel est le paramètre à privilégier lors de la rédaction du code ?
La qualité du code
60 %
Un autre paramètre (à préciser en réponse)
6 %
La vitesse
2 %
Aucun des deux ne doit primer sur l'autre
31 %
Voter 48 votants
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 ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 04/11/2015 à 9:15
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".
11  0 
Avatar de FraisDesRiques
Membre actif https://www.developpez.com
Le 04/11/2015 à 10:02
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.
7  0 
Avatar de Matthieu Vergne
Expert éminent https://www.developpez.com
Le 05/11/2015 à 18:07
Citation Envoyé par martopioche Voir le message
Waw... Merci de cette présomption de la qualité du code que je produit...
Si je comprends que tu puisses avoir cette interprétation, ce n'est ni la seule ni celle espérée. C'était une phrase générale (tu peux remplacer les "tu" par des "on". Je ne sais pas comment tu codes et je m'en fiche, à toi de voir comment tu veux coder.

Citation Envoyé par martopioche Voir le message
Pour votre projet, quel était le cahier des charges ? Quel était le cout estimé ? Quel était le cout consommé ? Quel était le taux d'utilisation ? Quel était la satisfaction des utilisateurs ? Quel est le ROI ? Combien de participants avez-vous réussi à faire venir venir de plus à votre conf par rapport aux confs concurrentes au même moment ?

Ces questions paraissent hors de propos ? Pourtant, dans le cadre d'un projet commercial, c'est celles qui intéressent en priorité.
Je vais sûrement me prendre des -1 mais j'assume.

Ces questions intéressent qui ? À part le cahier des charges et la satisfaction des utilisateurs, les autres questions ne sont pas du ressort du développeur. Un projet c'est pas des décideurs et des ouvriers qui suivent, c'est un ensemble de personnes travaillant avec des objectifs en communs. Les développeurs ne sont pas des pisseurs de code. Ils ne sont pas là uniquement pour répondre au besoin que d'autres ont décidé. Eux aussi ont des besoins, ainsi que des compétences à faire valoir dans le processus de décision. De la même manière, qu'on ne vienne pas me dire que le commercial est un gars super rationnel qui ne pense qu'à la maximisation du ROI. Qu'on ne vienne pas me dire que le patron ne s'intéresse qu'à la survie de son entreprise. L'entreprise est une chose, mais sans l'humain il n'y en aurait pas. Alors il est où l'humain dans tes questions ? En dehors des utilisateurs, nulle part. Les gars qui bossent ils en tirent quoi de leur boulot ? Du fric et c'est tout ? Quand tu dis que ces questions sont primordiales, tu ne trouves pas qu'on oublie quelque chose ?

Avec ce genre de raisonnement, on en arrive aux comportement publicitaires actuels : personne n'en veut mais comme c'est rentable on continue. On en arrive à des fraudes sur les tests de voitures, après tout le cahier des charges dit seulement qu'il faut passer les tests. Le chiffre passe avant, l'humain (éthique inclue) passe après. C'est précisément sur ce point que les plus grands polémiqueurs sur l'IA insistent [1][2][3] : la machine n'a pas nos valeurs, il faut donc se protéger de ses dérives. J'adore d'ailleurs les arguments de Wozniak, qui met justement le doigt dessus :
If we build these devices to take care of everything for us, eventually they'll think faster than us and they'll get rid of the slow humans to run companies more efficiently.
Mais à bien y regarder, est-ce qu'on fait mieux ? Tes questions elles visent quoi ? Elles mettent quoi au centre ? C'est quoi l'objectif principal ? Moi je vois que c'est la survie de l'entreprise le moteur, et cela passe par faire du chiffre. Satisfaire les utilisateurs ? Motiver ses employés ? Ça ce sont les moyens pour préserver l'entreprise, et non pas l'inverse. Si on peut faire du chiffre sans satisfaire les humains impliqués, on le fait. Et c'est ce genre de dérives qu'on s'effraye d'avoir au travers des IA, alors que c'est précisément ce qu'on fait nous-même et qui est à la source des scandales et autres procès qu'on voit fleurir chaque jour.

Alors tes questions, je suis d'accord qu'elles sont importantes. Mais de là à dire qu'elles sont primordiales... les entreprises, ou peu importe comment on les a appelé, existent depuis bien avant qu'on utilise des concepts de coût, ROI et consort. Il serait peut-être temps de faire preuve d'un peu de sagesse plutôt que de se "masturber" avec des tartines de jargon. Ce n'est pas le cahier des charges qui est important, c'est le besoin utilisateur. Ce n'est pas le coût estimé qui est important, c'est les ressources qu'on est collectivement près à investir (temps, argent, etc.) pour réussir le projet. Ce n'est pas le coût réel qui est important, c'est les leçons qu'on peut tirer de nos erreurs pour faire mieux la prochaine fois. Tes questions se réfèrent à des parties chiffrables de ce qui est primordial, et non à ce qui est primordial.

Citation Envoyé par martopioche Voir le message
À nouveau, je ne dis pas que la qualité doit être sacrifiée sur l'autel de la rapidité, je n'ai jamais écris ça ! Mais considérer que la qualité doit primer sur la "rapidité de mise en prod'" n'est qu'un caprice de développeur (qui en soi ne doit pas être très performant niveau "qualité" complètement déconnecté des réalités de sa fonctions. Sauf peut être dans le domaine universitaire où il n'y a pas de contraintes économiques (j'en viens).
À cela je répondrai deux choses.

Primo, si je me fie au sondage, il semble qu'une proportion significative de développeurs sur DVP soient des développeurs capricieux (qui en soi ne doivent pas être très performants niveau "qualité" complètement déconnectés des réalités de leur fonction.

Secundo, les plus grands experts sont ceux qui disposent (i) d'une pratique volontaire (i.e. amélioration continue) et (ii) d'un bon coach (i.e. feedback productif). Je m'appuie pour cela sur des ténors dans la recherche sur l'expertise, mais si tu veux plus de détails je te conseille de jeter un œil à ma signature. La qualité, c'est une valeur de travailleur compétent et efficace.

Mais même si on débat, au fond on pense tous les deux la même chose : tout dépend du contexte, il n'y a pas de règle absolue. On a juste chacun nos priorités.
5  0 
Avatar de Voyvode
Membre émérite https://www.developpez.com
Le 04/11/2015 à 10:54
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.
4  0 
Avatar de Traroth2
Membre émérite https://www.developpez.com
Le 05/11/2015 à 11:33
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.
4  0 
Avatar de heid
Membre confirmé https://www.developpez.com
Le 04/11/2015 à 9:23
En fait a règle est simple, à réaliser dans l'ordre :

  • Make it work
  • Make it clean
  • Make it fast
4  1 
Avatar de Marco46
Expert éminent sénior https://www.developpez.com
Le 04/11/2015 à 10:38
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.
3  0 
Avatar de shkyo
Membre expérimenté https://www.developpez.com
Le 04/11/2015 à 13:43
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!
3  0 
Avatar de martopioche
Membre éclairé https://www.developpez.com
Le 04/11/2015 à 16:15
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.
4  1 
Avatar de Matthieu Vergne
Expert éminent https://www.developpez.com
Le 04/11/2015 à 21:30
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.
4  1