Qual è una politica di revisione del codice interna ragionevole?

Question

Qual è una politica di revisione del codice interna ragionevole?

#1 da (5 voti)

4

In una compagnia di circa 100 sviluppatori e ~ 2 pen-tester, viene sviluppato un prodotto. Ogni giorno arriva una buona quantità di codice diverso tramite le richieste PR di github.

L'obiettivo è rivedere il maggior numero possibile di nuovo codice prima che venga unito.

Da una parte all'estremo, sarebbe qualcosa come 'rivedere ogni PR e non consentire l'unione prima dei veterinari di pen-tester. "Chiaramente questo è molto dispendioso in termini di risorse. L'altro estremo sarebbe" lascia tutto passare e eseguire test di penna per modulo sulle versioni ".

Esistono significative strategie di copertura delle pubbliche relazioni tra questi due estremi?

Nota: non chiedendo di integrare l'analisi automatica del codice nella pipeline di build, l'obiettivo è di avere l'audit manuale per il maggior numero possibile di codice in modo significativo. Inoltre, non chiedendo dei metodi di revisione del codice (come la metodologia per identificare alcune classi di bug).

git code-reviews

posta bgd223 23.01.2018 - 16:09

fonte

1 risposta

Leggi altre domande sui tag git code-reviews

Crea una singola classe per mappare oggetti diversi su un oggetto di destinazione? L'unità di lavoro dovrebbe creare un repository?

score 5 · Answer 1

Suggerirei di creare un elenco di tipi di modifiche che richiedono di firma del tester di penna su richieste pull, come ad esempio:

Aggiunta di una nuova query SQL.
Uso di una nuova libreria.
Modifica di cose da fare con password, carte di credito o altre informazioni sensibili.
Creazione o ricezione di nuove connessioni di rete.
Correzioni per vulnerabilità note.
Hotfix urgenti che entreranno in produzione prima di poter eseguire il test completo della penna.

Questo è solo un esempio. I tuoi esperti dovrebbero essere in grado di creare un elenco migliore per il tuo dominio specifico.

Inoltre, puoi fare in modo che una politica lasci aperte le richieste di pull abbastanza a lungo da permettere ai pen-tester di scegliere di rivedere altri tipi di modifiche, se lo desiderano. Seguo un programma di pomodoro, quindi controllo la posta ogni mezz'ora. È super fastidioso avere qualcosa di importante da dire su un PR che è stato aperto e unito in quel lasso di tempo.