Les normes / styles de codage doivent-ils être appliqués par le serveur d'intégration continue exécutant des outils d'analyse statique (ex. PMD, StyleCop / FxCop) et échouant à la construction si les normes ne sont pas respectées? Quels types de règles ne doivent pas être utilisés pour échouer la génération?
Réponses:
Les normes de codage devraient être là pour une raison ... et la non-conformité devrait être vérifiée.
Cependant, toutes les violations ne doivent pas être considérées comme des erreurs - tout comme toutes les violations de compilation ne le sont pas. Où vous tracez la ligne doit être une entreprise et une décision d'outil.
Par exemple, MISRA définit ses règles comme obligatoires et consultatives ... Je suggérerais que les avis permettraient à la construction de continuer.
Ce n'est pas complètement inconnu et vous saurez si cela fonctionnera pour vous uniquement en l'essayant. Il y a quelques étapes que vous pourriez prendre avant cela.
L'équipe doit d'abord décider ensemble des normes. Ensuite, des outils tels que ReSharper doivent être utilisés pour indiquer aux développeurs s'ils ne respectent pas les normes. Faire des évaluations par les pairs sur chaque tâche pourrait aider davantage.
Après avoir pris ces mesures, il pourrait être envisagé de placer des contrôles de codage standard sur le serveur CI. Cependant, il doit toujours être pris en compte s'il est sage d'avoir une pause de construction pour ne pas respecter les normes de codage. Le risque est que vous ayez beaucoup de builds cassés qui pourraient diluer le sens de build cassé.
Au lieu d'interrompre la construction, vous pouvez exécuter les outils et leur demander de créer des rapports. Si les violations de codage standard semblent augmenter, vous pouvez réunir l'équipe et comprendre pourquoi cela se produit.
Les normes / styles de codage doivent-ils être appliqués par le serveur d'intégration continue exécutant des outils d'analyse statique (ex. PMD, StyleCop / FxCop) et échouant à la construction si les normes ne sont pas respectées?
Ces contrôles d'intégration continus doivent être très, très rapides. Tout retard important signifie que vos programmeurs vont s'engager et perdre la trace de leur processus de réflexion en attendant les résultats. Allongez-vous et ils s'engageront et prendront une tasse de café ou discuteront avec leurs collègues de bureau des dernières performances ratées de certaines équipes sportives. Ces retards sont hautement contre-productifs. Il vaut mieux laisser certaines choses à la compilation nocturne ou à la révision du code.
Quels types de règles ne doivent pas être utilisés pour échouer la génération?
Les subjectifs, pour commencer. Comment appliquez-vous la règle "Le code doit être auto-documenté ou bien commenté"? La règle "pas de nombres magiques"? Ce sont des choses qu'il vaut mieux laisser à l'examen du code.
Une autre catégorie concerne les violations des règles auxquelles une dérogation a déjà été accordée. Étant donné n'importe quelle base de code importante, il y aura inévitablement une partie du code où violer la norme est exactement la bonne chose à faire.
Dans le cadre d'un plan d'amélioration de la qualité des logiciels, nous avons récemment codé une série de reniflements de code à intégrer dans notre processus de génération.
Nous construisons beaucoup, étant une application PHP, il n'y a pas de véritable compilation, donc la construction est vraiment un test unitaire / analyse statique / runner, et nous pouvons nous permettre de passer quelques cycles sur cela.
Nous avons eu des problèmes de qualité du code et du code hérité avec beaucoup de problèmes.
En partant du principe que s'il n'échoue pas, la validation sera ignorée, nous avons commencé à confirmer les validations par rapport à notre norme de codage `` souhaitée '', et les validations échouées avec des erreurs qui ne respectaient pas la norme.
La maintenance a été interrompue, même la réparation la plus simple d'un composant hérité a nécessité que le développeur reformate d'énormes quantités de source, et la construction a été interrompue le plus souvent. Inutile de dire que nous avons changé les erreurs en avertissements, et maintenant elles sont ignorées et «surtout» inutiles.
Je dirais donc ceci (appris d'une dure expérience).
Assurez-vous que la norme de votre base de code est suffisamment proche de la norme que vous appliquez pour que vous n'ayez pas besoin que les développeurs reformatent les volumes de code instantanément. Ou .. Vous êtes prêt et attendez l'augmentation de l'effort.
Étant une petite équipe avec une énorme exigence de livraison, nous ne pouvions pas nous permettre de faire passer l'équipe à une énorme opération de refacturation. Nos normes de codage sont désormais principalement gérées par révision manuelle, et l'héritage est en cours de réécriture dans le cadre d'un plan d'amélioration continue.
Quand j'ai dit que les avertissements étaient «principalement» inutiles, eh bien nous les utilisons maintenant pour enregistrer des statistiques qui nous permettent de mesurer les kpi qui devraient continuer à montrer une amélioration.
Lorsque nous appliquerons à nouveau le code renifle, nous allumerons la lumière et introduirons quelques reniflements à la fois jusqu'à ce que la norme soit appliquée.
Cela dépendra de votre objectif ultime et de votre stratégie .
Forcer toutes les bonnes normes mentionnées dans le serveur CI peut sembler très lucratif. Cependant, cela pourrait ne pas être pratique pour la grande équipe de développement (plus de 6 développeurs), si cela est fait à chaque validation sur le serveur. Attendre que votre serveur réponde après la validation ne devrait PAS être un long délai. Cela peut potentiellement provoquer des temps d'arrêt.
Cependant, il est totalement légitime de bloquer une validation si le code (le jeu de modifications en fait) a des problèmes de dépendance ou ne se compile pas. Cependant, l'échec du code en raison de la disposition du code et de certaines conventions de dénomination peut être trop sévère et ne pas constituer une restriction vitale pour les règles de validation du serveur CI.
Mais il est très probable que cette règle soit utile si elle est appliquée pendant la construction du soir.
De plus, les outils de refactorisation peuvent aider à la mise en œuvre et à l'apprentissage des normes - comme l' utilisation de Resharper ou JustCode par les développeurs.