Attualmente sono responsabile della revisione di uno dei codici del mio compagno di squadra per un'app Web front-end. Abbiamo stabilito un flusso di lavoro che comporta la creazione di un ramo di funzionalità in git per ogni funzione che definiamo. Supponiamo che la nostra app ti consenta di scorrere un elenco di elementi e di fare clic sui dettagli dell'elemento, quindi il tipo di funzionalità che abbiamo definito fino ad ora sono "funzionalità elenco articoli", "stile elenco articoli", "funzionalità dettagli articolo", "dettaglio articolo" stile'. Una volta completata la funzione, ho chiesto al mio compagno di squadra di inviare una richiesta di pull e quindi lavoreremo attraverso il processo di revisione prima che la modifica venga accettata.
Per me, i vantaggi di separare le richieste di pull in modifiche logiche sono che possiamo garantire che tutto il codice sia focalizzato e non ridondante, che sia facile da recensire e che possiamo sperare di evitare un accoppiamento stretto dei componenti. Il mio compagno di squadra considera questo flusso di lavoro un ostacolo al progresso perché trova molto difficile attenersi a questa separazione tra i rami delle funzionalità.
Ho una serie di domande ...
Stiamo impostando la portata delle nostre funzionalità troppo strette?
Al momento la maggior parte dei vantaggi di mantenere concentrate le richieste di pull sono benefici per la persona che controlla il codice. Ci sono benefici per il mio compagno di squadra se separa le modifiche in questo modo?