Come rispondere a richieste bizzarre nelle revisioni del codice? [chiuso]

2

Penso che le recensioni del codice siano grandiose e molto utili per tutti. Detto questo, di tanto in tanto ho ricevuto un feedback su una richiesta di pull (che porta al ritardo del PR per almeno il tempo necessario per un altro giro di risposte da parte di tutti gli interessati, se non più a lungo) che penso sia così completamente fuori dal campo di sinistra che non so nemmeno come rispondere. Ad esempio:

  • (discutendo di un sito web a pagina singola costruito con un framework simile ad Angular): "Penso che dovremmo servirli come pagine separate perché altrimenti gli utenti saranno confusi"

  • (discutendo di una funzione stdlib di C89 / C99 / C11): "Penso che dovremmo evitare questo per motivi di portabilità e ri-implementarlo da soli"

  • (discutendo delle funzionalità per le quali abbiamo bisogno di un'estensione per compilatore): "Anche se lo usiamo in molti altri punti, penso che dovremmo implementarlo di nuovo qui per motivi di portabilità"

Anche se non voglio stabilire un tono negativo durante le revisioni del codice, trovo molto difficile non essere frustrato da commenti come questo, specialmente quando il revisore ne è molto insistente (vale a dire più turni di discussione avanti e indietro ). Quando vedo commenti come questo, sospetto strongmente che il recensore stia solo cercando una scusa per parlare, e che lui o lei avrebbe trovato qualche motivo per permutare in modo semi-casuale praticamente qualsiasi richiesta di pull inviata. Ritengo che ciò sovverte il punto del processo di revisione del codice e riduca la produttività del team nel suo complesso.

Non so come rispondere a questo tipo di domande senza uscire negativamente, perché trovo difficile credere che siano state fatte in buona fede (ad esempio se si preoccupa sinceramente che la funzionalità garantita dalle specifiche della propria lingua non sia abbastanza portatile da usare, come fai a fare qualcosa?). Come posso rispondere efficacemente a questo tipo di commento?

    
posta Patrick Collins 08.03.2016 - 01:05
fonte

1 risposta

4

Devi posizionare le revisioni del codice nel tuo processo di sviluppo. Le recensioni del codice non dovrebbero probabilmente essere l'unico posto per il feedback, poiché ovviamente alcuni feedback avrebbero dovuto essere espressi, discussi e elaborati molto prima. Ancora altri feedback dovrebbero generare il proprio filo di lavoro senza necessariamente influire sull'attuale elemento di lavoro in esame.

Il primo punto elenco dovrebbe probabilmente essere off-topic per la revisione del codice e invece essere in argomento durante le riunioni dei clienti, le mischie o le discussioni sulle storie degli utenti. In altre parole, è una questione di progettazione dell'interazione con il cliente; come tale avrebbe dovuto essere sollevato in precedenza, e avrebbe dovuto essere sollevato da qualcuno che rappresentava più il cliente / cliente piuttosto che i colleghi programmatori (che stanno rivedendo il codice reale).

Gli ultimi due punti elenco dovrebbero probabilmente generare il proprio thread di refactoring, ma non necessariamente contenere il codice in questione, in particolare, quando il codice in questione non è l'unico "autore del reato". In genere è consigliabile eseguire più check-in piccoli piuttosto che di grandi dimensioni, quindi ampliare in modo significativo lo scopo di alcune modifiche al codice al fine di incorporare un ampio refactoring (che richiede di correggere il codice al di fuori dello scopo di un check-in) sta confliggendo le cose, cioè un passo nella direzione sbagliata. Inoltre, è buona prassi tenere separati i refactoring e le modifiche delle caratteristiche quando possibile, come check-in separati, pertanto, ciò suggerisce anche che l'aggiunta di un refactoring nel check-in delle funzionalità (o il check-in di refactoring separato) è una combinazione di scopi.

    
risposta data 08.03.2016 - 02:35
fonte

Leggi altre domande sui tag