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, Chroniqueur Actualités
Quel est le paramètre à privilégier lors de la rédaction du code ?
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 ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de el_slapper 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".
Avatar de heid 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
Avatar de Orgoff Orgoff - Membre averti https://www.developpez.com
le 04/11/2015 à 9:28
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.
Avatar de FraisDesRiques FraisDesRiques - Membre régulier 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.
Avatar de martopioche martopioche - Membre éclairé https://www.developpez.com
le 04/11/2015 à 10:05
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.
Avatar de Cincinnatus Cincinnatus - Membre éclairé https://www.developpez.com
le 04/11/2015 à 10:30
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".
Avatar de Marco46 Marco46 - Modérateur 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.
Avatar de Voïvode Voïvode - 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.
Avatar de vinmar vinmar - Membre confirmé https://www.developpez.com
le 04/11/2015 à 12:02
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...
Avatar de Washmid Washmid - Membre averti https://www.developpez.com
le 04/11/2015 à 12:35
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.
Contacter le responsable de la rubrique Accueil