Le code, là où il se trouve vraiment.
Dans l'application de bureau, vous ouvrez un dossier et il y travaille : il lit les fichiers, lance la compilation, lit ce qui revient et corrige ce qu'il a cassé. Pas sur une copie collée dans une fenêtre de chat.
Des pages et des outils qui tournent.
Demandez une page, un widget ou un petit outil, et il tourne juste à côté de la réponse. Passez au code, modifiez-le sur place et voyez le résultat aussitôt.
Trois étapes.
- 1
Ouvrir le dossier
Dans l'application de bureau, vous désignez un dossier. Rien en dehors n'est accessible, dans aucun mode.
- 2
Dire ce qui ne va pas
« Le test dans OrderServiceTests échoue depuis le dernier commit. » Il lit le fichier, puis le test, puis le diff.
- 3
Confirmer la modification
Chaque écriture demande sa propre confirmation, ou aucune si vous la désactivez pour une session.
Ce qu'il fait.
- Lit des fichiers entiers, pas seulement leurs noms, et suit un import jusqu'au fichier qu'il désigne
- Lance `dotnet build` et `dotnet test`, puis lit la sortie du compilateur au lieu de deviner
- `git status`, `diff`, `log` et `blame` sans demander ; commit et push seulement quand vous le dites
- Écrit dans vos dossiers, avec une confirmation par fichier, ou aucune si vous la désactivez
- Force push et hard reset ne sont pas disponibles du tout, dans aucun mode
- Les longs fichiers s'ouvrent dans un panneau à côté de la conversation au lieu de la faire défiler
- Les pages web et petites applications React qu'il écrit tournent en aperçu direct à côté de la réponse, avec un bouton pour passer au code, modifiable sur place
- Dessine le parcours d'une requête dans le système sous forme de diagramme de flux, de séquence ou de cas d'utilisation
Il n'exécute pas votre application et ne touche à rien en dehors des dossiers ouverts. Une compilation qui a besoin d'identifiants, d'une base de données ou d'un appareil échouera ici exactement comme sur une machine qui n'en dispose pas.
Le test dans OrderServiceTests échoue depuis le dernier commit. Trouvez pourquoi et corrigez-le, mais ne modifiez pas le test.
Medium pour le travail courant, Large quand la modification touche plusieurs fichiers et que le raisonnement doit tenir sur l'ensemble.
Comparer les taillesQuestions.
- Exécute-t-il mon application ?
- Non. Il lance la compilation et les tests, lit ce qui revient et travaille à partir de là. Démarrer votre application, avec sa base de données et ses identifiants, n'en fait pas partie.
- Peut-il endommager mon dépôt ?
- Force push, hard reset et `clean -fd` ne sont pas disponibles du tout, ni derrière une confirmation, ni dans aucun mode. Le pire qui puisse arriver est un mauvais commit, que vous pouvez annuler.
- Quels langages ?
- Il lit et écrit dans n'importe quel langage. L'intégration de la compilation et des tests existe aujourd'hui pour .NET ; pour le reste, vous obtenez le fichier, le raisonnement et la modification, et vous lancez la compilation vous-même.
