ce qui m'intéresse c'est du post-commit review (pour ne pas perturber les us et coutumes dans un premier temps).
C'est une fausse bonne idée, certes le pre-commit review bouscule les habitudes, mais ça aide à acquérir les bonnes habitudes (respect des coding standards, découper ses patchs, faire attention aux changement d'API/ABI, tests de non-régression etc...) parce que les développeurs au bout d'un moment auront marre de voir leurs patchs mal branlés refusés.
Le problème du post-commit reviewing, c'est que le reviewer va systématiquement passer son temps à corriger le code pourrave et les développeurs ne prendront jamais le temps de soigner leurs commits. VOire si le ratio reviewees/reviewers ou le volume de code est trop élévé, le système finit par imploser. En général, la revue de code à posteriori ne fonctionne que si tu as gelé la base de code (avant une release, ou pendant un audit).
[^] # Re: A tester ...
Posté par GeneralZod . En réponse à la dépêche Review Board 1.6. Évalué à 6.
C'est une fausse bonne idée, certes le pre-commit review bouscule les habitudes, mais ça aide à acquérir les bonnes habitudes (respect des coding standards, découper ses patchs, faire attention aux changement d'API/ABI, tests de non-régression etc...) parce que les développeurs au bout d'un moment auront marre de voir leurs patchs mal branlés refusés.
Le problème du post-commit reviewing, c'est que le reviewer va systématiquement passer son temps à corriger le code pourrave et les développeurs ne prendront jamais le temps de soigner leurs commits. VOire si le ratio reviewees/reviewers ou le volume de code est trop élévé, le système finit par imploser. En général, la revue de code à posteriori ne fonctionne que si tu as gelé la base de code (avant une release, ou pendant un audit).