Idées & Perspectives

Explorer le développement AI-first, les garde-fous de code et l'architecture de la jetabilité.

literate-programmingstructured-editingastprogramming-tools

Les éditeurs de texte vous laissent écrire du code invalide. Les éditeurs d'arbres ne le feraient pas.

Chaque compilateur voit votre code comme un arbre, mais votre éditeur vous laisse modifier du texte brut. Voici à quoi ressemble réellement l'édition structurée, pourquoi elle ne s'est pas imposée et comment emprunter ses avantages sans changer d'outils.

Chaque langage de programmation possède une grammaire formelle. Votre compilateur la lit, construit un arbre d'analyse et rejette tout ce qui ne correspond…
literate-programmingknuthsoftware-historydocumentation

Donald Knuth voulait que les programmes se lisent comme de la littérature. Le compilateur en avait décidé autrement.

La programmation lettrée promettait que le code devait être écrit d'abord pour les humains et ensuite pour les machines. Quatre décennies plus tard, presque personne n'écrit de cette manière. Voici pourquoi l'idée la plus élégante de la documentation logicielle n'a pas changé notre façon de travailler.

En 1984, Donald Knuth a publié un article proposant une inversion radicale. Les programmes ne devraient pas être écrits pour les compilateurs et annotés pour…
fagan-inspectionscausal-analysisdefect-analysisroot-cause

Corriger le bug est la partie facile. Comprendre pourquoi il existe est ce qui compte.

La plupart des équipes corrigent les défauts et passent à autre chose. Les mêmes défauts reviennent. Voici comment exécuter une analyse causale dans une inspection Fagan pour arrêter d'écrire deux fois le même bug.

Chaque équipe a ce défaut qui ne cesse de revenir. Un off-by-one dans la pagination. Une vérification de null manquante dans le middleware d'authentification.…
fagan-inspectionscode-reviewdatapr-reviews

Les Revues de Pull Request Détectent 15 à 30 % des Défauts. Les Données le Disent Depuis 50 Ans.

De multiples études menées chez IBM, AT&T, HP et Microsoft confirment que la revue de code informelle détecte environ un quart des défauts. Voici ce que les données disent réellement, pourquoi ce nombre est si bas et comment y remédier.

La revue de code informelle détecte entre 15 et 30 pour cent des défauts présents dans le code en cours de révision. Ce n'est pas une opinion. C'est une…
fagan-inspectionscode-reviewchecklistsstructured-review

Une checklist générique ne capture rien. Une checklist structurée capture 60 % des défauts.

La plupart des checklists de revue sont des listes copiées-collées de bonnes intentions. Une checklist structurée de type Fagan inspection est construite à partir de données réelles de défauts, ciblée sur des types d'artefacts spécifiques et utilisée pendant la préparation individuelle. Voici comment en construire une qui fonctionne.

Si votre équipe dispose d'une checklist pour le code review, il y a de fortes chances qu'elle se trouve sur une page wiki que personne n'ouvre. Elle dit…
fagan-inspectionsllmcode-reviewai-engineering

Un LLM peut pré-inspecter votre code. Il ne peut pas animer la réunion.

Les inspections Fagan nécessitent quatre à six personnes et deux heures pour examiner 250 lignes. Un LLM peut réduire ce coût en gérant la préparation et le respect des checklists, mais il ne peut pas remplacer les rôles humains qui trouvent les défauts les plus coûteux.

Une inspection Fagan complète nécessite un modérateur, un lecteur, deux à quatre inspecteurs et l'auteur. L'équipe passe deux heures à examiner environ 250…
fagan-inspectionscode-reviewsoftware-historyprocess

Les Fagan Inspections détectaient 90 % des défauts avant les tests. Puis nous avons cessé de les pratiquer.

Le processus de revue structuré de Michael Fagan chez IBM capturait presque tous les défauts avant qu'ils n'atteignent le compilateur. Il consommait aussi 15 à 20 % de l'effort total du projet. Voici pourquoi la méthode de revue la plus efficace de l'histoire du logiciel a disparu, et ce que les équipes manquent réellement.

En 1976, Michael Fagan a publié un article dans l'IBM Systems Journal décrivant un processus de revue si efficace qu'il est devenu la référence en matière de…
fagan-inspectionscode-reviewhuman-factorsdefect-detection

Votre meilleur relecteur manque la plupart des défauts. Fagan l'a mesuré chez IBM en 1976.

Même les ingénieurs seniors ne détectent qu'une fraction des défauts dans une relecture non structurée. Les recherches de Michael Fagan chez IBM ont montré pourquoi, et ont construit un processus d'inspection structuré pour y remédier.

Deux ingénieurs seniors relisent le même pull request. L'un signale un null check manquant. L'autre repère une race condition dans le cleanup path. Aucun des…
fagan-inspectionscode-reviewdefect-preventionsoftware-quality

La plupart des code reviews détectent 20 % des défauts. Les Fagan inspections en détectent 90 %.

La revue de code informelle détecte 15 à 30 % des défauts. Les Fagan inspections, un processus structuré vieux de 50 ans, rapportent constamment des taux d'élimination de 60 à 90 %. Voici comment elles fonctionnent, pourquoi les équipes les évitent, et comment en exécuter une version allégée.

La plupart des code reviews détectent entre 15 et 30 pour cent des défauts qu'elles sont censées trouver. Ce n'est pas une supposition. IBM l'a mesuré dans les…
model-checkingautoverusrustverification

AutoVerus transforme 40 heures d'écriture de proof en 3 appels LLM. L'astuce consiste à savoir quand abandonner.

AutoVerus utilise un réseau d'agents LLM pour générer des proofs de correction Verus pour du code Rust, automatisant plus de 90% des proof obligations via une boucle générer-réparer-discharger pilotée par le feedback du solveur SMT.

La partie la plus difficile de la vérification formelle n'a jamais été le vérificateur. C'est l'écriture du proof. Donnez à un ingénieur Rust senior Verus, le…