Le secrétaire de Fernand

Série

Encoder le système

Un arc qui va du manifeste à la conclusion : programmer n'est pas seulement écrire du code, c'est encoder des garanties dans les systèmes.

3 articles sur 7 disponibles

La série

Article 1

Construire des systèmes, pas de la belle prose

On parle encore trop souvent du code comme d’un style. Pourtant, le code tourne dans notre monde.

Article 2

Encoder, ne pas sous-entendre

Pourquoi l’implicite devient fragile quand humains et agents co-produisent du code.

Article 3

Faire attribuer les boucles de feedback, pas seulement détecter

Pourquoi les boucles de feedback gagnent en puissance quand le code rend explicites ses concepts système.

Article 4Prochain article

Faire respecter l’architecture, ne pas se fier à l’intention

Pourquoi les règles structurantes de l’architecture doivent devenir des vérifications exécutables plutôt que des intentions auxquelles se fier.

Article 5À venir

Construire des garanties, ne pas traquer les bugs

Pourquoi le but n’est pas de corriger les bugs plus vite, mais d’encoder des garanties qui rendent des catégories entières de bugs impossibles, rares ou visibles.

Article 6À venir

Structurer le domaine, ne pas disperser les règles

Pourquoi les invariants métier appartiennent aux structures du domaine, pas à des règles dispersées dans les chemins du code.

Article 7À venir

Encoder les garanties, ne pas seulement écrire du code

Programmer est l’art de décider quelles vérités rendre inviolables, où les encoder et à quel coût.

Glossaire de la série

Quarante concepts employés dans les essais publiés. Chaque définition précise ce que le terme signifie à l’intérieur de cette série.

Abstraction

Une représentation qui masque certains détails afin de concentrer l’attention sur les concepts importants.

Central dans l’article 2
Adaptateur

Une couche fine qui traduit entre une technologie extérieure et le modèle ou le contrat utilisé par le système.

Attribution

Le fait d’identifier la règle, l’état, la frontière ou la responsabilité à l’origine du problème.

Autorité

La partie du système autorisée à décider ou à exécuter une opération.

Colocation

Le fait de placer des éléments de code liés les uns aux autres à proximité, même lorsqu’ils appartiennent à des zones d’exécution ou d’architecture différentes.

Central dans l’article 2
Contrat

Une formulation explicite de ce qui peut entrer ou sortir d’une frontière et de ce que chaque côté garantit.

Dépendance invisible

Une connaissance dont dépend le code sans que cette dépendance soit représentée ou garantie.

Central dans l’article 2
Dérive

L’écart progressif du code ou de son comportement par rapport à la structure que le système devait préserver.

Détection

Le fait d’établir que quelque chose ne fonctionne pas correctement.

Effet de bord

Une interaction avec un élément extérieur au calcul local, comme une base de données, un réseau, un fichier, une horloge ou un appareil.

État explicite

Une situation nommée dans laquelle le système peut se trouver, représentée directement plutôt que déduite de conditions dispersées.

Événement métier

Un enregistrement nommé indiquant qu’un événement significatif s’est produit dans le domaine ou dans le modèle du système.

Exhaustivité

La garantie que tous les cas possibles ont été envisagés et traités.

Explicite

Un concept représenté sous une forme visible, nommée et inspectable.

Feedback local

Des vérifications rapides portant sur le code immédiatement modifié, comme les types, la compilation et les tests proches.

Feedback loop

Un mécanisme qui observe le résultat d’une modification et renvoie une information permettant de guider la correction suivante.

Feedback proche de la production

Des vérifications des comportements critiques dans des conditions proches de l’exécution réelle.

Feedback structurel

Des vérifications qui déterminent si les frontières architecturales, les dépendances et les responsabilités continuent d’être respectées.

Fitness function architecturale

Une vérification automatisée qui évalue régulièrement si le système respecte toujours une propriété architecturale.

Fonction pure

Une fonction dont le résultat dépend uniquement de ses entrées et qui ne modifie aucun état extérieur.

Frontière

Un point qui sépare des zones ayant des responsabilités, des niveaux de confiance ou des comportements différents.

Idempotence

La propriété selon laquelle répéter la même opération ne produit pas d’effets supplémentaires non désirés.

Identifiant de corrélation

Un identifiant utilisé pour relier les journaux, événements et appels appartenant à une même opération.

Implicite

Une information nécessaire pour comprendre le système, mais qui n’est pas directement représentée dans le code lu.

Invariant

Une condition qui doit rester vraie pendant toute la partie pertinente de la vie du système.

Exemple: Une commande payée ne peut pas revenir à l’état « en attente de paiement ».

Machine à états

Un modèle qui nomme les états possibles, les événements acceptés et les transitions autorisées entre ces états.

Machine probabiliste

Un système qui produit des sorties probables plutôt que de suivre une unique continuation déterminée.

Central dans l’article 2
Matrice de disposition

Un tableau complet qui classe la signification de chaque événement dans chaque état possible.

Observabilité

La capacité à reconstruire ce qu’un système en fonctionnement a fait, dans quel contexte et pour quelle raison.

Portabilité cognitive

La capacité à reconnaître une même structure conceptuelle à travers différents langages, frameworks ou implémentations.

Central dans l’article 2
Responsabilité

La partie du système chargée de garantir qu’une opération est accomplie.

Robustesse

La capacité d’un système à rester compréhensible, à absorber les écarts et à rendre visible ce qui se produit pendant son exécution.

Snapshot

Une représentation immuable de l’état du système à un instant donné.

Central dans l’article 2
Surface de vérification

L’ensemble des formes explicites du système que les outils et les personnes peuvent inspecter et vérifier.

Test basé sur les propriétés

Une approche de test qui vérifie des propriétés générales sur de nombreuses entrées générées automatiquement, plutôt que de dépendre uniquement d’exemples choisis manuellement.

Test boîte noire

Un test qui vérifie le comportement observable sans dépendre des détails internes de l’implémentation.

Trace

Un enregistrement relié des différentes étapes suivies par une opération à travers le système.

Transformation déterministe

Une transformation qui produit toujours le même résultat à partir des mêmes entrées explicites.

Union discriminée

Un type représentant un ensemble fini d’alternatives, chacune identifiée par un champ distinctif commun.

ViewModel

Une représentation préparée pour l’interface utilisateur, qui expose l’état et les actions dont la vue a besoin sans intégrer le comportement du domaine dans la vue.

Central dans l’article 2