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 ?
Répondre avec citation
Envoyé par Stéphane le calme
: 
Partager