Lavorando su un problema che si basa sulla modifica del codice

Question

Lavorando su un problema che si basa sulla modifica del codice

#1 da (4 voti)
#2 da (3 voti)

3

Lavoro in un piccolo team che crea software, corriamo molto vicino a scrum, ticket e sprint e usiamo git. Io comunque lavoro in un fuso orario diverso, quindi la comunicazione può essere un po 'sconnesso, anche se per il resto molto buona.

Recentemente ho lavorato su alcuni biglietti che si basano su una funzione che non ha superato PR. Ciò può comportare modifiche sostanziali al mio ramo "base".

A questo punto ho lavorato su un ramo fuori da questo ramo di funzionalità iniziale, solo per averlo cambiato. A volte cambia molto. Abbiamo "aggirato" questo utilizzando un numero di mezzi. Inizialmente, chiudendo il PR iniziale e riportando tutte le modifiche e i commenti nel PR della seconda funzione.

Al momento ho "preso" il ticket e il PR di un altro sviluppatore e apporterò le modifiche richieste mantenendo aggiornato il secondo ramo delle funzionalità.

Questo ha causato problemi per me, in testa dovendo destreggiarsi con numerose funzionalità e mantenere le filiali aggiornate. Ha causato problemi alla squadra, c'è stata confusione sul PR che cosa va dove chi è responsabile di cosa. Questi hanno causato alcune nottate mentre lavoro nel loro fuso orario per sistemare tutto.

Posso pensare a un numero di soluzioni, ma nessuna senza problemi:

Ruota le funzionalità che fanno affidamento l'una sull'altra in biglietti singoli e PR, in questo modo non ci sono dipendenze di ticket. Tuttavia i biglietti diventerebbero enormi e ingombranti, i PR sarebbero ugualmente così
Non funziona su una funzione che ha predecessori non completati. In questo modo lo "stato fondamentale" non si muoverà mentre ci lavori. Tuttavia, cerchiamo di concentrarci su un compito alla volta e questo porta ad avere queste dipendenze, se aspettassi queste potrei perdere un sacco di tempo.

Prima che cambi il fuso orario, eviteremmo tutto questo lavorando su biglietti con una grande quantità di dipendenze, e facendolo finire il più rapidamente possibile. Tuttavia, la differenza di fuso orario rende difficile (revisione 24 ore su 24).

teamwork scrum pull-requests

posta baler 21.06.2018 - 15:07

fonte

2 risposte

Leggi altre domande sui tag teamwork scrum pull-requests

Come evitare di spararti ai piedi quando usi la chiusura in JavaScript Come progettare la classe degli utenti

score 4 · Answer 1

Non esiste una soluzione * per il problema di fondo di "cosa succede se qualcuno cambia il codice su cui stavo lavorando prima di completare le mie modifiche", puoi solo gestire il processo.

Tradizionalmente le filiali di funzionalità mitigano il problema, perché puoi lavorare sulla tua versione del codice e apportare periodicamente modifiche alle altre persone secondo la tua velocità. Correggere i problemi di unione.

Questo non è di grande aiuto se si hanno rami delle funzionalità di lunga durata con molti cambiamenti, anche se si può essere secondi dopo il completamento dei mesi di lavoro quando un collega commette i suoi 3 mesi di cambiamenti, lasciandovi una mastodontica fusione e refactoring di tutto il tuo lavoro.

Suggerirei lo standard:

Funzioni più piccole
Frequente "rifinitura" e fusione nel ramo della funzione
Accoppiamento lento del codice

e forse potresti fare un po 'di codifica di contratti come le interfacce prima di eseguire l'implementazione. In questo modo il ramo base dovrebbe essere pronto per le tue modifiche, prima che tu cambi, se questo ha un senso.

_{* la soluzione è ovviamente quella di ottenere il tuo impegno in primo luogo e andare a pranzo.}

score 3 · Answer 2

Se hai sempre un intervallo di tempo di 24 ore prima di ricevere un feedback su una richiesta di pull, e ti trovi nei guai se viene rifiutato perché il tuo prossimo lavoro dipende da esso, vuoi renderlo molto probabile richieste approvate, specialmente quelle in cui altri lavori dipenderanno da loro.

La prima misura che suggerirei è di verificare se sia possibile suddividere importanti cambiamenti in sezioni di feature più piccole. Se riesci a suddividere un PR grande in due più piccoli, il primo include le modifiche importanti necessarie per l'implementazione di altre funzionalità, il secondo con modifiche meno importanti, aumenterai la possibilità di approvare le modifiche importanti, anche se le modifiche meno importanti vengono rifiutate.

Inoltre, dovrebbe essere trasparente per il revisore quando un PR è un prerequisito per i tuoi prossimi passi di lavoro. Il vostro revisore conosce anche il ritardo temporale e deve essere consapevole del fatto che il rifiuto di modifiche importanti solo a causa di alcuni problemi formali minori renderà le cose molto inefficaci. Permettendogli di riparare cose come errori di battitura evidenti, indentazione errata, violazione accidentale degli standard di codifica. Per tali problemi, non dovresti dover attendere 24 ore per ottenere le modifiche nel ramo principale dello sviluppo.

Infine, attiva / disattiva può essere un buon modo per integrare "metà caratteristiche "al forno". Il commutatore dovrebbe attivare la funzione solo nell'ambiente di sviluppo, ma non nel test o nell'ambiente di produzione.

Aggiungi una funzione per attivare la "funzione iniziale" che la rende invisibile per gli utenti e tutti i set di funzioni dipendenti. Questo può spesso rendere più semplice per il tuo revisore accettare la richiesta di pull, purché il cambiamento non causi alcun danno reale ad altre parti del sistema.

Inoltre, rendendo tutte le nuove feature slice che dipendono dalla modifica iniziale dipende dal commutatore, rendi la dipendenza esplicita e non devi destreggiarla nella tua testa. La dipendenza diventerà anche più trasparente per il resto della squadra.

Ovviamente, per fare in modo che funzioni, il revisore dovrebbe dirti che accetta il tuo PR per ora, ma prima che l'interruttore di funzione sia finalmente rimosso (e il set di funzionalità rilasciato in produzione), lui / lei ti aspetta per cambiare un elenco di cose. E quando commetti il PR finale per rimuovere l'interruttore, lui / lei può controllare di nuovo questo elenco per assicurarsi che nulla sia stato dimenticato.

Nel caso in cui la richiesta di pull non sia accettata, probabilmente sarà meglio lavorare sui problemi del rifiuto prima di costruire più codice su di esso. Ma anche in questo caso, avere il codice dipendente che controlla l'attivazione delle funzionalità renderà più semplice l'ordinamento delle dipendenze delle funzionalità.