Sviluppatore di frontend e backend che lavora su un progetto - chi inizia prima le attività?

Dovresti fare pianificazione delle funzionalità. In secondo luogo, lo sviluppatore del backend dovrebbe creare attività che saranno eseguite in un periodo di due settimane (scrum), lui / lei dovrebbe mantenere ogni attività aggiornata e usare un software come swagger per descrivere come appare l'API implementata. Inoltre, non dovrebbe modificare gli apis già implementati senza attività e conoscenza.

Quindi il tuo lavoro come sviluppatore frontend sarebbe molto più facile. Saprai quale parte di API è in fase di sviluppo, quale parte è già stata eseguita e puoi seguire swagger per sapere come usare api.

Inoltre, dovresti usare il più possibile la vera API perché in questo modo rilevi i bug in precedenza:)

Modifica: Penso che sarebbe bello se il team di back-end fosse di una settimana o tutto lo sprint di fronte a te. In questo modo avrai tutto ciò di cui hai bisogno una volta iniziato a lavorarci sopra.

you are never really sure how the backend dev will return the hashmap to the frontend

Ok, che è il tuo problema. Con questo problema come dato, non importa chi inizia a lavorare per primo - sarà comunque una scommessa.

Suggerirei che, dopo che "il web design è già stato completato e accettato", gli sviluppatori di frontend e backend incontrano e cancellano le varie API. Potrebbero persino preparare alcuni JSON statici di esempio che lo sviluppatore del frontend può testare, mentre lo sviluppatore del backend sa che sono ciò che dovrà inventare.

Per prima cosa progetterei i contatti dati, quindi entrambi inizieranno a lavorarci allo stesso tempo. Questo potrebbe cambiare, ma se progettato bene dovrebbe essere minimo. È la bellezza di avere la parte posteriore del front-end in livelli separati

Entrambi dovrebbero iniziare a funzionare per primi, ad esempio se lo sviluppatore frontend deve mostrare lo stato di un messaggio, entrambi dovrebbero funzionare insieme e uscire con un'API, ad esempio / api / v1 / status / 333 (GET), il risultato è un JSON, ecc.

Dovresti fare entrambe le cose contemporaneamente, con la collaborazione. Questo può dipendere in gran parte dalla tecnologia in gioco. Suppongo che per sviluppatore front-end intendi Xaml o Html / Css a seconda dell'applicazione, e backend, servizi Web, logica aziendale e logica di accesso ai dati.

Dovresti aver già collaborato abbastanza che entrambi sanno qual è l'obiettivo. Lo sviluppatore front-end può costruire l'intera interfaccia utente lavorando con oggetti DTO JSON codificati, mentre lo sviluppatore back-end può appianare tutti gli accessi ai dati, la business logic e i servizi web. Il DTO ei servizi web possono essere ottimizzati, poiché questi sono la colla in mezzo. Devi essere "vicino" a come potrebbe apparire il DTO, ma non deve essere esatto, ma dovresti aver collaborato prima di fare una "fine" del progetto, quindi non c'è questo grande aggiustamento quando necessità di integrare gli strati insieme. Questo include decidere in anticipo quali potenziali chiamate di servizio e oggetti di trasferimento dati potrebbero essere in gioco, e poiché ogni sviluppatore si imbatte in potenziali problemi o problemi di progettazione, dovrebbero collaborare l'un l'altro per alterare il progetto in quel punto e non alla fine .

Sembra che tu abbia un problema di processo / comunicazione.

Di solito è necessario prima completare il back-end in modo che lo sviluppatore front-end possa sostituire gli oggetti DTO codificati con chiamate di servizio effettive, e qui deve esserci qualche collaborazione, in particolare test di integrazione prima che questi bit vengano inviati ad un tester.

Abbiamo sviluppato diversi progetti con successo in questo modo e, se fatto bene, è possibile ottenere uno sviluppo simultaneo più veloce, piuttosto che uno sviluppo lineare. La nostra ragione per passare a questo approccio è che siamo un team di scrum, ma abbiamo lacune nelle competenze e diversi punti di forza, quindi stiamo utilizzando l'architettura stratificata in modo appropriato per consentire alle persone di lavorare nelle loro aree di forza e sviluppare le funzionalità contemporaneamente.

Avvertenza: non tutte le funzionalità o i progetti si prestano a questa metodologia, ma se puoi farlo, lo consiglio vivamente.