Expliquez-moi comment vous cadreriez et livreriez une fonctionnalité qui touche la base de données, l'API et l'interface.

Découpez verticalement et livrez par étapes plutôt que de construire trois couches en parallèle. Commencez par le modèle de données et une migration additive, puis l'API avec des tests de contrat, puis l'interface derrière un feature flag. Faites marcher un cas étroit de bout en bout très tôt, parce que c'est là que les mauvaises hypothèses ressortent à bas coût. Gardez des pull requests assez petites pour que quelqu'un puisse les relire correctement en une seule fois.

Avant d'écrire quoi que ce soit, je veux la plus petite version qui soit vraiment utile, parce que la moitié de ce qui est spécifié n'est pas nécessaire dans la première release. Ensuite je fais une tranche verticale fine : un champ, un endpoint, un écran, qui marchent de bout en bout en un jour ou deux. C'est là que vous découvrez que le modèle de données est faux, et le découvrir le deuxième jour ne coûte rien comparé au neuvième. Les migrations passent en premier et sont toujours additives pour pouvoir partir avant le code qui les utilise. Si quelqu'un d'autre construit l'interface, on se met d'accord tôt sur le contrat d'API et cette personne travaille contre un mock ou un schéma typé pour que personne ne soit bloqué à m'attendre. Côté pull requests, je vise des changements qu'un relecteur peut tenir en tête : migration et modèle dans l'une, endpoint et tests dans une autre, interface dans une troisième, toutes mergées derrière un flag désactivé. Ensuite on l'active en interne, puis pour un petit pourcentage. Livrer en sourdine comme ça m'a sauvé plus d'une fois quand la charge était pire que prévu.