filosofia di sviluppo del backend

3

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?

    
posta Mazyod 21.02.2014 - 16:25
fonte

1 risposta

5

Debugging / TESTING!

  • L'unità verifica il diavolo dal tuo codice back-end. Di solito è più semplice del codice frontend di test di unità, perché il codice non è in attesa di clic o pressioni di tasti arbitrari. È tutto "arrivano questi dati, questi dati si spengono". Il test aggressivo delle unità ti farà accelerare in modo fenomenale perché non devi ricominciare dall'inizio per convalidare ogni piccola parte di codice. E poi avrai quei test in giro come test di regressione.

  • Esiste un TDD (sviluppo basato su test) che dice che dovresti scrivere i tuoi primi , e quindi inserire il codice che li fa funzionare. Ma posso farlo solo a metà e affermare che sto usando lo "stile londinese". Ma se ti piace, è una buona pratica.

  • Come high water mark: in Python, mirano al 100% di copertura del test e amp; è abbastanza facile da colpire.

  • Sono uno di quei ragazzi che non usa quasi mai un debugger. Piuttosto, io uso i test unitari per fare garanzie riguardo al comportamento e alla registrazione sensibile. Ma questa è solo la mia preferenza.

Il parallelismo

  • Più importante per far funzionare la cosa a tutti IMHO

Visualizing

  • Trovo che questi diagrammi siano essenziali per il mio lavoro: diagramma di sequenza e (meno così) diagramma ER e diagramma di stato

  • Controlla link . Ti salverà la vita su un progetto complicato, e anche su quelli semplici aiuti davvero a visualizzare le interazioni client-server.

  • Se disegna un diagramma di sequenza, non solo mostrerà le interazioni client-server, ma ogni freccia che punta al tuo servizio è un metodo API che devi implementare. Abbastanza utile e amp; molto diretto.

  • Sì, utilizzo i diagrammi ER sia per la progettazione del database che per la progettazione della classe quando i dati raggiungono una certa complessità.

  • A volte un diagramma di stato può essere molto utile.

La mia opinione è che lo sviluppo del backend sia più facile rispetto allo sviluppo del frontend perché vedo il mio lavoro come "spostare byte da qui a lì". Ma potrebbe essere solo perché sono davvero pessimo per lo sviluppo del frontend.

    
risposta data 21.02.2014 - 16:54
fonte