Zum Hauptinhalt springen
Stellen Sie sicher, dass Sie When to Use Devin und Instructing Devin Effectively für weitere wichtige Tipps lesen.

Hinzufügen eines neuen API-Endpunkts

Gute Vorgehensweise
“Erstelle einen neuen Endpunkt /users/stats, der ein JSON-Objekt mit der Anzahl der Benutzer und dem durchschnittlichen Registrierungsalter zurückgibt. Verwende dazu unsere bestehende users-Tabelle in PostgreSQL. Du kannst den Endpunkt /orders/stats in statsController.js als Vorlage für die Struktur der Responses verwenden. Stelle sicher, dass der neue Endpunkt in der Test-Suite StatsController.test.js abgedeckt ist.”
Warum das funktioniert:
  • Gibt Route und erwartetes Antwortformat klar an
  • Verweist auf bestehenden Code als Vorlage
  • Definiert die Datenquelle (users-Tabelle)
  • Enthält Anforderungen an die Testabdeckung


Schlechte Vorgehensweise
“Füge einen Endpunkt für Benutzerstatistiken hinzu.”
Warum das fehlschlägt:
  • Unspezifisch, welche Statistiken enthalten sein sollen
  • Keine Erwähnung von Datenquellen
  • Kein Verweis auf bestehende Muster/Konventionen
  • Fehlende Testanforderungen

Frontend-Feature zur Datenanzeige

Gute Vorgehensweise
“Füge in UserProfileComponent ein Dropdown hinzu, das eine Liste von Benutzerrollen (admin, editor, viewer) anzeigt. Verwende das Styling von DropdownBase. Wenn eine Rolle ausgewählt wird, rufe die bestehende API auf, um die Benutzerrolle zu setzen. Überprüfe, ob die Auswahl die Benutzerrolle in der DB aktualisiert. Sieh in deinem Knowledge nach, wie du das korrekt testest.”
Warum das funktioniert:
  • Benennt konkrete Komponenten
  • Listet die exakten Rollen auf, die enthalten sein sollen
  • Verweist auf eine bestehende Styling-Komponente
  • Definiert den Ablauf der Benutzerinteraktion
  • Enthält Validierungsschritte


Schlechte Vorgehensweise
“Mache die Benutzerprofilseite benutzerfreundlicher. Füge irgendeine Möglichkeit hinzu, Rollen zu ändern, und bestätige, dass es funktioniert.”
Warum das fehlschlägt:
  • „Benutzerfreundlich“ ist subjektiv
  • Keine spezifischen UI-Komponenten erwähnt
  • Unklarer Ablauf der Benutzerinteraktion
  • Vage Validierungskriterien

​
Weitere Beispiele

​
Gut

Schreiben von Unit-Tests

“Füge Jest-Tests für die AuthService-Methoden login und logout hinzu. Stelle sicher, dass die Testabdeckung für diese beiden Funktionen mindestens 80 % beträgt. Verwende UserService.test.js als Beispiel. Führe nach der Implementierung npm test -- --coverage aus und überprüfe, dass der Coverage-Bericht >80 % für beide Funktionen anzeigt. Bestätige außerdem, dass die Tests sowohl mit gültigen als auch mit ungültigen Anmeldedaten erfolgreich sind und dass logout die Sitzungsdaten ordnungsgemäß löscht.”
Warum gut? Klare Erfolgsmetrik (80 % Abdeckung), Referenzen, an denen sich Devin orientieren kann (UserService.test.js), und ein klar abgegrenzter Umfang mit konkreten Überprüfungsschritten.

Migration oder Refactoring von bestehendem Code

“Migriere logger.js von JavaScript zu TypeScript. Wir haben bereits eine tsconfig.json und eine Test-Suite LoggerTest.test.js zur Validierung. Stelle sicher, dass der Code ohne Fehler kompiliert, und ändere auf keinen Fall die bestehende Konfiguration! Überprüfe die Migration anschließend, indem du: 1) tsc ausführst, um sicherzustellen, dass keine Typfehler auftreten, 2) die Test-Suite mit npm test LoggerTest.test.js ausführst, um sicherzustellen, dass alle Tests erfolgreich sind, und 3) kontrollierst, dass alle bestehenden Logger-Methodenaufrufe in der gesamten Codebasis weiterhin ohne Typfehler funktionieren.”
Warum gut? Es gibt eine klare Vorlage (tsconfig.json) und eine Test-Suite für direktes Feedback, plus konkrete Schritte für Kompilierung und Validierung.

Aktualisieren von APIs oder Datenbankabfragen

“Wir wechseln von pg zu sequelize (siehe https://sequelize.org/api/v6/identifiers). Bitte aktualisiere die UserModel-Abfragen so, dass sie Sequelize-Methoden verwenden. Sieh dir dafür OrderModel an, um zu verstehen, wie wir das in dieser Codebasis handhaben. Überprüfe nach der Implementierung, indem du: 1) npm run test:integration UserModel.test.js ausführst, um sicherzustellen, dass alle Integrationstests erfolgreich sind, 2) bestätigst, dass sich die Abfrageperformance nicht verschlechtert hat, indem du die Ausführungszeit auf einem Testdatensatz mit 1000 Usern prüfst, und 3) validierst, dass alle CRUD-Operationen weiterhin die Datenintegrität sicherstellen, indem du npm run test:e2e user-flows.test.js ausführst.”
Warum gut? Devin kann ein bekanntes Muster nachahmen, und es gibt explizite Referenzen (OrderModel.js). Es wird ein Link zur Dokumentation bereitgestellt, damit Devin weiß, dass er diese heranziehen soll, und es sind konkrete Schritte zur Überprüfung von Performance und Funktionalität mit exakten Testbefehlen enthalten.

​
Schlecht

Unstrukturierte Code-Reviews

„Finde Probleme in unserer Codebasis und behebe sie“
Warum schlecht? Die Anfrage ist zu vage und verlangt, dass Devin zu viele Aufgaben in einer einzigen Sitzung erledigt. Devin kann in langen Sitzungen durcheinanderkommen.

Visuelle Designaufgaben

„Baue exakt das nach, was in diesem Figma-Mockup zu sehen ist“
Warum schlecht? Dies ist eine subjektive visuelle Anfrage. Devin kann nicht „sehen“ wie Menschen und wird die Details nicht perfekt treffen. Devin ist nicht für solche Anwendungsfälle optimiert.

Hochkomplexe, vage Projekte

„Baue eine neue Microservices-Architektur für unsere App.“
Warum schlecht? Dies ist eine sehr große und unstrukturierte Aufgabe. Sie erfordert Architekturentscheidungen und Abwägungen.Teile stattdessen komplexe Projekte in Phasen auf:
  1. Lass Devin deine Codebasis untersuchen
  2. Bitte Devin, konkrete Architekturen vorzuschlagen
  3. Erstelle separate Sitzungen für die Implementierung der einzelnen Teile