La programmazione delle coppie funziona bene quando si tratta di sviluppatori backend e sviluppatori frontend che lavorano insieme? [chiuso]

Secondo me ci sono i seguenti vantaggi della programmazione della coppia:

• Due peope controllano la coerenza logica lungo la strada
• Il codice diventa più leggibile e comprensibile
• È più probabile trovare bug fastidiosi e errori di battitura durante la scrittura del codice
• Una persona può scrivere test / documentazione insieme a

La connessione principale tra front e backend sono interfacce. Le buone interfacce possono essere il risultato della programmazione di coppie, ma penso che le interfacce dovrebbero essere definite prima si inizia a scrivere il codice.

Personalmente rotolerei con il terzo punto, ma penso anche che non c'è niente di sbagliato nel secondo punto se il team di sviluppo è piccolo. Non mi piace il primo punto, perché penso che la programmazione della coppia tra due programmatori con lo stesso campo di attività sarà più produttiva.

In parole semplici:

• Nella programmazione in coppia entrambi i partner possono guidare e navigare su lo stesso codice di , quindi il 1o punto non è quello che si potrebbe chiamare programmazione di coppia.
• Se le cose sono fatte bene, il frontend dos non ha bisogno di sapere la struttura o il database.
• Scrivere la documentazione prima di scrivere il codice è al massimo atipico

Il mio suggerimento: - avere un paio di programmatori in coppia, programmare il frontend e un paio di programmatori in coppia programmano il backend. - Se hai solo due programmatori, falla programmare in coppia il back-end, quindi il front-end. - Se sia il frontend che il backend devono avanzare simultaneamente (e hai solo due programmatori), allora lascia che ogni programmatore faccia il suo lavoro da solo.

Sì, perché no.

Quello che ottieni dalla programmazione di coppia è il vantaggio di qualcun altro che guarda una panoramica di ciò che sta accadendo con il codice, mentre il codificatore principale viene catturato nei dettagli. Ottieni anche dalla diffusione della conoscenza che trasferirà tra i due.

Quindi, in questo caso, il tuo back-end sarà in grado di codificare l'interfaccia che il front-end utilizzerà più tardi e conoscerà l'interfaccia con cui verrà presentato più tardi - può anche suggerire aggiunte perché saprà quali dati vuole lì e poi, salvando la costosa rilavorazione più tardi. E viceversa.

Entrambi i ragazzi acquisiranno conoscenza del prodotto da un'area sconosciuta, lo vedranno essere utilizzato e testato e conosceranno la configurazione e la configurazione di esso. Anche se non diventano sviluppatori cross-area, i benefici saranno ancora visibili nella conoscenza generale del prodotto.

Dipende

Ho lavorato in un negozio molto piccolo dove eravamo tutti a ore fatturabili. Ti è stata assegnata l'intera attività front-end, back-end (che includeva qualsiasi tipo di database) e le ore specificate. Dopo un anno circa di fare tutti i compiti individualmente, abbiamo deciso di collaborare e lavorare insieme. Ero molto più adatto per il javascript errore di trapping e back-end, in particolare il lavoro di database. Il mio amico era molto più adatto per cose e configurazioni front-end.

Abbiamo deciso di collaborare, mettere in comune il nostro lavoro e le ore. Ha funzionato alla grande. Mi sono concentrato sulle cose di backend per costruire i miei pezzi in modo da poterli ritagliare all'interno di un set di < div > / lt; / div > tag.

Il mio compagno ha fatto il lavoro di layout sapendo che tutto ciò di cui avevo bisogno era come set di < div > < / div > tag.

Poi saltavo su tutti gli errori di javascript toccando e lui faceva tutta la configurazione.

Ognuno di noi si è concentrato su ciò in cui eravamo più forti. Più lavoro è stato fatto con meno stress.