> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/fr/2020/w28-definitions-and-interface-dependencies.md).

# W28-Définitions et dépendances entre interfaces

### L'importance des définitions <a href="#id-ding-yi-de-zhong-yao-xing" id="id-ding-yi-de-zhong-yao-xing"></a>

Beaucoup de confusions et de responsabilités floues viennent de concepts mal définis, ou définis sans accord commun. Quand la QA attribue un bug dans Ones, une situation complexe peut rendre le choix du destinataire difficile. La cause est souvent le sens incertain de cette attribution. Sans définition claire, on y mêle la personne qui a créé le problème, celle qui le traite et celle qui en est responsable. Dès que le cas se complique, cette polysémie crée l'ambiguïté. Une définition simple suffit alors : on attribue le bug à celui qui doit le corriger. L'attribution désigne le traitement, pas la répartition des responsabilités. Chercher la cause et les responsabilités relève du retour COE.

### **Effet des dépendances entre API sur la rétrocompatibilité** <a href="#id-jie-kou-jian-yi-lai-dui-xiang-xia-jian-rong-de-ying-xiang" id="id-jie-kou-jian-yi-lai-dui-xiang-xia-jian-rong-de-ying-xiang"></a>

Dans une architecture séparant frontend et backend, toute évolution d'API doit rester rétrocompatible. En général, on ajoute des champs sans modifier les anciens. Sinon, ni changer l'ordre des publications ni ajouter un interrupteur entre anciennes et nouvelles API n'empêche les pics d'erreurs au moment du basculement. Attention aussi aux dépendances. Même si l'on crée une nouvelle version sans toucher à l'ancienne, elle peut dépendre d'une API précédente qui fournit son adresse. Il faut alors vérifier spécialement que cette API amont gère les versions de la nouvelle API aval.