Une révision de code est-elle subjective ou objective (quantifiable)?

Je suis en train de mettre en place des lignes directrices pour les revues de code. Nous n'avons pas encore de processus formel et nous essayons de le formaliser. Et notre équipe est géographiquement répartie.

Nous utilisons TFS pour le contrôle du code source (nous l'avons également utilisé pour le suivi des tâches / des bogues / du projet, mais nous l'avons migré vers JIRA ) avec Visual Studio 2008 pour le développement.

Que recherchez-vous lors d'une révision de code?

• Ce sont les choses que je suis venu avec
  1. Appliquer les règles FxCop (nous sommes une boutique Microsoft)
  2. Vérifiez les performances (tous les outils?) Et la sécurité (pensez à utiliser OWASP - Code Crawler ) et la sécurité des threads
  3. Adhérer aux conventions de nommage
  4. Le code devrait couvrir les cas limites et les limites
  5. Devrait gérer les exceptions correctement (ne pas avaler les exceptions)
  6. Vérifier si la fonctionnalité est dupliquée ailleurs
  7. Un corps de méthode doit être petit (20-30 lignes) et les méthodes doivent faire une chose et une seule chose (pas d'effets secondaires et éviter le couplage temporel -)
  8. Ne pas transmettre / renvoyer les valeurs NULL dans les méthodes
  9. Eviter le code mort
  10. Documenter les méthodes / propriétés / variables publiques et protégées

Quelles autres choses devrions-nous généralement rechercher?

J'essaie de voir si nous pouvons quantifier le processus de révision (il produirait une sortie identique lorsque examiné par différentes personnes) le corps doit être petit ".

Ou bien la révision du code est-elle très subjective (et différerait-elle d'un critique à l'autre)?

L'objectif est de disposer d'un système de marquage (par exemple, -1 point pour chaque violation de règle FxCop, -2 points pour ne pas suivre les conventions de nommage, 2 points pour le refactoring, etc.) afin que les développeurs fassent preuve de plus de prudence lorsqu'ils archivent leur code. De cette façon, nous pouvons identifier les développeurs qui écrivent constamment du bon / mauvais code. L’objectif est de laisser le critique passer environ 30 minutes maximum pour effectuer une révision (je sais que cela est subjectif, étant donné que le groupe de modifications / révision peut inclure plusieurs fichiers / modifications majeures de l’architecture existante, etc. l’idée générale, le réviseur ne devrait pas passer des jours à réviser le code de quelqu'un).

Quel autre système objectif / quantifiable suivez-vous pour identifier le code bon / mauvais écrit par les développeurs?

Référence du livre: Clean Code: Un manuel sur la conception de logiciels agiles par Robert Martin .

Le classement des personnes dans une revue va à l'encontre des systèmes les plus performants avec lesquels j'ai travaillé, voire de tous. Mais l'objectif que j'essaie d'atteindre depuis plus de 20 ans est de réduire le nombre de bugs et d'augmenter la productivité par heure d'ingénieur. Si l’évaluation des individus est un objectif, je suppose que les examens pourraient être utilisés. Je n'ai jamais vu une situation où cela était nécessaire, en tant que travailleur ou en tant que chef.

Certaines études objectives (Fagan, etc.) et beaucoup de sagesse populaire suggèrent que les relations entre pairs facilitent la révision du code visant à réduire les bugs et à augmenter la productivité. Les gestionnaires qui travaillent peuvent participer en tant que travailleurs, mais pas en tant que gestionnaires. Les points de discussion sont notés, les modifications visant à satisfaire les examinateurs sont généralement une bonne chose, mais elles ne sont pas obligatoires. D'où la relation entre pairs.

Tous les outils automatisés pouvant être acceptés sans autre analyse ni jugement sont utiles: C, C ++, Java. Compilation régulière. Les compilateurs sont vraiment bons pour trouver des bogues de compilateur. La documentation des écarts dans les contrôles automatisés ressemble à une mise en accusation subtile des contrôles automatisés. Les directives de code (comme Java) qui autorisent les écarts sont assez dangereuses, à mon humble avis. Idéal pour le débogage, pour vous permettre de comprendre rapidement le cœur du problème. Pas si bon à trouver dans un bloc de code mal documenté, 50 000 dont vous êtes devenu responsable.

