SideNote ProArbeitsabläufe mit SideNote Pro für Entwickler
Ratschläge zu KI für Entwickler drehen sich meist ums Schreiben von Code, und das ist der Teil, den Editoren schon abdecken. SideNote Pro hilft beim Rest des Tages: unbekannten Code lesen, Fehlschläge verstehen und Fragen zu einer Codebasis beantworten.
Fragen zu einem Repository stellen
Indizieren Sie einen Projektordner in Settings, Folder context. Erzeugte Verzeichnisse und solche von Fremdcode wie .git, node_modules, bin, obj, dist und build werden automatisch ausgeschlossen, der Index bildet also Ihren Code ab und nicht Ihre Abhängigkeiten.
Am wertvollsten ist das bei einer Codebasis, die Sie nicht selbst geschrieben haben. Fragen, die sich am ersten Tag lohnen:
- Wo ist die Authentifizierung konfiguriert, und welche Dateien legen den Ablauf von Sitzungen fest?
- Welche Dateien behandeln Datenbankmigrationen, und in welcher Reihenfolge laufen sie?
- Wo liegt die Wiederholungslogik für ausgehende HTTP-Aufrufe?
- Welche Konfigurationswerte werden beim Start gelesen, und wo liegen ihre Standardwerte?
Die Liste Sources ist oft nützlicher als die Antwort in Fließtext. Sie nennt die vier Dateien, die Sie öffnen sollten, und das war die eigentliche Frage. Open und Reveal sind von dort einen Klick entfernt.
Die Suche ist lexikalisch, passen Sie sich also dem Vokabular der Codebasis an. Wer nach session expiry fragt, findet Code, in dem session expiry steht. Von logout timing aus schlägt sie keine Brücke. Wenn eine Suche danebengeht, formulieren Sie mit den eigenen Wörtern des Codes um.
Settings › Folder context
Fehler einordnen, ohne das Terminal zu verlassen
Markieren Sie irgendwo einen Stacktrace oder eine Fehlermeldung, in einem Terminal, einem Protokollbetrachter, einer Browserkonsole, drücken Sie Ctrl+Shift+Q (Ctrl ist die Taste Strg), tippen Sie das eine, was der Trace nicht enthält, und wählen Sie die Zeile Ask. Oder geben Sie Ask SideNote eine eigene Tastenkombination und tippen Sie Ihre Frage im Eingabebereich.
Dieser letzte Teil ist wichtig. Ein Stacktrace sagt dem Modell, wo es gebrochen ist. Was er dem Modell nicht sagen kann, ist, was Sie gerade getan haben, was sich kürzlich geändert hat oder was Sie erwartet haben. Das begann, nachdem wir den Job nebenläufig ausgeführt haben macht aus einer allgemeinen Antwort eine nützliche.
Eine eigene Aktion, die sich lohnt: Erkläre diesen Fehler jemandem, der diese Codebasis nicht kennt, und nenne dann die drei wahrscheinlichsten Ursachen in der Reihenfolge ihrer Wahrscheinlichkeit: {{selection}}. Legen Sie sie auf eine Taste, und sie wird zum Reflex bei jedem unbekannten Fehlschlag.
Halten Sie die Befehle, die Sie immer wieder nachschlagen, als Active Note fest: einen Build-Aufruf, eine Checkliste für das Deployment, eine Abfrage, die Sie einmal im Monat ausführen. Lassen Sie sie beim Arbeiten schweben (Float), oder hängen Sie sie mit passe diesen Befehl an die Staging-Umgebung an an, wenn sie geändert werden muss. Die Antwort ist Text, und nichts wird ausgeführt, bis Sie es selbst ausführen.
Festhalten, was sich nicht einfügen lässt
- Ein Darstellungsfehler
- Bereichsaufnahme, dann dieses Layout bricht bei dieser Breite, welches Element läuft am wahrscheinlichsten über? In Verbindung mit dem Ordnerkontext über Ihren Quellcode erhalten Sie eine Datei statt allgemeinen Rats.
- Ein Diagramm aus einem Profiler oder Monitoring
- Was legt dieses Muster darüber nahe, wohin die Zeit geht?
- Der Fehlerdialog eines Programms
- der sich den Text nicht markieren lässt.
Ctrl+Shift+Xnimmt ihn auf, von dort, wo Sie sind. - Ein Diagramm in einer Dokumentation
- Eine Bereichsaufnahme schlägt es, ein Architekturdiagramm in Prosa zu beschreiben.
Ihr Modell braucht für all das Unterstützung für Bilder. Das ist bei lokalen Anbietern zu prüfen, wo die Bildunterstützung vom Modell abhängt.
Die Tiefe dem Problem anpassen
Entwicklerfragen lassen sich sauber trennen, und die Trennung zu nutzen lohnt sich, weil der Kostenunterschied groß ist.
| Schnell | Tief |
|---|---|
| Was macht diese Funktion? | Warum gerät das nur unter Last in einen Deadlock? |
| Wie lautet die Syntax dafür? | Ist diese Migration sicher, wenn gleichzeitig geschrieben wird? |
| Schreibe einen regulären Ausdruck, der darauf passt | Welcher dieser beiden Entwürfe fällt bei einer Partition schlechter aus? |
| Erkläre diese Fehlermeldung | Finde die Race Condition in dieser Abfolge |
| Fasse dieses Changelog zusammen | Was bricht zuerst, wenn wir das um das Zehnfache skalieren, und warum? |
Die linke Spalte ist der Großteil der täglichen Nutzung und braucht kein schweres Modell. Eskalieren Sie, wenn eine schnelle Antwort sichtbar oberflächlich ist, statt gleich tief zu beginnen. Siehe ein Modell für jede Aufgabe.
Code lesen und Änderungen prüfen
- Markieren Sie eine unbekannte Funktion und drücken Sie Explain. Schneller, als sie kalt zu lesen, und Sie lesen sie danach trotzdem.
- Markieren Sie einen Diff und bitten Sie um eine Commit-Nachricht. Eine lohnende eigene Aktion.
- Fragen Sie bei Ihrer eigenen Änderung was würde ein Reviewer hieran beanstanden, bevor Sie einen Pull Request öffnen.
- Fragen Sie bei allem, was Eingaben verarbeitet, was setzt dieser Code voraus, das nicht geprüft wird.
- Indizieren Sie bei einem Entwurfsdokument den Ordner, in dem es liegt, und fragen Sie, was ihm an anderer Stelle widerspricht.
Alles hier liefert Anhaltspunkte, keine Urteile. Die KI-Lesart eines Nebenläufigkeitsverhaltens ist eine Hypothese, die es zu prüfen gilt, und Code, den sie vorschlägt, ist Code, der Ihnen gehört, sobald Sie ihn zusammenführen. Lesen Sie ihn, wie Sie den Vorschlag eines Kollegen aus dem Gedächtnis lesen würden: oft nützlich, nie maßgeblich.