Les inspections de code que je connais jusqu'à présent se font généralement lors de la phase d'intégration continue. Bien que cela puisse garantir la qualité du code, je pense personnellement que le coût est encore un peu élevé. Les principales raisons sont :
Un développeur termine finalement le développement sur sa propre branche, puis le pousse vers le serveur, puis l'intègre en continu. pour vérifier le code et constate que le style de code ne passe pas. Tout ce processus de rétroaction prend trop de temps.
Le projet Java en cours de développement espère pouvoir vérifier du code tel que (checkstyle, pmd, etc.). Ces vérifications doivent être réussies avant la soumission localement, au lieu d'être effectuées après avoir été poussées vers le référentiel de code. réaliser sont les suivants :
Doit passer l'inspection du code avant la soumission, sinon la soumission ne sera pas autorisée
Il est préférable d'avoir un support d'outils et de ne pas compter sur l'IDE
Le fichier de configuration de l'outil de vérification de code est préférable pour effectuer la gestion des versions
Solutions actuellement envisagées (pas encore essayées) :
Intégrez checkstyle et d'autres plug-ins dans maven
Utilisez un script dans git/hooks pour appeler maven pour vérification Si la vérification réussit la soumission, si elle échoue, la soumission est. pas autorisé
Il permet aux développeurs de pousser uniquement vers une branche qui ne peut pas être publiée (comme dev), et les développeurs de branches officiellement publiées (comme master) n'ont pas le droit de pousser directement.
Installez des plug-ins tels que checkstyle sur le serveur. Si la vérification réussit, le développement sera fusionné dans le maître. Si la vérification échoue, la fusion ne sera pas autorisée.
Vous avez bien compris, git hook sert à faire ces choses
Nous utilisons Sonar Qube pour vérifier et coopérer avec Jenkins pour vérifier pendant l'intégration continue.
Il n'est pas nécessaire de passer l'inspection avant la soumission, car nous laissons aux développeurs le temps d'apporter des modifications plus tard.
Personnellement, je pense que tant que le code peut être compilé et que les tests unitaires et d'intégration ont réussi, il peut être publié. Les problèmes détectés lors de l'inspection du code peuvent être intégrés à la prochaine itération de la version, et le chef de l'équipe de développement peut simplement regarder les développeurs apporter des modifications.