Quand j’ai regardé pour la première fois les exemples du SDK de Newton, je pensais qu’ils étaient là simplement pour montrer aux développeurs comment appeler différentes fonctions.
Mais après y avoir passé plus de temps, j’ai commencé à remarquer autre chose.
Presque tous les exemples supposent que les erreurs sont normales. Le point intéressant n’est pas la façon dont le SDK se comporte lorsque tout est configuré correctement : c’est sa manière de réagir quand quelque chose ne va pas.
Si une Shield existante ne correspond pas à la politique attendue, elle refuse de s’attacher en silence. Si une politique refuse une action, le SDK n’encourage pas à effectuer des tentatives sans fin. Si quelqu’un veut seulement inspecter une Shield déployée, il peut vérifier sa configuration sans avoir besoin d’un accès privilégié.
Aucune de ces fonctionnalités ne fait la une, pourtant, ensemble, elles révèlent une philosophie.
Newton semble moins axé sur l’aide apportée aux développeurs pour écrire du code rapidement, et davantage sur l’aide pour éviter de commettre des erreurs invisibles. Cette différence compte, car les erreurs invisibles sont souvent celles qui survivent jusqu’en production.
Un autre détail m’est resté en tête : l’absence d’un état de chaîne global. Chaque Shield est lié à la chaîne à laquelle il appartient, ce qui oblige chaque environnement à rester explicite au lieu de s’appuyer sur des hypothèses cachées.
Plus je lisais ces exemples, moins ils me semblaient être de simples extraits de code isolés.
Elles semblaient comme de petites démonstrations d’un principe de conception plus vaste : des systèmes prévisibles sont construits en rendant l’incertitude visible avant qu’elle ne devienne coûteuse.
C’est peut-être le genre d’infrastructure que les gens apprécient le moins : parce que quand ça fonctionne bien, on le remarque à peine.