Mi sento un po 'perso in questo processo di sviluppo backend che sto tentando in questo momento. La maggior parte delle solite pratiche di sviluppo che utilizzo durante lo sviluppo di applicazioni lato client non si applicano qui ... Consentitemi di fornire un contesto.
Il processo di debug
Durante lo sviluppo di un'applicazione lato client (iOS, app desktop Java o qualsiasi altra cosa), è facile impostare rapidamente il progetto sul tuo IDE preferito, farlo funzionare sul tuo computer o su un dispositivo di test e eseguire il debug di quanto vuoi.
D'altra parte, non è così semplice collegare un debugger al tuo codice back-end, specialmente se si tratta di codice Python in esecuzione su Google App Engine (GAE). Questo è quello che sto usando, e ... sì. Linters e tutti aiutano MOLTO, ma ancora, i problemi semantici non possono essere risolti in questo modo, ovviamente.
Attualmente sto esaminando il mio codice backend scritto di recente e seppellisco solo con le dichiarazioni logging.debug ('msg'), asserzioni e quant'altro. Questa è l'unica cosa che riesco a pensare. È normale per gli sviluppatori di back-end? Il logging e scavare attraverso i log di solito come gli sviluppatori di backend iterano sulle loro applicazioni?
Parallelismo e richiesta guidata
Questo potrebbe essere un po 'più specifico per GAE e altri backend non bloccanti, onestamente. I server a thread singolo non soffrono di questo problema ... Comunque, quando si ha a che fare con il parallelismo e tutto è guidato da eventi di socket, come fanno gli sviluppatori di back-end di solito a testare se il loro back-end funziona?
Ho fatto la cosa più ingenua di tutti i tempi, ovvero aprire la console python e utilizzare la libreria delle richieste semplicemente inviando richieste e test a poco a poco. Poi, sono andato avanti e ho scritto un'app kivy per aiutarmi ad inviare le richieste da un'interfaccia GUI e vedere cosa sta succedendo, ma ci vuole più tempo per mantenere l'app kivy che sviluppare il backend !! Ho provato a verificare i framework di test per GAE, ma non sembravano facili da ottenere, quindi mi chiedevo se ne valeva la pena? Sarei in grado di simulare centinaia di client usando il mio backend usando i framework di test? Che cosa usano le persone in questi giorni (per GAE in particolare)?
Visualizzazione del "flusso"
A causa della mia inesperienza con lo sviluppo del backend, è difficile per me sorprendentemente difficile mantenere un'immagine chiara del ciclo di richiesta / risposta nella mia testa. Conosco le nozioni di base, ho scritto alcune app di backend, ma non appena diventa un po 'complesso, devo continuare a ricordare a me stesso dove passa la richiesta guardando il punto di ingresso e tutti i passaggi fino alla risposta fatto. Sono sicuro che se fossi in grado di visualizzarlo in qualche modo, non devo continuare a tornare più e più volte. Invece, vorrei sapere facilmente da dove proviene un bug, per esempio, o dove è il posto migliore per aggiungere una determinata funzionalità.
In ogni caso, mi chiedevo se esistesse una sorta di "cosa" standard per progettare il flusso delle richieste. Non lo so, forse un diagramma UML o qualcosa del genere? Ho provato a delinearlo, ma ho finito con un casino. Ad esempio, vorrei abbozzare il design del backend in base alle caratteristiche e ai requisiti, ma in questo caso la logica e il modello effettivi verrebbero ignorati. Poi, cerco di includere quelli nel diagramma, e diventa eccessivamente complesso e ingombra di molte frecce e scatole strane. Ho bisogno di qualcosa per supportare lo sviluppo, come i diagrammi ER per la progettazione di database relazionali .
Sì, mi dispiace. Parlo molto e sono perso in questo mondo. Aiuto?