Des idées de systèmes presque inutiles

Des idées de systèmes qui fonctionnent à peine

• "Rendons-le simplement extensible"

  • L’idée est de faciliter l’ajout de nouvelles implémentations lorsqu’une implémentation ne fonctionne pas. Mais dans la plupart des cas, les fonctionnalités qu’une API propose ne fonctionnent pas aussi bien que prévu. Pour une vraie extensibilité, une seconde implémentation doit être conçue dès le départ.

• "Ajoutons simplement une API"

  • Il arrive souvent qu’on ajoute une API pour construire une plateforme et attirer des développeurs. Mais fournir une API exige des efforts continus pour la compatibilité et l’interopérabilité, et le simple fait d’offrir une API ne garantit pas qu’elle aura des utilisateurs. Construire une plateforme est un business sérieux, et il est difficile de créer une base économique solide en se contentant de fournir seulement des API.

• "Ajoutons une couche d’abstraction supplémentaire"

  • En informatique, on dit qu’un problème peut être résolu avec un niveau d’indirection supplémentaire. Mais une abstraction trop précoce peut nuire à la maintenance, à la sécurité et à l’optimisation des performances. Une abstraction ajoutée sans plan rend la maintenance du code plus difficile.

• "Rendons le système asynchrone"

  • L’asynchronisme est un sujet ancien de recherche en informatique. Les frameworks web l’abstraient bien, mais quand on tente de le gérer directement en dehors d’un framework, le risque de bugs imprévisibles augmente fortement.

• "Ajoutons le contrôle d’accès plus tard"

  • La sécurité d’un système devrait être considérée dès le départ, mais est souvent ajoutée plus tard à cause de la vitesse de mise sur le marché. Si l’on n’envisage pas le contrôle d’accès dès le départ, du point de vue des clients et des attaquants, il existe un risque élevé de devoir repenser le produit plus tard.

• "Synchronisons les données"

  • La synchronisation des données est un problème extrêmement difficile, avec de nombreux défis que seule l’expérience permet de surmonter. Construire une solution reposant sur la synchronisation des données est rarement une bonne idée.

• "Faisons-en une solution cross-platform"

  • Le développement cross-platform est semblable à la création d’un système d’exploitation, d’un fournisseur cloud ou d’un navigateur web. Cela peut fonctionner quand la plateforme est nouvelle ou quand l’application est simple, mais devient de plus en plus difficile avec le temps.

• "Permettons une sortie vers le natif"

  • Quand une approche cross-platform atteint ses limites, il est courant de permettre une évasion vers le code natif. Mais cette approche peut entrer en conflit avec l’état maintenu par le framework, et échoue dans neuf cas sur dix.

• Conclusion

  • Ces idées ne provoquent pas toujours des échecs, mais dans la plupart des cas il existe une meilleure approche. Il est important de résoudre les problèmes selon les principes de base et d’éviter les patterns logiciels à fort risque d’échec.

[ndrgrd]

Pour les plugins, l'essentiel est de concevoir l’interface en filtrant au maximum les comportements indispensables. Si l’on se contente de reprendre tant bien que mal la structure du code actuel pour créer l’interface, elle devient inévitablement une interface inutile liée à cette implémentation, mais ce genre de cas est vraiment fréquent…

[GN⁺]

Avis Hacker News

• Les DSL et les API fonctionnent souvent bien. Même des moteurs d'inférence comme TensorFlow peuvent être vus comme des DSL, ou comme des API qui encapsulent un DSL.

  • SQL, les langages Shader, le BPF, etc. sont aussi des exemples comparables.
  • L'approche du « ajoutons simplement une API » peut ne pas réussir. Il faut l'aborder avec la même prudence et la même rigueur que pour implémenter une UI.

• Les DSL peuvent parfois fonctionner très bien. JOOQ.org est une bonne référence.

• Elastic Load Balancer est une boucle de contrôle réactive à la charge de travail ; c'est en quelque sorte un produit.

• La rareté des ressources est omniprésente dans la plupart des industries. Voir par exemple erikbern.com et "Goal: Process of Ongoing Improvement".

• La détection d'anomalies n'est pas un problème propre aux systèmes distribués, mais les personnes qui en ont subi les effets peuvent la juger nécessaire.

  • L'algorithme Isolation Forest est parfois miraculeux. En 2018, il a donné de bons résultats en utilisant des embeddings basés sur CNN pour des textes.

• L'expression « presque » ne fonctionne pas ici. C'est un simple pessimisme teinté de cynisme.

• Beaucoup cherchent une fonction de décision subtile pour les exceptions, mais c'est en réalité très simple : ça marche quand je le fais, pas quand quelqu'un l'avait déjà fait.

• Le « Domain Driven Design » revient à concevoir une application selon la structure de l'entreprise : c'est une recette de désastre.

  • Cela peut ne pas poser de problème dans une petite entreprise, mais sur une entreprise qui réussit ou grandit, on peut vite le regretter.
  • Il faut plutôt concevoir autour de couches fonctionnelles et conserver autant que possible la logique métier dans les lignes de base de données et dans les workflows utilisateurs.

• Une boucle de contrôle réactive à la charge est une brique de base et essentielle, utilisée par beaucoup de systèmes.

• J'ai travaillé sur des projets utilisant plusieurs DSL, des caches P2P et du parallélisme hybride, et la plupart ont réussi.

  • Les caches P2P n'ont pas donné de grands bénéfices parce qu'ils n'étaient pas nécessaires.
  • C'est complexe, mais cette complexité permet des fonctionnalités difficiles à atteindre autrement.

• L'approche « synchronisons juste les données » peut être problématique.

  • Beaucoup de systèmes sont conçus pour une « échelle Internet » mais opèrent en réalité en dessous.
  • Ces équipes sont naïves, ou au pire, dépensent de l'argent avec un manager non ingénieur pour résoudre le problème.

• J'ai mis en œuvre avec succès de nombreuses idées. Cela peut sembler un peu étrange.