Certaines règles sont stupides mais faciles à appliquer; les valeurs par défaut pour chaque instruction switch même lorsqu'elles sont inaccessibles, par exemple. Ensuite, c’est juste une case à cocher, et vous n’avez pas à perdre du temps et de l’argent à faire des tests avec des valeurs qui ne correspondent à rien. Si vous avez des règles , vous aurez des bêtises , elles sont inextricablement liées . Tout avantage d’une règle doit valoir la sottise qu’il coûte, et cette relation doit être vérifiée à intervalles réguliers.

D'un autre côté, "ça marche" n'est pas une vertu avant l'examen ou la défense en examen. Si le développement suivait le modèle en cascade , vous souhaiteriez effectuer la révision lorsque le codage est terminé à 85%, avant que des erreurs compliquées ne soient détectées et résolues, car la révision est un moyen moins coûteux de les trouver. Puisque la vraie vie n’est pas le modèle de la cascade, il est en quelque sorte un art de réviser qui constitue une norme sociale. Les personnes qui liront votre code et y chercheront des problèmes sont en or massif. La direction qui soutient cela de manière continue est une perle au-dessus du prix. Les critiques doivent ressembler à des checkins - tôt et souvent .

J'ai trouvé ces choses bénéfiques:

1) Pas de guerres de style . Les accolades ouvertes ne doivent être soumises qu’à un contrôle de cohérence dans un fichier donné. Tous les mêmes. C'est bien alors. Ditto profondeur de pénétration ** s et largeur de l' onglet ** . La plupart des entreprises découvrent qu'elles ont besoin d'un standard commun pour les onglets, qui est utilisé comme un grand espace.

