La performance est un facteur crucial dans le cycle de vie d'un logiciel et ce besoin gagne en importance dès la phase de conception du produit. Toutefois, certains segments de la communauté des développeurs estiment que les préoccupations en matière de performances sont dépassées et ne s'inscrivent plus dans les priorités de l'industrie. Pour Casey Muratori, Lead programmeur chez Molly Rocket Inc, ces genres d'excuses visant à reléguer la performance au second plan ne sont tout simplement pas valables, et il est facile de le démontrer en observant les efforts menés par les grandes firmes technologiques, à l'instar de Facebook ou de Twitter, au cours de ces dernières années.
Il existe de nombreux arguments légitimes en faveur de la performance des logiciels, mais il y a aussi de bonnes vieilles excuses. Il est temps d'en finir avec ces excuses.
Chaque fois que je souligne qu'une pratique logicielle courante est mauvaise pour les performances, des arguments s'ensuivent. C'est une bonne chose ! Les gens devraient se disputer sur ces sujets. Cela permet d'éclairer les deux côtés de la question. C'est productif et cela permet de mieux comprendre comment la performance des logiciels s'inscrit dans les priorités de notre industrie.
Ce qui n'est pas bon, c'est que certains segments de la communauté des développeurs ne veulent même pas avoir de discussions, et encore moins d'arguments, sur la performance des logiciels. Parmi certains développeurs, il existe une attitude omniprésente selon laquelle les logiciels ne sont tout simplement plus concernés par les préoccupations en matière de performances. Ils pensent que nous avons dépassé le stade de l'histoire du développement des logiciels où l'on devrait encore penser aux performances.
Ces excuses se répartissent en cinq catégories de base :
Toutes ces idées sont ridicules. Si vous regardez les preuves facilement disponibles et faciles à interpréter, vous pouvez voir qu'il s'agit d'excuses complètement invalides, et qu'elles ne peuvent pas être de bonnes raisons pour mettre fin à un argument sur la performance.
Bien sûr, pour faire une affirmation aussi forte, je dois être précis.
Tout d'abord, lorsque je parle de performances, j'entends la quantité de ressources consommées par un programme pour effectuer son travail. Le temps de l'unité centrale, le temps de l'horloge murale, l'autonomie de la batterie, le trafic réseau, l'empreinte de stockage - toutes les mesures qui ne modifient pas l'exactitude d'un programme, mais qui affectent le temps d'attente d'un utilisateur pour que le programme se termine, l'espace de stockage qu'il occupe, l'autonomie de la batterie qu'il utilise, etc.
Deuxièmement, lorsque je dis qu'il s'agit d'excuses complètement invalides, je veux dire exactement cela : elles sont manifestement fausses lorsqu'elles sont utilisées comme excuse pour justifier le fait d'ignorer la performance des logiciels et de rejeter des arguments ou des données.
Il est important de noter que cela ne signifie pas que vous ne pouvez pas trouver d'exemples où la base de l'excuse pourrait être vraie. Il est clairement possible de trouver une base de code dont les performances sont concentrées dans des points névralgiques. Il est également possible de trouver une entreprise où les performances n'ont pas d'incidence sur les résultats.
Mais une situation qui se produit parfois ne justifie pas l'utilisation d'une déclaration comme excuse générale. Pour que ces excuses soient valables et qu'elles relèguent les performances au rang de préoccupations ésotériques, elles doivent être vraies dans le cas courant. Elles doivent être vraies a priori, comme des choses que l'on peut savoir sur les logiciels en général avant d'avoir étudié les performances d'un produit ou d'une pratique en particulier.
Or, les preuves disponibles démontrent clairement que ces excuses ne sont pas vraies en général. Pour s'en convaincre, il suffit d'examiner les antécédents des entreprises de logiciels qui ont réussi. Il devient alors immédiatement évident qu'aucune de ces choses n'aurait pu être une déclaration exacte au sujet de leurs projets.
Prenons l'exemple de Facebook. C'est une énorme entreprise. Elle emploie des dizaines de milliers de développeurs de logiciels. C'est l'une des entreprises les plus rentables de la planète. Et, ce qui est important pour nous, elle est assez ouverte sur ce qu'elle fait et sur la façon dont se déroule le développement de ses logiciels. Nous pouvons facilement regarder en arrière et voir ce qu'il est advenu de ses projets logiciels au cours de la dernière décennie.
Facebook
En 2009, Facebook a annoncé le déploiement d'un nouveau système de stockage. La raison d'être de ce système était l'amélioration des performances.
Il a fallu "quelques années" pour développer ce système. La raison invoquée pour justifier tout ce temps et tous ces efforts est qu'il permet de "réduire de moitié le matériel" :
"En termes de coûts, si le système est deux fois plus efficace, nous pouvons utiliser 50 % de matériel en moins", a déclaré M. Johnson. "Avec 50 milliards de fichiers sur disque, les coûts s'additionnent. Cela nous donne essentiellement une marge de manœuvre [financière]."
L'année suivante, en 2010, ils ont annoncé qu'ils allaient "rendre Facebook deux fois plus rapide".
Pourquoi ? Ils ont déclaré avoir mené des expériences - corroborées par Google et Microsoft - qui ont prouvé que les utilisateurs consultaient plus de pages et retiraient plus de valeur de leur site lorsqu'il était plus rapide :
A-t-il été facile de rendre Facebook deux fois plus rapide ? S'agissait-il simplement de quelques ingénieurs travaillant sur quelques "points chauds" ?
Non. Il s'agissait d'un effort à l'échelle de l'organisation qui a duré "six mois et plus", et qui faisait suite à un an et demi de travaux antérieurs sur les performances :
Cet effort a nécessité la création de bibliothèques et de systèmes entièrement nouveaux, ainsi que la réécriture complète de plusieurs composants :
En 2012, Facebook a annoncé qu'il abandonnait HTML5 et qu'il avait réécrit l'intégralité de son application mobile pour qu'elle soit native iOS.
Il s'agissait d'une réécriture de six mois en utilisant le SDK iOS d'Apple, même si le résultat "était presque identique à l'ancienne application" :
Pourquoi avoir pris six mois pour réécrire toute une application sans ajouter de nouvelles fonctionnalités ? Pour remédier à ce qu'ils appellent "les plus gros problèmes de l'application", qui étaient tous des problèmes de performance :
L'entreprise était-elle prête à faire des sacrifices pour améliorer les performances ? Absolument :
En décembre de la même année, Facebook a annoncé avoir fait exactement la même chose pour Android, en réécrivant l'application en mode natif pour les mêmes raisons.
En 2017, Facebook a annoncé une nouvelle version de React appelée "React Fiber".
Il s'agissait d'une réécriture complète de leur framework React. Il était censé être compatible avec l'API, alors pourquoi était-ce nécessaire ? Selon Facebook, l'objectif principal était de le rendre "aussi réactif que possible" afin que les applications soient "très performantes" :
En 2018, Facebook a publié un document décrivant comment l'amélioration des performances de PHP et Hack est devenue une priorité pour eux, et ils ont dû créer des compilateurs de plus en plus compliqués pour que leur code s'exécute plus rapidement.
L'article décrit un certain nombre de techniques employées dans le compilateur pour contourner les limitations inhérentes à ces langages qui rendent difficile la génération d'un code rapide par les compilateurs.
Quelle augmentation de performance ont-ils obtenue ? 21,7 %, un pourcentage qui a nécessité un "énorme effort d'ingénierie".
En 2020, Facebook a annoncé qu'elle avait réalisé un autre effort d'ingénierie majeur pour réduire l'empreinte de Facebook Messenger de 75 %.
Comment ont-ils procédé ? En réécrivant l'intégralité de l'application à partir de zéro :
Combien de travail cela a-t-il demandé ? Il s'agit apparemment d'un effort pluriannuel et d'une "entreprise encore plus vaste que ce que Facebook avait prévu" :
Pourquoi un tel effort d'ingénierie pour reproduire la même application dans un encombrement plus réduit ? Parce que c'était "une bonne affaire" :
Deux mois plus tard, Facebook a annoncé qu'il reconstruisait l'ensemble de la pile technologique de facebook.com.
Pourquoi ? Parce qu'elle s'est rendue compte que sa pile technologique existante n'était pas en mesure d'offrir la "sensation et les performances d'une application" dont elle avait besoin :
Quelle a été l'ampleur du travail nécessaire pour reconstruire facebook.com ? Selon Facebook, il a fallu procéder à une "réécriture complète" :
La question de savoir pourquoi Facebook pensait que les réécritures étaient "extrêmement rares" est intéressante, puisque, comme nous l'avons déjà vu, il semble qu'ils réécrivent tout le temps. Quoi qu'il en soit, cette réécriture a touché une grande partie de leur pile technologique, et ils ont conclu en disant que le travail effectué pour améliorer les performances était "considérable" et que "les performances et l'accessibilité ne peuvent pas être considérées comme une taxe sur les fonctionnalités d'expédition" :
Enfin, nous avons l'une de mes annonces préférées de Facebook concernant les performances. Ce post de 2021 annonce une nouvelle version du compilateur Relay.
Il s'agit d'une réécriture complète du compilateur, dans un langage complètement différent. Pourquoi cette réécriture était-elle nécessaire ? Parce que leur "capacité à obtenir progressivement des gains de performance ne pouvait pas suivre la croissance du nombre de requêtes" dans leur base de code :
Ce qui est intéressant dans cette annonce, c'est qu'il s'agit d'une réécriture des performances d'un compilateur, alors que l'une des principales raisons d'être du compilateur est qu'il est nécessaire pour améliorer les performances des applications écrites avec Relay. Relay sans le compilateur serait trop lent, mais le compilateur lui-même était également trop lent, il a donc fallu réécrire le compilateur.
C'est la "poupée russe" des annonces de réécriture des performances.
Les excuses revisitées
Facebook nous dit directement, encore et encore, qu'aucune de ces cinq excuses ne s'applique à son produit typique :
Comment les gens peuvent-ils encore prendre ces excuses au sérieux ? Il n'y a aucun moyen d'expliquer le comportement de cette seule entreprise, sans parler du reste de l'industrie, si vous croyez à l'une de ces excuses.
Je suppose que l'une des façons de continuer à croire à l'une de ces excuses est de penser que Facebook est unique. Qu'ils sont les seuls à être si malavisés, si peu talentueux ou si malchanceux qu'ils ont ces problèmes de performance, mais que personne d'autre ne le serait.
En d'autres termes, il faudrait croire que les plus de 20 000 ingénieurs logiciels de Facebook se distinguent nettement du commun des mortels et que leurs bases de code sont très différentes de celles des autres.
Qu'en est-il de cette excuse ?
L'industrie dans son ensemble
Nous pourrions plutôt prendre l'exemple de Twitter qui, en 2011, a annoncé qu'il avait réécrit toute l'architecture de son moteur de recherche en raison de l'augmentation du trafic de recherche.
Ils ont remplacé MySQL par une version en temps réel de Lucene et Ruby-on-Rails par un serveur Java personnalisé appelé Blender, tout cela dans le but déclaré d'améliorer les performances de recherche.
L'année suivante, ils ont annoncé qu'ils avaient créé un système complet de profilage des performances afin d'optimiser leurs systèmes distribués.
La même année, ils ont également annoncé des optimisations approfondies de leur interface utilisateur, ce qui a nécessité de revenir sur un certain nombre de décisions architecturales prises deux ans auparavant et qui s'étaient avérées néfastes pour les performances.
En 2015, ils ont annoncé qu'ils avaient complètement remplacé leur plateforme d'analyse par un tout nouveau système qu'ils ont écrit à partir de zéro et qui s'appelle "Heron".
Peu satisfaits des performances de Heron, ils ont annoncé en 2017 qu'ils avaient procédé à des optimisations de bas niveau supplémentaires.
Apparemment, ces optimisations n'étaient pas suffisantes, car en 2021, ils ont décidé de remplacer complètement Heron, ainsi que plusieurs autres éléments de leur infrastructure de base, afin d'améliorer les performances de leur back-end.
Bien sûr, nous ne sommes pas obligés de nous en tenir à Twitter. Si vous préférez Uber, l'entreprise a publié un article en 2016 expliquant comment elle était passée à "Schemaless", un datastore écrit sur mesure.
Ils ont affirmé que cela était nécessaire car s'ils continuaient à utiliser leur solution existante (Postgres), "l'infrastructure d'Uber ne fonctionnerait plus d'ici la fin de l'année". Le déménagement a nécessité une réécriture complète de toute l'infrastructure, a pris "une grande partie de l'année" et a impliqué "de nombreux ingénieurs" de leurs bureaux d'ingénierie "dans le monde entier".
Toujours en 2016, ils ont annoncé avoir écrit PyFlame, un "Ptracing Profiler for Python" personnalisé.
La première raison qu'ils ont invoquée pour écrire leur propre profileur est que - et je n'invente rien - le profileur Python existant était trop lent pour être utilisé avec précision :
Pourquoi avaient-ils besoin d'un profileur en premier lieu ? Parce qu'ils voulaient maintenir leurs coûts de calcul à un niveau bas :
Si vous voulez un exemple du type de services back-end qu'ils ont dû profiler puis réécrire, vous n'avez qu'à regarder le nouveau datastore Schemaless qu'ils avaient annoncé l'année précédente.
Apparemment, ils avaient tout écrit en Python, mais ils se sont aperçus que Python était trop lent. Ils ont alors dû réécrire complètement tous les nœuds de travail en Go, sans autre raison que d'augmenter les performances.
Au cours de la même période, Uber a apparemment réécrit toute son application iOS en Swift. Ce fil de discussion datant de décembre 2020 détaille la série de désastres de développement causés par cette décision.
La lecture de ce fil de discussion est passionnante et détaille certains des efforts héroïques nécessaires à la livraison d'une application Swift. Malgré cela, Uber a fini par devoir prendre "un coup à huit chiffres" sur son résultat net parce qu'il n'y avait aucun moyen de réduire la taille de son application Swift pour permettre l'inclusion d'un binaire iOS 8 pour la rétrocompatibilité.
En 2020, Uber a annoncé qu'elle réécrivait entièrement son application Uber Eats, ce qui a pris une année entière.
Pourquoi une réécriture complète était-elle nécessaire ? L'entreprise n'a donné que deux raisons, dont l'une était la performance :
En 2021, Uber a annoncé une autre réécriture complète, cette fois de sa plateforme de traitement des commandes.
Ce processus a duré deux ans et était nécessaire car, selon Uber, "l'architecture construite en 2014 n'était pas évolutive".
Je peux continuer ainsi aussi longtemps que vous le souhaitez. La preuve que la performance est importante et que les entreprises prennent constamment des mesures pour l'améliorer est facile à trouver dans presque toutes les entreprises technologiques qui partagent des informations publiques sur leurs processus de développement. Vous pouvez les trouver chez Slack ...
... Netflix ...
... Yelp ...
... Shopify ...
... LinkedIn ...
... eBay ...
... HubSpot ...
... PayPal ...
... SalesForce ...
... et bien sûr, Microsoft ...
Conclusion
Avec autant de preuves réfutant les cinq excuses, il est clair, je l'espère, qu'elles sont ridicules. Il s'agit de raisons totalement invalides pour le développeur moyen, dans le cas courant, d'écarter les préoccupations relatives aux performances des logiciels. Elles ne doivent pas être prises au sérieux dans un contexte professionnel de développement de logiciels.
Il est essentiel de noter que les preuves contre ces excuses proviennent de certaines des entreprises les plus importantes et les plus rentables au monde - des entreprises pour lesquelles les développeurs de logiciels essaient activement de travailler, car elles offrent les emplois les plus prestigieux et les mieux rémunérés de l'industrie. À moins que votre objectif ne soit d'être un développeur de logiciels qui ne réussit pas, au sein d'une entreprise de logiciels qui ne réussit pas, il n'y a tout simplement pas de raison de s'attendre à ce que votre projet ne soit pas gravement affecté par des problèmes de performance.
En fait, si l'on considère les deux dernières décennies dans leur ensemble, il semblerait qu'elles montrent exactement le contraire de ce que prétendent généralement les auteurs d'excuses. Les performances des logiciels semblent être au cœur des intérêts commerciaux à long terme. Les entreprises affirment que leurs propres données montrent que la performance affecte directement le succès financier de leurs produits. Des feuilles de route entières sont bouleversées par des réécritures de fond en comble des performances. Loin de ce que ces excuses impliquent, la conclusion logique serait que les programmeurs doivent prendre les performances plus au sérieux qu'ils ne l'ont fait jusqu'à présent, et non pas moins !
Cela dit, comme je l'ai mentionné au début, il y a encore beaucoup d'arguments à faire valoir. Je ne veux pas mettre fin aux arguments, mais seulement aux excuses.
Par exemple, l'un des arguments serait que les preuves que j'ai présentées ici sont cohérentes avec une stratégie consistant à livrer rapidement une "version 1" peu performante, puis à commencer à travailler sur une "version 2" très performante pour la remplacer. Cela serait tout à fait cohérent avec les éléments que nous avons observés.
Mais même si cela s'avère vrai, cela signifie toujours que les programmeurs doivent se préoccuper des performances ! Cela signifie simplement qu'ils doivent apprendre deux modes de programmation : "jetable" et "performant". Il n'y aurait toujours pas d'excuse pour rejeter la performance comme une compétence critique, parce que vous savez toujours que la version jetable doit être remplacée par une version plus performante en peu de temps.
Ce type d'argument est excellent. Nous devrions l'avoir. Ce que nous ne devrions pas avoir, ce sont des excuses - des affirmations selon lesquelles il n'y a pas d'argument à avoir, et que la performance n'a en quelque sorte aucune importance dans le cycle de vie d'un produit, de sorte que les développeurs n'ont tout simplement pas besoin d'en apprendre davantage à ce sujet.
Cela dit, si la perspective d'apprendre à connaître les performances d'un logiciel vous semble être une mauvaise nouvelle, laissez-moi vous annoncer une bonne nouvelle.
Bien que ces cinq excuses ne soient pas vraies pour les performances logicielles en général, les temps ont changé. Si vous pensez que pour obtenir de bonnes performances logicielles, il est nécessaire d'utiliser le langage assembleur à la main, sachez que presque plus personne ne le fait. Il s'agit là d'un créneau extrêmement pointu dont on n'a pratiquement pas besoin, où la différence est minime et où il est très peu probable que le jeu en vaille la chandelle sur le plan financier !
Ces cinq excuses sont toutes vraies en ce qui concerne les assembleurs roulés à la main aujourd'hui ! Et ce n'était pas le cas dans les années 1980, par exemple.
La bonne nouvelle, c'est qu'aujourd'hui, la performance des logiciels n'est pas liée à l'apprentissage de l'écriture manuelle du langage assembleur. Il s'agit plutôt d'apprendre à lire des choses comme le langage assembleur, afin de comprendre quelle quantité de travail réel vous générez pour le matériel lorsque vous prenez chaque décision de programmation dans un langage de plus haut niveau. Il s'agit de savoir comment et pourquoi le langage A sera moins efficace que le langage B pour un type de programme particulier, afin de pouvoir prendre la bonne décision quant à celui à utiliser. Il s'agit de comprendre que les différents choix architecturaux ont des conséquences importantes, parfois graves, sur le travail que l'unité centrale, le réseau ou le sous-système de stockage aura à effectuer, et d'éviter soigneusement les pires pièges de chacun d'eux.
Bien qu'il faille un certain temps pour acquérir les compétences nécessaires à la prise de bonnes décisions en matière de performances, il s'agit aujourd'hui d'un objectif tout à fait réalisable. Il n'est plus nécessaire de passer plusieurs années à écrire du code assembleur à la main, comme c'était le cas auparavant. L'apprentissage des compétences de base en matière de programmation axée sur les performances est quelque chose qu'un développeur peut faire en quelques mois plutôt qu'en quelques années.
Et comme le montrent les faits, ces compétences font cruellement défaut à certains des plus grands et des plus importants éditeurs de logiciels au monde.
Chaque fois que je souligne qu'une pratique logicielle courante est mauvaise pour les performances, des arguments s'ensuivent. C'est une bonne chose ! Les gens devraient se disputer sur ces sujets. Cela permet d'éclairer les deux côtés de la question. C'est productif et cela permet de mieux comprendre comment la performance des logiciels s'inscrit dans les priorités de notre industrie.
Ce qui n'est pas bon, c'est que certains segments de la communauté des développeurs ne veulent même pas avoir de discussions, et encore moins d'arguments, sur la performance des logiciels. Parmi certains développeurs, il existe une attitude omniprésente selon laquelle les logiciels ne sont tout simplement plus concernés par les préoccupations en matière de performances. Ils pensent que nous avons dépassé le stade de l'histoire du développement des logiciels où l'on devrait encore penser aux performances.
Ces excuses se répartissent en cinq catégories de base :
- Pas de nécessité. "Il n'y a aucune raison de se préoccuper des performances des logiciels parce que le matériel est très rapide et que les compilateurs sont très bons. Quoi que vous fassiez, ce sera toujours assez rapide. Même si vous préférez les langages les plus lents, les bibliothèques les plus lentes et les styles architecturaux les moins performants, le résultat final sera toujours performant parce que les ordinateurs sont tout simplement aussi rapides."
- Trop faible. "S'il existe une différence de performance entre les différents choix de programmation, elle sera toujours trop faible pour qu'on s'en préoccupe. Le code optimal n'offrira au mieux que 5 ou 10 % de performances en plus, et nous pouvons toujours nous accommoder de 10 % d'utilisation de ressources en plus, quelles qu'elles soient."
- Le jeu n'en vaut pas la chandelle. "Bien sûr, vous pouvez passer du temps à améliorer les performances d'un produit. Cette amélioration peut même être substantielle. Mais financièrement, cela n'en vaut jamais la peine. Il est toujours préférable pour le résultat net d'ignorer les performances et de se concentrer sur autre chose, comme l'ajout de nouvelles fonctionnalités ou la création de nouveaux produits."
- La niche. "Les performances n'ont d'importance que dans des secteurs restreints et isolés de l'industrie du logiciel. Si vous ne travaillez pas sur des moteurs de jeux ou des systèmes embarqués, vous n'avez pas à vous préoccuper des performances, car elles n'ont pas d'importance dans votre secteur."
- Hostpot. "Les performances sont importantes, mais la grande majorité des programmeurs n'ont pas besoin de le savoir ou de s'en préoccuper. Les problèmes de performance d'un produit seront inévitablement concentrés dans quelques petits points névralgiques, et les experts en performance peuvent simplement corriger ces points névralgiques pour que le logiciel soit performant sur tous les paramètres que nous devons améliorer."
Toutes ces idées sont ridicules. Si vous regardez les preuves facilement disponibles et faciles à interpréter, vous pouvez voir qu'il s'agit d'excuses complètement invalides, et qu'elles ne peuvent pas être de bonnes raisons pour mettre fin à un argument sur la performance.
Bien sûr, pour faire une affirmation aussi forte, je dois être précis.
Tout d'abord, lorsque je parle de performances, j'entends la quantité de ressources consommées par un programme pour effectuer son travail. Le temps de l'unité centrale, le temps de l'horloge murale, l'autonomie de la batterie, le trafic réseau, l'empreinte de stockage - toutes les mesures qui ne modifient pas l'exactitude d'un programme, mais qui affectent le temps d'attente d'un utilisateur pour que le programme se termine, l'espace de stockage qu'il occupe, l'autonomie de la batterie qu'il utilise, etc.
Deuxièmement, lorsque je dis qu'il s'agit d'excuses complètement invalides, je veux dire exactement cela : elles sont manifestement fausses lorsqu'elles sont utilisées comme excuse pour justifier le fait d'ignorer la performance des logiciels et de rejeter des arguments ou des données.
Il est important de noter que cela ne signifie pas que vous ne pouvez pas trouver d'exemples où la base de l'excuse pourrait être vraie. Il est clairement possible de trouver une base de code dont les performances sont concentrées dans des points névralgiques. Il est également possible de trouver une entreprise où les performances n'ont pas d'incidence sur les résultats.
Mais une situation qui se produit parfois ne justifie pas l'utilisation d'une déclaration comme excuse générale. Pour que ces excuses soient valables et qu'elles relèguent les performances au rang de préoccupations ésotériques, elles doivent être vraies dans le cas courant. Elles doivent être vraies a priori, comme des choses que l'on peut savoir sur les logiciels en général avant d'avoir étudié les performances d'un produit ou d'une pratique en particulier.
Or, les preuves disponibles démontrent clairement que ces excuses ne sont pas vraies en général. Pour s'en convaincre, il suffit d'examiner les antécédents des entreprises de logiciels qui ont réussi. Il devient alors immédiatement évident qu'aucune de ces choses n'aurait pu être une déclaration exacte au sujet de leurs projets.
Prenons l'exemple de Facebook. C'est une énorme entreprise. Elle emploie des dizaines de milliers de développeurs de logiciels. C'est l'une des entreprises les plus rentables de la planète. Et, ce qui est important pour nous, elle est assez ouverte sur ce qu'elle fait et sur la façon dont se déroule le développement de ses logiciels. Nous pouvons facilement regarder en arrière et voir ce qu'il est advenu de ses projets logiciels au cours de la dernière décennie.
En 2009, Facebook a annoncé le déploiement d'un nouveau système de stockage. La raison d'être de ce système était l'amélioration des performances.
Il a fallu "quelques années" pour développer ce système. La raison invoquée pour justifier tout ce temps et tous ces efforts est qu'il permet de "réduire de moitié le matériel" :
"En termes de coûts, si le système est deux fois plus efficace, nous pouvons utiliser 50 % de matériel en moins", a déclaré M. Johnson. "Avec 50 milliards de fichiers sur disque, les coûts s'additionnent. Cela nous donne essentiellement une marge de manœuvre [financière]."
L'année suivante, en 2010, ils ont annoncé qu'ils allaient "rendre Facebook deux fois plus rapide".
Pourquoi ? Ils ont déclaré avoir mené des expériences - corroborées par Google et Microsoft - qui ont prouvé que les utilisateurs consultaient plus de pages et retiraient plus de valeur de leur site lorsqu'il était plus rapide :
Chez Facebook, nous nous efforçons de rendre notre site aussi réactif que possible ; nous avons mené des expériences qui prouvent que les utilisateurs consultent davantage de pages et tirent plus de profit du site lorsqu'il fonctionne plus rapidement. Google et Microsoft ont présenté des conclusions similaires pour leurs propriétés lors de la conférence O'Reilly Velocity 2009.
Non. Il s'agissait d'un effort à l'échelle de l'organisation qui a duré "six mois et plus", et qui faisait suite à un an et demi de travaux antérieurs sur les performances :
De début 2008 à mi-2009, nous avons passé beaucoup de temps à suivre les meilleures pratiques établies par les pionniers dans le domaine des performances web pour essayer d'améliorer le TTI ... En juin 2009, nous avions réalisé des améliorations significatives ... Après avoir examiné les données, nous nous sommes fixé l'objectif ambitieux de réduire cette mesure de moitié d'ici 2010 ; nous avions environ six mois pour faire de Facebook un site deux fois plus rapide.
La réduction des cookies a nécessité quelques astuces d'ingénierie mais s'est avérée assez simple ; en six mois, nous avons réduit de 42 % le nombre moyen d'octets de cookies par requête (avant gzip). Pour réduire le HTML et le CSS, nos ingénieurs ont développé une nouvelle bibliothèque de composants réutilisables (construits sur XHP) qui formeront les éléments de base de toutes nos pages. [...] Nous avons entrepris de réécrire nos interactions principales à partir de cette nouvelle bibliothèque, appelée Primer, et nous avons constaté une diminution massive de 40 % (après gzip) du nombre moyen d'octets JavaScript par page. [...] Nous appelons l'ensemble du système BigPipe et il nous permet de diviser nos pages web en blocs logiques de contenu, appelés Pagelets, et de canaliser la génération et le rendu de ces Pagelets.
Il s'agissait d'une réécriture de six mois en utilisant le SDK iOS d'Apple, même si le résultat "était presque identique à l'ancienne application" :
Facebook a annoncé aujourd'hui l'aboutissement de plus de six mois de travail, une version native de l'application Facebook pour iOS deux fois plus rapide. "Jusqu'à présent, nous avons cherché à nous adapter", explique Mick Johnson, chef de produit iOS, "mais nous nous sommes rendu compte que même si nous avons un excellent site web mobile, intégrer du HTML 5 dans une application n'est pas ce que les gens attendent". Facebook pour iOS 5.0 a été conçu à partir du SDK iOS d'Apple, et son apparence est presque identique à celle de l'ancienne application...
En créant une application Facebook native pour iOS, l'entreprise a cherché à améliorer trois points clés, "les plus grands points douloureux de l'application", tous liés à la vitesse : le lancement de l'application, le défilement du fil d'actualité et le fait de toucher des photos dans le fil d'actualité.
Si Facebook pour iOS est beaucoup plus rapide qu'auparavant, cette rapidité s'accompagne d'un compromis : l'entreprise ne peut plus proposer de mises à jour quotidiennes pour l'une de ses applications les plus populaires.
Facebook a annoncé aujourd'hui le lancement de sa nouvelle application Android, qui abandonne les "webviews" HTML 5 en faveur d'un code natif pour accélérer le chargement des photos, la navigation dans votre Timeline et le feuilletage de votre fil d'actualité.
Il s'agissait d'une réécriture complète de leur framework React. Il était censé être compatible avec l'API, alors pourquoi était-ce nécessaire ? Selon Facebook, l'objectif principal était de le rendre "aussi réactif que possible" afin que les applications soient "très performantes" :
L'objectif principal était de rendre React aussi réactif que possible, m'a expliqué Ben Alpert, ingénieur chez Facebook et membre de l'équipe centrale de React, lors d'une interview en début de semaine. "Lorsque nous développons React, nous cherchons toujours à voir comment nous pouvons aider les développeurs à créer des applications de haute qualité plus rapidement", a-t-il noté. "Nous voulons faciliter la création d'apps très performantes et les rendre réactives".
L'article décrit un certain nombre de techniques employées dans le compilateur pour contourner les limitations inhérentes à ces langages qui rendent difficile la génération d'un code rapide par les compilateurs.
Quelle augmentation de performance ont-ils obtenue ? 21,7 %, un pourcentage qui a nécessité un "énorme effort d'ingénierie".
En 2020, Facebook a annoncé qu'elle avait réalisé un autre effort d'ingénierie majeur pour réduire l'empreinte de Facebook Messenger de 75 %.
Comment ont-ils procédé ? En réécrivant l'intégralité de l'application à partir de zéro :
Aujourd'hui, Facebook a soumis la version iOS de Messenger à un régime amaigrissant extrême. En réécrivant entièrement l'application, Facebook a réduit l'empreinte de Messenger sur votre iPhone à 30 Mo, soit moins d'un quart de sa taille maximale. Selon l'entreprise, la nouvelle version se charge deux fois plus vite que celle qu'elle remplace.
Connue sous le nom de code "LightSpeed" et annoncée lors de la conférence F8 de Facebook en avril 2019, la nouvelle version devait initialement être livrée l'année dernière ; la compléter a été une entreprise encore plus vaste que Facebook ne l'avait anticipé. Le vice-président de Messenger, Stan Chudnovsky, compare l'effort à la rénovation d'une maison et à la découverte de nouveaux problèmes lorsque les entrepreneurs ouvrent les murs : "Vous ne pouvez que trouver des choses qui sont pires que ce que vous aviez prévu", dit-il.
L'amélioration des performances d'une application n'est pas seulement une question de courtoisie à l'égard des utilisateurs ; c'est aussi une question de rentabilité, car cela tend à accroître l'utilisation de l'application. "Nous savons qu'à chaque fois que nous rendons Messenger plus rapide et plus simple, les gens communiquent plus facilement et l'utilisent davantage", explique Raymond Endres, vice-président de l'ingénierie.
Pourquoi ? Parce qu'elle s'est rendue compte que sa pile technologique existante n'était pas en mesure d'offrir la "sensation et les performances d'une application" dont elle avait besoin :
Lorsque nous avons réfléchi à la manière dont nous allions créer une nouvelle application web - conçue pour les navigateurs d'aujourd'hui et dotée des fonctionnalités que les utilisateurs attendent de Facebook - nous nous sommes rendu compte que notre pile technologique existante n'était pas en mesure d'offrir la convivialité et les performances d'une application dont nous avions besoin.
Une réécriture complète est extrêmement rare, mais dans ce cas, étant donné que beaucoup de choses ont changé sur le web au cours de la dernière décennie, nous savions que c'était le seul moyen d'atteindre nos objectifs en matière de performances et de croissance durable.
Les améliorations de l'expérience technique et de l'expérience utilisateur doivent aller de pair, et les performances et l'accessibilité ne peuvent pas être considérées comme une taxe sur les fonctionnalités d'expédition. Grâce à des API, des outils et une automatisation de qualité, nous pouvons aider les ingénieurs à aller plus vite et à livrer en même temps un code de meilleure qualité et plus performant. Le travail effectué pour améliorer les performances du nouveau Facebook.com a été considérable et nous prévoyons de partager plus d'informations sur ce travail prochainement.
Il s'agit d'une réécriture complète du compilateur, dans un langage complètement différent. Pourquoi cette réécriture était-elle nécessaire ? Parce que leur "capacité à obtenir progressivement des gains de performance ne pouvait pas suivre la croissance du nombre de requêtes" dans leur base de code :
Mais nous n'avons pas abordé la raison pour laquelle nous avons décidé de réécrire le compilateur en 2020 : la performance. Avant la décision de réécrire le compilateur, le temps nécessaire pour compiler toutes les requêtes de notre base de code ralentissait progressivement, mais inexorablement, au fur et à mesure que notre base de code grandissait. Notre capacité à obtenir des gains de performance ne pouvait pas suivre la croissance du nombre de requêtes dans notre base de code, et nous ne voyions pas de solution incrémentale pour sortir de cette situation difficile. [...] Le déploiement s'est fait en douceur, sans interruption du développement de l'application. Les premiers benchmarks internes ont indiqué que le compilateur était près de 5 fois plus performant en moyenne, et près de 7 fois plus performant que P95. Nous avons encore amélioré les performances du compilateur depuis lors.
C'est la "poupée russe" des annonces de réécriture des performances.
Les excuses revisitées
Facebook nous dit directement, encore et encore, qu'aucune de ces cinq excuses ne s'applique à son produit typique :
- S'il n'y avait vraiment "aucun besoin" de s'inquiéter de la performance des logiciels - ils sont toujours assez rapides, quel que soit le langage choisi, quelles que soient les bibliothèques utilisées - pourquoi ont-ils dû faire des choses comme réécrire un compilateur entier de JavaScript à Rust ? Ils auraient dû pouvoir utiliser JavaScript et faire en sorte que le compilateur soit suffisamment rapide. Pourquoi ont-ils dû réécrire toute leur application iOS en utilisant le SDK natif ? HTML5 aurait dû être suffisamment rapide. Pourquoi ont-ils dû entreprendre un "énorme effort d'ingénierie" pour créer une nouvelle technologie de compilateur afin d'accélérer à leur code PHP et Hack ? Hack et PHP auraient déjà dû être assez rapides, n'est-ce pas ?
- Si les améliorations de performance sont toujours "trop petites" pour être prises en compte, comment ont-ils obtenu des performances deux fois supérieures sur l'ensemble de leur site ? Comment ont-ils pu réduire leur exécutable de 75 % ? Comment ont-ils obtenu une augmentation de 5 fois des performances lorsqu'ils ont réécrit leur compilateur en Rust ? Comment obtiennent-ils ces améliorations massives et généralisées des performances, si l'optimisation ne peut jamais faire qu'une différence insignifiante ?
- Si les performances ne valaient pas la peine d'être prises en compte, pourquoi Facebook - une société cotée en bourse - affecte-t-elle des divisions entières de son organisation à la réécriture de logiciels pour améliorer les performances ? Pourquoi une société à but lucratif consacre-t-elle autant de temps et d'énergie à quelque chose qui n'a aucune incidence sur sa réussite financière ? Pourquoi font-ils référence à des études de clientèle - apparemment corroborées par Google et Microsoft - selon lesquelles les clients s'engagent davantage avec leur produit si celui-ci est plus performant ? Pourquoi qualifient-ils de "bonne affaire" le fait de réécrire exactement la même application à partir de zéro juste pour obtenir une réduction de l'empreinte de 75 % ?
- Si la performance est une préoccupation de "niche", quelle est cette niche ? Comment Facebook voit-il la nécessité d'optimiser les performances et de réécrire complètement chaque catégorie de produits ? Quel type de "niche" englobe les applications iOS, les applications Android, les applications web de bureau, les backends de serveur et les outils de développement internes ?
- Si les problèmes de performance de Facebook étaient concentrés dans des "points chauds", pourquoi a-t-il fallu réécrire complètement des bases de code entières ? Pourquoi avoir réécrit quelque chose de fond en comble si seuls quelques points névralgiques étaient à l'origine du problème ? Pourquoi n'ont-ils pas simplement réécrit les points chauds ? Pourquoi ont-ils dû réécrire un compilateur entier dans un nouveau langage, au lieu de simplement réécrire les zones sensibles dans ce langage ? Pourquoi ont-ils dû créer leur propre compilateur pour accélérer PHP et Hack, au lieu d'identifier les points sensibles de ces codes et de les réécrire en C pour améliorer les performances ?
Comment les gens peuvent-ils encore prendre ces excuses au sérieux ? Il n'y a aucun moyen d'expliquer le comportement de cette seule entreprise, sans parler du reste de l'industrie, si vous croyez à l'une de ces excuses.
Je suppose que l'une des façons de continuer à croire à l'une de ces excuses est de penser que Facebook est unique. Qu'ils sont les seuls à être si malavisés, si peu talentueux ou si malchanceux qu'ils ont ces problèmes de performance, mais que personne d'autre ne le serait.
En d'autres termes, il faudrait croire que les plus de 20 000 ingénieurs logiciels de Facebook se distinguent nettement du commun des mortels et que leurs bases de code sont très différentes de celles des autres.
Qu'en est-il de cette excuse ?
L'industrie dans son ensemble
Nous pourrions plutôt prendre l'exemple de Twitter qui, en 2011, a annoncé qu'il avait réécrit toute l'architecture de son moteur de recherche en raison de l'augmentation du trafic de recherche.
Ils ont remplacé MySQL par une version en temps réel de Lucene et Ruby-on-Rails par un serveur Java personnalisé appelé Blender, tout cela dans le but déclaré d'améliorer les performances de recherche.
L'année suivante, ils ont annoncé qu'ils avaient créé un système complet de profilage des performances afin d'optimiser leurs systèmes distribués.
La même année, ils ont également annoncé des optimisations approfondies de leur interface utilisateur, ce qui a nécessité de revenir sur un certain nombre de décisions architecturales prises deux ans auparavant et qui s'étaient avérées néfastes pour les performances.
En 2015, ils ont annoncé qu'ils avaient complètement remplacé leur plateforme d'analyse par un tout nouveau système qu'ils ont écrit à partir de zéro et qui s'appelle "Heron".
Peu satisfaits des performances de Heron, ils ont annoncé en 2017 qu'ils avaient procédé à des optimisations de bas niveau supplémentaires.
Apparemment, ces optimisations n'étaient pas suffisantes, car en 2021, ils ont décidé de remplacer complètement Heron, ainsi que plusieurs autres éléments de leur infrastructure de base, afin d'améliorer les performances de leur back-end.
Bien sûr, nous ne sommes pas obligés de nous en tenir à Twitter. Si vous préférez Uber, l'entreprise a publié un article en 2016 expliquant comment elle était passée à "Schemaless", un datastore écrit sur mesure.
Ils ont affirmé que cela était nécessaire car s'ils continuaient à utiliser leur solution existante (Postgres), "l'infrastructure d'Uber ne fonctionnerait plus d'ici la fin de l'année". Le déménagement a nécessité une réécriture complète de toute l'infrastructure, a pris "une grande partie de l'année" et a impliqué "de nombreux ingénieurs" de leurs bureaux d'ingénierie "dans le monde entier".
Toujours en 2016, ils ont annoncé avoir écrit PyFlame, un "Ptracing Profiler for Python" personnalisé.
La première raison qu'ils ont invoquée pour écrire leur propre profileur est que - et je n'invente rien - le profileur Python existant était trop lent pour être utilisé avec précision :
Le premier inconvénient est son surcoût extrêmement élevé : nous voyons couramment qu'il ralentit les programmes par 2. Pire encore, nous avons constaté que cette surcharge entraînait des chiffres de profilage inexacts dans de nombreux cas.
Chez Uber, nous nous efforçons d'écrire des services backend efficaces pour maintenir nos coûts de calcul à un niveau bas. Cela devient de plus en plus important au fur et à mesure que notre entreprise se développe ; des inefficacités apparemment minimes sont considérablement amplifiées à l'échelle d'Uber.
Apparemment, ils avaient tout écrit en Python, mais ils se sont aperçus que Python était trop lent. Ils ont alors dû réécrire complètement tous les nœuds de travail en Go, sans autre raison que d'augmenter les performances.
Au cours de la même période, Uber a apparemment réécrit toute son application iOS en Swift. Ce fil de discussion datant de décembre 2020 détaille la série de désastres de développement causés par cette décision.
La lecture de ce fil de discussion est passionnante et détaille certains des efforts héroïques nécessaires à la livraison d'une application Swift. Malgré cela, Uber a fini par devoir prendre "un coup à huit chiffres" sur son résultat net parce qu'il n'y avait aucun moyen de réduire la taille de son application Swift pour permettre l'inclusion d'un binaire iOS 8 pour la rétrocompatibilité.
En 2020, Uber a annoncé qu'elle réécrivait entièrement son application Uber Eats, ce qui a pris une année entière.
Pourquoi une réécriture complète était-elle nécessaire ? L'entreprise n'a donné que deux raisons, dont l'une était la performance :
L'équipe d'UberEats.com a passé l'année dernière à réécrire l'application web de A à Z pour la rendre plus performante et plus facile à utiliser.
Ce processus a duré deux ans et était nécessaire car, selon Uber, "l'architecture construite en 2014 n'était pas évolutive".
Je peux continuer ainsi aussi longtemps que vous le souhaitez. La preuve que la performance est importante et que les entreprises prennent constamment des mesures pour l'améliorer est facile à trouver dans presque toutes les entreprises technologiques qui partagent des informations publiques sur leurs processus de développement. Vous pouvez les trouver chez Slack ...
... Netflix ...
... Yelp ...
... Shopify ...
... LinkedIn ...
... eBay ...
... HubSpot ...
... PayPal ...
... SalesForce ...
... et bien sûr, Microsoft ...
Conclusion
Avec autant de preuves réfutant les cinq excuses, il est clair, je l'espère, qu'elles sont ridicules. Il s'agit de raisons totalement invalides pour le développeur moyen, dans le cas courant, d'écarter les préoccupations relatives aux performances des logiciels. Elles ne doivent pas être prises au sérieux dans un contexte professionnel de développement de logiciels.
Il est essentiel de noter que les preuves contre ces excuses proviennent de certaines des entreprises les plus importantes et les plus rentables au monde - des entreprises pour lesquelles les développeurs de logiciels essaient activement de travailler, car elles offrent les emplois les plus prestigieux et les mieux rémunérés de l'industrie. À moins que votre objectif ne soit d'être un développeur de logiciels qui ne réussit pas, au sein d'une entreprise de logiciels qui ne réussit pas, il n'y a tout simplement pas de raison de s'attendre à ce que votre projet ne soit pas gravement affecté par des problèmes de performance.
En fait, si l'on considère les deux dernières décennies dans leur ensemble, il semblerait qu'elles montrent exactement le contraire de ce que prétendent généralement les auteurs d'excuses. Les performances des logiciels semblent être au cœur des intérêts commerciaux à long terme. Les entreprises affirment que leurs propres données montrent que la performance affecte directement le succès financier de leurs produits. Des feuilles de route entières sont bouleversées par des réécritures de fond en comble des performances. Loin de ce que ces excuses impliquent, la conclusion logique serait que les programmeurs doivent prendre les performances plus au sérieux qu'ils ne l'ont fait jusqu'à présent, et non pas moins !
Cela dit, comme je l'ai mentionné au début, il y a encore beaucoup d'arguments à faire valoir. Je ne veux pas mettre fin aux arguments, mais seulement aux excuses.
Par exemple, l'un des arguments serait que les preuves que j'ai présentées ici sont cohérentes avec une stratégie consistant à livrer rapidement une "version 1" peu performante, puis à commencer à travailler sur une "version 2" très performante pour la remplacer. Cela serait tout à fait cohérent avec les éléments que nous avons observés.
Mais même si cela s'avère vrai, cela signifie toujours que les programmeurs doivent se préoccuper des performances ! Cela signifie simplement qu'ils doivent apprendre deux modes de programmation : "jetable" et "performant". Il n'y aurait toujours pas d'excuse pour rejeter la performance comme une compétence critique, parce que vous savez toujours que la version jetable doit être remplacée par une version plus performante en peu de temps.
Ce type d'argument est excellent. Nous devrions l'avoir. Ce que nous ne devrions pas avoir, ce sont des excuses - des affirmations selon lesquelles il n'y a pas d'argument à avoir, et que la performance n'a en quelque sorte aucune importance dans le cycle de vie d'un produit, de sorte que les développeurs n'ont tout simplement pas besoin d'en apprendre davantage à ce sujet.
Cela dit, si la perspective d'apprendre à connaître les performances d'un logiciel vous semble être une mauvaise nouvelle, laissez-moi vous annoncer une bonne nouvelle.
Bien que ces cinq excuses ne soient pas vraies pour les performances logicielles en général, les temps ont changé. Si vous pensez que pour obtenir de bonnes performances logicielles, il est nécessaire d'utiliser le langage assembleur à la main, sachez que presque plus personne ne le fait. Il s'agit là d'un créneau extrêmement pointu dont on n'a pratiquement pas besoin, où la différence est minime et où il est très peu probable que le jeu en vaille la chandelle sur le plan financier !
Ces cinq excuses sont toutes vraies en ce qui concerne les assembleurs roulés à la main aujourd'hui ! Et ce n'était pas le cas dans les années 1980, par exemple.
La bonne nouvelle, c'est qu'aujourd'hui, la performance des logiciels n'est pas liée à l'apprentissage de l'écriture manuelle du langage assembleur. Il s'agit plutôt d'apprendre à lire des choses comme le langage assembleur, afin de comprendre quelle quantité de travail réel vous générez pour le matériel lorsque vous prenez chaque décision de programmation dans un langage de plus haut niveau. Il s'agit de savoir comment et pourquoi le langage A sera moins efficace que le langage B pour un type de programme particulier, afin de pouvoir prendre la bonne décision quant à celui à utiliser. Il s'agit de comprendre que les différents choix architecturaux ont des conséquences importantes, parfois graves, sur le travail que l'unité centrale, le réseau ou le sous-système de stockage aura à effectuer, et d'éviter soigneusement les pires pièges de chacun d'eux.
Bien qu'il faille un certain temps pour acquérir les compétences nécessaires à la prise de bonnes décisions en matière de performances, il s'agit aujourd'hui d'un objectif tout à fait réalisable. Il n'est plus nécessaire de passer plusieurs années à écrire du code assembleur à la main, comme c'était le cas auparavant. L'apprentissage des compétences de base en matière de programmation axée sur les performances est quelque chose qu'un développeur peut faire en quelques mois plutôt qu'en quelques années.
Et comme le montrent les faits, ces compétences font cruellement défaut à certains des plus grands et des plus importants éditeurs de logiciels au monde.
Et vous ?
Qu'en pensez-vous ? Trouvez-vous que l'avis de M. Muratori est pertinent, ou plutôt partisan ? Pensez-vous que la performance demeure un aspect important du développement de logiciels ? Selon vous, dans quelle mesure est-il utile d'investir dans l'amélioration des performances d'un logiciel au détriment de l'ajout de nouvelles fonctionnalités ? D'après vous, les progrès du matériel et des compilateurs suffisent-ils à garantir que les performances des logiciels ne sont plus un problème ? Selon vous, les pratiques de codage et les styles architecturaux sous-optimaux peuvent-ils encore affecter les performances des logiciels ?Voir aussi
Les problèmes de performance des sites web coûtent aux entreprises de commerce en ligne 10 % de leurs revenus, malgré que 48 % ont augmenté leurs investissements ces deux dernières années Faut-il sacrifier la performance pour avoir un code plus lisible ? Selon un développeur, la performance passe au second degré Quel est l'effet du langage de programmation sur la qualité du logiciel ? Une étude tente de clarifier la situation 
Envoyé par denisys
