Aller au contenu principal

Engineering Handbook — TL;DR

Cette édition s'adresse à des personnes qui construisent déjà du logiciel et veulent retrouver, rapidement, les idées qui rendent un système plus facile à modifier. Elle ne remplace pas la version complète : elle aide à décider quel approfondissement lire lorsque le changement devient risqué.

La thèse en une phrase

L'ingénierie ne consiste pas à éviter toute erreur. Elle consiste à rendre les erreurs moins probables, moins graves, détectables plus tôt et réparables plus vite.

Les huit réflexes

  1. Comprendre avant de modifier. Une demande décrit rarement toutes les règles, dépendances et exceptions qu'elle affecte.
  2. Regarder l'impact, pas la taille du diff. Une ligne dans une règle d'accès peut être plus risquée que cent lignes isolées.
  3. Préserver des options. Une migration additive, un contrat compatible ou un flag temporaire valent souvent mieux qu'un basculement brutal.
  4. Découper pour apprendre. Un petit changement livrable doit produire une information utile, pas simplement moins de code à relire.
  5. Produire des preuves adaptées. Test, revue, donnée de production et retour utilisateur se complètent ; aucun ne suffit toujours seul.
  6. Exposer progressivement. Déployer du code n'oblige pas à l'activer pour tout le monde, immédiatement et sans retour possible.
  7. Observer le résultat utilisateur. Une métrique technique verte ne prouve pas que le parcours fonctionne.
  8. Faire apprendre le système humain. Les incidents, les revues et les changements difficiles doivent laisser des capacités, pas seulement des souvenirs.

Comment l'utiliser

Lire ce livre en quinze à vingt minutes pour se remettre les idées en tête. Lorsqu'une situation dépasse votre contexte local, suivre les liens « Approfondir » vers la version complète. Les chapitres ne sont pas des règles à cocher : ils donnent les questions qui rendent une décision explicable.

La boucle de confiance

Si une étape est faible, ne la compensez pas par davantage de cérémonies ailleurs. Cherchez l'information qui manque, la protection qui rend l'erreur acceptable ou le feedback qui arrive trop tard.

À retenir

La confiance n'est pas un sentiment ni le résultat d'un outil. C'est une propriété du système de travail : comprendre suffisamment, changer de façon contrôlable, voir les effets et apprendre ensemble.