2) `Ragged

   looking

texte qui ne

   line up is hard to read 

pour le contenu.

BTW, K & R ont mis en retrait cinq (CINQ) espaces, de sorte que les appels à l'autorité ne valent rien. Juste être cohérent.

3) Une copie numérotée, non modifiable et accessible au public du dossier à examiner doit être indiquée au moins 72 heures avant l’examen.

4) Pas de design à la volée. En cas de problème, notez son emplacement et continuez.

5) Des tests qui suivent tous les chemins dans l'environnement de développement sont une très, très, très bonne idée. Les tests nécessitant des données externes massives, des ressources matérielles, l'utilisation du site du client, etc., etc.

6) Un format de fichier non ASCII est acceptable si des outils de création, affichage, édition, etc. existent ou ont été créés au début du développement. C’est un de mes préjugés personnels, mais dans un monde où le système d’exploitation dominant ne peut s’échapper avec moins d’un gigaoctet de RAM, je ne comprends pas pourquoi des fichiers inférieurs à, par exemple, 10 mégaoctets devraient faire l’objet de rien. autre que ASCII ou un autre format pris en charge par le commerce. Il existe des normes pour les graphiques, le son, les films, les exécutables et les outils qui vont avec. Il n'y a aucune excuse pour un fichier contenant une représentation binaire d'un certain nombre d'objets.

Pour la maintenance, la refactorisation ou le développement de code publié, un groupe de collègues de travail que j'avais utilisé était examiné par une autre personne, assise devant un écran et regardant un diff, ancien ou nouveau , comme passerelle vers l'enregistrement dans une succursale. Je l’ai aimé, c’était bon marché, rapide, relativement facile à faire. Les visites guidées destinées aux personnes qui n'ont pas lu le code à l'avance peuvent être instructives pour tous, mais améliorent rarement le code du développeur.

Si vous êtes géographiquement distribué, il serait relativement facile de regarder les diffs sur un écran tout en discutant avec quelqu'un d'autre. Cela couvre deux personnes à la recherche de changements. Pour un groupe plus important qui a lu le code en question, plusieurs sites ne sont pas plus difficiles que tous dans la même pièce. Plusieurs salles reliées par des écrans d'ordinateur partagés et des boîtes à squak fonctionnent très bien, à mon humble avis. Plus il y a de sites, plus la gestion des réunions est nécessaire. Un responsable en tant qu'animateur peut gagner sa vie ici. N'oubliez pas de continuer à interroger les sites sur lesquels vous n'êtes pas.

À un moment donné, la même organisation avait automatisé des tests unitaires, qui étaient utilisés comme tests de régression. C'était vraiment sympa. Bien sûr, nous avons ensuite changé de plate-forme et les tests automatisés ont été laissés pour compte. La révision est meilleure, comme le note le Manifeste Agile , les relations sont plus importantes que les processus ou les outils . Mais une fois que vous avez passé en revue, les tests unitaires automatisés / tests de régression sont la prochaine aide la plus importante dans la création d'un bon logiciel.

Si vous pouvez baser les tests sur les exigences , eh bien, comme le dit la dame dans "When Harry Met Sally" , j'aurai ce qu'elle a!

Toutes les revues doivent avoir un parking pour capturer les exigences et les problèmes de conception au niveau supérieur au codage. Une fois que quelque chose est reconnu comme appartenant au parking, la discussion devrait s'arrêter lors de l'examen.

Parfois, je pense que la révision de code devrait ressembler à la révision schématique de la conception matérielle: complètement publique, complète, tutoriel, fin d'un processus, passerelle après laquelle il est construit et testé. Mais les critiques schématiques sont lourdes, car le changement d'objets physiques coûte cher. Les revues d'architecture, d'interface et de documentation de logiciels devraient probablement être lourdes. Le code est plus fluide. La révision du code devrait être plus légère.

À bien des égards, je pense que la technologie est autant une question de culture et d’attente qu’un outil spécifique. Pensez à toutes les improvisations " Swiss Family Robinson " / Flintstones / McGyver qui ravissent le cœur et stimulent l'esprit. Nous voulons que nos affaires fonctionnent . Il n’ya pas de chemin unique à suivre, pas plus qu’il n’existait une "intelligence" qui pouvait être extraite et automatisée de façon ou d’autre par les programmes d’ IA des années 1960 .

La plupart des points que vous avez décrits ne sont qu’une question de formatage de code ou de "surface":

• Adhérer aux conventions de nommage
• Eviter le code mort
• Document
• ...

Tout cela pourrait être vérifié en utilisant un outil automatisé : il n’est pas nécessaire de faire appel à un développeur expérimenté pour passer au travers du code.

Je ne connais pas du tout .NET , mais pour PHP , nous avons des outils pour vérifier ce genre de choses; Considérant que .NET est souvent considéré comme "plus industriel" que PHP, je serais surpris d'apprendre qu'il n'existe aucun outil pour vérifier ce genre de choses.

L'outil automatisé peut à la fois:

• Être intégré dans un processus de construction automatique , qui s'exécute toutes les nuits
• Envoyer des e-mails en rapportant
  • avertissements (par exemple, une méthode est plus longue que 20 lignes)
  • erreurs (par exemple, une méthode est plus longue que 50 lignes)

Le courrier peut être envoyé à toute l'équipe ou au responsable du code qui n'a pas passé le test. Vous pouvez également utiliser une interface Web de création de rapports (même remarque à propos de .NET et PHP).

J'ajouterais également que les tests automatisés peuvent beaucoup aider à détecter un certain nombre d'erreurs avant que le code ne soit utilisé en production. Et les tests automatisés peuvent également aider avec certaines métriques, je suppose.

Les revues de code effectuées par des développeurs expérimentés présentent également un autre avantage important dont vous n'avez pas parlé:

• Un développeur expérimenté peut souvent détecter une grande variété de bogues simplement en regardant le code source (je trouve souvent des bogues lorsque je fais des critiques de code).
• Une révision du code effectuée par un développeur expérimenté lui permettra de formuler des commentaires et des recommandations à l’équipe :
  • Il essaiera de comprendre les algorithmes utilisés dans le code et suggérera peut-être de meilleures solutions.
  • En lisant le code, il y a souvent des choses que vous pouvez voir qu'un outil automatisé ne détectera pas.

Mais pour une révision de code allant au- delà du simple formatage de code, vous aurez besoin de plus d'une demi-heure ...

D'après mon expérience en matière de révision du code, il devrait s'agir d'un effort combiné d'amélioration du code et non d'une "mesure" permettant de déterminer qui est bon ou mauvais dans son travail. S'il importe peu que vous receviez beaucoup de remarques lors de la révision du code, les réviseurs seront plus stricts et donneront donc des suggestions pour améliorer le code.

Pour améliorer la qualité du code coché dans, assurez-vous que les commentaires de révision sont traités (laissez le réviseur approuver les commentaires traités) et utilisez également des outils de vérification de code statique pour imposer un niveau de qualité à la validation initiale.

Je pense que votre système de notation est une mauvaise idée. Dans quel but? Identifier les bons et les mauvais programmeurs? Tout le monde participant à cette révision de code peut former une évaluation d'un programmeur particulier sur la base du code présenté dans la révision de code, mieux qu'une assignation arbitraire de valeurs à un ensemble quelque peu arbitraire de caractéristiques. Si vous voulez identifier les bons et les mauvais programmeurs ... demandez aux programmeurs. Je garantis que les humains peuvent faire cette évaluation mieux que votre heuristique idiote.

Ma suggestion serait d'essayer d'améliorer les révisions du code afin que les gens puissent partager ouvertement leurs idées et leurs opinions dans un environnement sans jugement ni hostile. Si vous pouviez le faire, vous serez 100 fois mieux que de formuler des jugements sur des programmeurs basés sur vos listes de contrôle stupides qui prétendent faire un bon travail d'évaluation des programmeurs. Je pense que beaucoup de programmeurs sont déjà fiers d’eux-mêmes s’ils réussissent mal dans les revues de code; Je me demande si une «punition» supplémentaire pour une mauvaise performance est généralement utile.

Mon seul conseil serait d' éviter de rendre votre processus de révision de code trop strict - le plus important, c'est que la révision de code ait réellement lieu et qu'elle soit prise au sérieux .

Plus le processus est exténuant pour l'examinateur, moins il est probable que des révisions de code aient lieu et qu'elles soient prises au sérieux, plutôt que considérées simplement comme une gêne. En outre, la véritable valeur des révisions de code réside dans la capacité du relecteur à utiliser son propre jugement. Des outils automatisés peuvent être utilisés pour vérifier des éléments tels que le respect des règles FXCop.

En règle générale, évitez de passer tout votre temps dans une révision de code à effectuer quelque chose qui pourrait être fait à la machine. Par exemple, votre premier élément consiste à "appliquer les règles FxCop", mais cela peut vraisemblablement être réalisé par FxCop sans que les utilisateurs aient à le faire.

Si vous pouvez le mesurer, s'il est objectif, quantifiable, essayez de le faire avec un outil. Si vous avez besoin d’un critique expérimenté, c’est pour le subjectif flou.

Beaucoup de bons commentaires ont déjà été faits sur les questions de style, ce qui est important. Dans un projet d'équipe, il est utile que tout le code ait l'air d'avoir été écrit par un seul auteur. Cela facilite l'accès des autres membres de l'équipe et la résolution des problèmes lorsqu'ils surviennent. Les mesures quantitatives que vous choisissez pour atteindre cet objectif plus large sont moins importantes.

Un élément supplémentaire consiste à faire en sorte que le code corresponde à l'architecture globale convenue pour le reste du système. Des problèmes similaires devraient tous être résolus de la même manière. Si la logique de l'application a été répartie sur plusieurs couches, le code en cours de révision décompose-t-il ses fonctionnalités comme le reste du système? Sinon, le code à l'étude enseigne-t-il quelque chose de nouveau qui devrait être retiré du reste du système? Tout comme les vérifications de style garantissent que le code a tous la même apparence, l'examen d'architecture doit garantir que le code fonctionne de la même manière. Ici encore, l’accent est mis sur la maintenabilité. Tous les membres de l'équipe devraient pouvoir accéder à ce code et avoir une idée de ce qui se passe immédiatement.

L'idée de classement semble être un désastre en devenir, mais vous connaissez mieux votre équipe. Il est possible qu'ils soient motivés par un tel système, mais je pense qu'il est plus probable que les gens commencent à se préoccuper davantage de leur note que de résoudre des problèmes. Les opportunités de mentorat qu'elles offrent constituent l'un des effets secondaires vraiment précieux des révisions de code. Le réviseur doit traiter la personne qui a écrit le code comme une personne qu’il conseille. Chaque problème détecté n’est pas un problème, mais une opportunité de créer un membre d’équipe plus averti et plus sophistiqué et une équipe plus soudée.

En réalité, je me soucie plus du contenu «subjectif» que d’autre chose. Ce que je veux d’une bonne revue de code, c’est de la vérification de ma logique, pas de la frappe. Et c’est ce sur quoi je me concentre lorsque j’examine le code.

Le format général que j'aime prendre est:

1. Que réparons-nous?
2. Quelle en était la cause? (regarde le code)
3. Comment on le répare?
4. Montre moi le nouveau code
5. Montre moi le code qui fonctionne

Sans cela, le simple fait de regarder les différences tend à donner des informations sur des problèmes mineurs ou des points stylistiques. Je suis beaucoup plus préoccupé par le fait de savoir si la logique est correcte, si l'approche utilisée est bonne dans l'ensemble et si la solution sera maintenable.

À titre d’exemple, j’ai récemment examiné du code rédigé par un collègue. Le problème initial était une violation de FxCop. Mais ce qui était en train de faire, c’était essayer de déterminer la présence ou non d’une fonctionnalité Windows en vérifiant le numéro de version. Mon principal commentaire était que c'était une façon fragile de le faire et qu'il valait mieux interroger directement le service, car le mappage entre l'existence des fonctionnalités et Windows sku pourrait changer à l'avenir et n'était pas du tout à l'abri de l'avenir.

La complexité cyclomatique (CC) est un moyen d'évaluer un code "pas mal".

Dans le code qui a un CC élevé, j'ai un facteur élevé: "Ce qui se passe ici, je ne me souviens pas". Le code CC inférieur est plus facile à comprendre.

Évidemment, les mises en garde habituelles s'appliquent aux métriques.

Les revues de code sont à la fois subjectives et objectives. Des règles telles que "le corps de la méthode doit comporter 20-30 lignes" sont subjectives (certaines personnes pourraient penser que 100 lignes est acceptable), mais si votre société a décidé que 20-30 lignes est la limite, c'est très bien et vous pouvez le mesurer. Je pense que le système de points que vous avez créé est une excellente idée. Vous devrez le réévaluer périodiquement car vous constaterez que certaines règles doivent avoir plus ou moins de poids dans la notation, mais tant que tout le monde connaît les règles, cela ressemble à un bon système.

Autres choses que je rechercherais:

• clarté du code - parfois, un morceau de code peut être écrit sur une ou plusieurs lignes. Le programmeur moyen ne devrait pas avoir à passer plusieurs minutes à essayer de comprendre ce que fait une ligne de code. S'il le fait, le code devrait peut-être être récrit de manière plus simple. Ceci est subjectif mais l’essentiel est que le code soit immédiatement compréhensible par la plupart des programmeurs de votre entreprise.
• vérifier les paramètres d'entrée de la fonction - il devrait y avoir un code pour vérifier que les paramètres d'entrée se situent dans des plages acceptables. Cela devrait également correspondre à la documentation de la fonction.
• noms de variables descriptives - sauf dans quelques cas particuliers (index de boucles, etc.), les noms de variables doivent être descriptifs. Une ressource que vous pouvez consulter pour connaître les conventions de dénomination, etc. est Code Complete.

Il semble que vous deveniez trop détaillé trop rapidement. Vous devriez le décomposer plus. Vous devez observer le code pour sa qualité et pour la conformité de ses fonctionnalités. Vous devriez avoir les deux séparés et ce n'est même pas la fin de l'histoire ... alors voici ma suggestion:

Qualité du code:

• Contrôles automatisés:
  • Conformation du style: la convention de nommage est-elle correcte, le code est-il correctement mis en retrait, etc.
  • Norme d'efficacité: contrôle des fuites de mémoire, contrôle de la complexité, variables redondantes, etc.
• Examen par les pairs:
  • Une simple promenade à travers le design
  • explication des écarts par rapport aux contrôles automatisés
  • Facilité d’entretien, expliquez comment vous pouvez l’entretenir et tout le reste.
  • Testabilité: est-il facile de tester ce code? Vous avez un plan?

Conformité des fonctionnalités:

1. Un examen des exigences relatives aux fonctionnalités et des modifications apportées depuis les exigences et / ou la révision de la conception
2. Démonstration de la fonctionnalité associée aux exigences et vérification une par une
3. Discutez de toute exigence supplémentaire concernant les autres aspects du logiciel rencontrés lors de la mise en œuvre (tels que les plans de déploiement, l'infrastructure, etc.).
4. Explication de tout écart par rapport aux exigences, le cas échéant.

Si vous pouvez vous couvrir sur ces deux aspects d'une révision de code, vous êtes en or.

Je pourrais écrire quelques paragraphes, mais je ne ferais que dissimuler ce que Karl Wiegers explique dans "Commentaires par les pairs dans le logiciel: un guide pratique" . Je pense que son livre contient des réponses explicites et concises à votre question (et bien plus encore).

Ça dépend.

Certaines parties de l'examen sont facilement quantifiables (pas de problèmes FxCop, pas d' erreurs StyleCop , pas d' erreurs CAT.NET , etc.).

Le style, cependant, peut être subjectif - mais comme vous le dites, une fois que vous commencez à être plus spécifique (pas de méthode> 20 lignes), vous pouvez le mesurer, et des outils comme NDepend peuvent le faire automatiquement. Cependant, certaines choses ne seront jamais automatiques - la gestion des cas sur le bord nécessiterait des tests, ce qui entraîne une couverture du code, et 100% est un idéal inaccessible dans de nombreux cas. La vérification des doublons est difficile à faire automatiquement. Null vérifie, bien pas sûr que je suis d'accord avec vous, mais vous pourrez peut-être écrire des règles NDepend, ou des règles FxCop pour celle-là.

Plus il y a d'outils, mieux c'est, et si les outils permettent aux développeurs de vérifier leur travail avant de valider les modifications et que des vérifications soient effectuées dans le cadre du processus d' EC , vous minimiserez le besoin de révisions.

Un système de marquage semble difficile à mettre en œuvre, mais il est utile d’avoir un outil de mesure: vous ne pouvez pas améliorer ce que vous ne pouvez pas mesurer. Mais vous devriez probablement accepter que certaines choses seront difficiles / impossibles à quantifier avec précision. La difficulté consiste à déterminer le nombre de points que chaque qualité doit attribuer: par exemple, si le respect des conventions de dénomination attribue un score de 2 points, combien de points pour une méthode réduite?

Peut-être que quelque chose comme une simple liste de contrôle serait mieux, afin que le code puisse être marqué comme étant conforme, partiellement conforme ou non conforme à une qualité particulière. Plus tard, vous pourrez ajouter des scores à la liste de contrôle une fois que vous aurez identifié les problèmes de qualité les plus fréquents ou provoquant le plus de problèmes.

Le processus de révision doit également être suffisamment souple pour permettre au code d’échouer à certaines parties de la révision, à condition que cela puisse être justifié et documenté. Respecter aveuglément certaines normes de qualité du code, ce qui rend un composant inutilement complexe / ingérable est une mauvaise idée!

Si vous voulez que le code des gens soit plus standardisé, sans leur faire perdre du temps sur le formatage, comme certains développeurs s'en plaindront. Investissez dans un outil tel que ReSharper, car il rend le processus presque automatisé de correction du formatage et d'autres tâches de re-factorisation.

• Si une machine peut vérifier, les gens ne devraient pas.
• Un seul élément de la liste de contrôle: chaque cas d'erreur est-il traité correctement partout?
• Utilisez les revues de code pour améliorer la qualité et transférer les connaissances.
• N'utilisez pas les critiques de code pour identifier les "mauvais" développeurs.
• Les coups d'égo sont plus efficaces que les points explicites.
• Soyez bref - 90 minutes et 500 lignes, c'est ÉNORME.