Personnellement, quand je code, mon invariant est que le code doit rester compilable, et c'est valable autant quand je code au départ que quand je fais de grosses modifications: évidemment il va se retrouver non-compilable pour de courtes périodes, mais j'essaie de minimiser ces périodes à tout prix.

Pour la conception de départ, ça veut dire que si je code top-down, ce n'est pas du top-down pur (qui fonctionne comme un breadth-first search), mais du depth-first: dès que j'ai besoin d'une fonction, je code d'abord la fonction dont j'ai besoin pour ensuite revenir à la fonction appelante (au pire, un bouchon qui ne fait rien, mais normalement j'essaie de coder la fonction tout de suite). Sinon, je code en bottom-up.

Pour les grosses modifications, ça veut souvent dire écrire des wrappeurs temporaires qui seront jetés quand la réorganisation sera complète.

Même si c'est parfois une contrainte (par exemple des wrappeurs inutiles à long terme, ou l'impossibilité de faire du top-down pur), ça a le gros avantage qu'on trouve tout de suite les erreurs détectables par le compilateur (erreurs de syntaxe etc.) qui seraient sinon cachées par d'autres erreurs, et que souvent on peut même tester le code (alors que du code non-compilable est essentiellement impossible à tester). Dans le cas des modifications, des wrappeurs de compatibilité bien écrits peuvent même garder le code entièrement fonctionnel même quand il est en pleine migration.