Comment réviser mon propre code? [fermé]

Je travaille sur un projet en solo et je dois gérer mon propre code. Généralement, la révision du code est effectuée par l'auteur du code, de sorte que le relecteur peut examiner le code d'un œil neuf - mais je n'ai pas un tel luxe. Quelles pratiques puis-je utiliser pour réviser plus efficacement mon propre code?

Tout d’abord, utilisez des outils pour vérifier autant que vous le pouvez. Les tests (sauvegardés avec une couverture de code raisonnable) vous donneront une certitude quant à l'exactitude du code. Les outils d’analyse statique peuvent capturer de nombreuses pratiques optimales. Il y aura toujours des problèmes sur lesquels vous aurez besoin d'un regard humain pour déterminer si et vous ne ferez jamais un aussi bon travail de révision de vos propres dossiers en tant que quelqu'un d'autre, il y a certaines choses que vous pouvez faire pour aider cependant

• les tests de contrôle existent et réussissent (éventuellement, vous avez une couverture de test cible, bien que vous puissiez avoir besoin de la rompre dans certains cas, mais vous devriez être en mesure de justifier pourquoi)
• Vérifiez que l'analyse statique passe (il y aura aussi des faux négatifs ici, mais c'est bien, tant que vous pouvez justifier pourquoi, alors c'est bien de les supprimer)
• maintenir une liste de contrôle des éléments supplémentaires à vérifier lors de l'examen (idéalement, ajoutez-la si possible à de nouvelles règles d'analyse statique), assurez-vous de vérifier tout ce que le SA ne peut pas contrôler, par exemple, les commentaires sont-ils toujours valables, les éléments sont-ils nommés correctement bien sûr, l’un des 2 problèmes difficiles connus en informatique)
• si une anomalie est identifiée, vérifiez si la cause est systémique et déterminez pourquoi elle n'a pas été trouvée lors de tests ou d'études antérieurs.

Ceci est bien sûr utile lorsque vous passez en revue le code d’autres

Jetez un coup d' oeil dans le Code Review Stack site Exchange. C'est pour partager le code des projets sur lesquels vous travaillez pour la revue par les pairs :

Code Review Stack Exchange est un site de questions et réponses permettant de solliciter l'examen de votre code par des pairs. Nous travaillons ensemble pour améliorer les compétences des programmeurs du monde entier en optimisant le code de travail.

Si vous recherchez des commentaires sur un élément de code spécifique de votre projet dans les domaines suivants…

• Meilleures pratiques et utilisation des modèles de conception
• Problèmes de sécurité
• Performance
• Correction dans des cas imprévus

Vous pouvez également utiliser des outils d’analyse statique de code pour détecter certains types de problèmes, mais dans certains cas, ils génèrent de fausses alarmes et ne peuvent pas vous dire comment améliorer la conception.

J'ai développé plusieurs personnes totalement différentes dans ma tête. L'un d'eux n'est même pas un programmeur! Nous discutons, discutons des dernières nouvelles et examinons le code de chacun.

Je recommande fortement mon approche.

ps Il ne plaisante pas.

Je suis d’accord avec l’opinion de JK-S pour dire que l’examen par une seule personne n’est pas aussi efficace que l’examen par deux personnes. Cependant, vous pouvez en tirer le meilleur parti:

examen à court terme (peu de temps après la production du code)

J'utilise git en tant que référentiel local. Chaque fois que j'ai terminé une fonctionnalité ou corrigé un bug, je transfère les modifications dans le référentiel.

Avant de m'enregistrer, je compare ce que j'ai modifié dans mon code et repense:

• Est-ce que les noms de variable / méthode / nom de classe reflètent toujours leur utilisation?

examen à long terme (6 mois après la production du code)

Je me demande:

• puis-je décrire d'un seul coup ce qu'une classe / méthode / variable fait?
• est-il facile d'utiliser une classe en isolation (sans les autres classes) ou d'écrire un unestest?

Commencez par mettre votre code de côté aussi longtemps que possible. Travailler sur quelque chose d'autre, un autre morceau de code. Même après une journée, vous serez étonné de ce que vous trouverez.

Deuxièmement, documentez votre code. Beaucoup de programmeurs n'aiment pas documenter leur code, mais assoyez-vous et écrivez une documentation, expliquez-lui comment utiliser le code et comment il fonctionne. En regardant votre code d'une manière différente, vous trouverez des erreurs.

On a dit que la vraie maîtrise d'un sujet est la capacité de l'enseigner à quelqu'un d'autre. Avec la documentation, vous essayez d'enseigner votre code à quelqu'un d'autre.

Transformez cette technique de débogage en une technique de révision de code: http://en.wikipedia.org/wiki/Rubber_duck_debugging

Le concept fonctionne à merveille pour vous mettre dans un état d'esprit approprié pour travailler avec le code comme s'il était nouveau.

En plus des outils utiles mentionnés dans d’autres réponses, je pense qu’il est utile de modifier votre état d’esprit lors de la révision du code. C'est idiot, mais je me dis: "Je mets mon chapeau de critique de code". Je fais la même chose avec QA.

Ensuite, il est important de vous limiter à cet état d'esprit. Vous êtes soit le critique ou le révisé, vous ne pouvez pas être les deux à la fois. En tant que réviseur, je prends des notes objectives à partager avec le révisé. Je ne modifie pas le code pendant que je l'examine, ce n'est pas quelque chose qu'un relecteur devrait faire.

La formalité semble parfois un peu absurde, mais je trouve que lorsque je travaille en solo, je suis souvent entraîné dans beaucoup de directions. Je ne ferme donc peut-être pas nécessairement la boucle d’examen avant que quelque chose d’autre n’apparaisse - cette formalité (et en réalité, je parle en termes approximatifs dans un outil wiki), est utile pour s’assurer que l’examen est terminé. De même, avec mon chapeau d'assurance qualité, j'ajoute des tickets pour les bugs avant de les corriger.

Il semble que le sentiment commun est que l'auto-examen n'est pas efficace. Je ne suis pas d'accord et je pense qu'une auto-évaluation peut résoudre beaucoup de problèmes si elle est faite à fond.

Voici des conseils tirés de mes quelques années d'expérience:

• Ayez une liste de contrôle approximative à portée de main. Ce sont des choses que vous voulez signaler pendant que vous lisez votre code.
• Prenez votre avis de code hors ligne. Cela peut sembler inutile, mais prenez des impressions que vous pouvez annoter et inverser, ou l’équivalent numérique de fichiers PDF bien mis en valeur synchronisés sur un iPad, qui est ensuite mis hors ligne. Éloignez-vous de votre bureau, de sorte que vous ne fassiez que réviser votre code sans distraction.
• Faites-le tôt le matin plutôt que de terminer votre journée de travail. Une nouvelle paire d'yeux c'est mieux. En fait, il pourrait être utile d’être sorti du code un jour avant de le relire à nouveau.

Juste un FYI - ces directives faisaient partie des recommandations d’Oracle il ya quelques années lorsque je travaillais là-bas, dans le but de détecter les bogues "en amont" avant que le code ne soit mis à l’essai. Cela a beaucoup aidé, même si cela a été considéré comme un travail ennuyeux par beaucoup de développeurs.

La technique du processus logiciel personnel pour les évaluations peut être utile, même si elle repose sur des données historiques concernant votre travail et la qualité des produits.

Vous commencez avec des données historiques sur vos produits de travail, en particulier le nombre et les types de défauts. Il existe différentes méthodes de classification des défauts, telles que celle d'un cours PSP . Vous pouvez développer les vôtres, mais l’idée est que vous devez être capable de dire quelles erreurs vous faites en cours de route.

Une fois que vous savez quelles erreurs vous commettez, vous pouvez développer une liste de contrôle que vous pourrez utiliser lors d'une révision. Cette liste de contrôle couvrira les principales erreurs que vous commettez et qui, à votre avis, peuvent être mieux comprises dans un examen (par opposition à l'utilisation d'un autre outil). Chaque fois que vous passez en revue un produit, utilisez la liste de contrôle pour rechercher ces erreurs ou ces erreurs, documentez-les et corrigez-les. Révisez périodiquement cette liste de contrôle de temps en temps pour vous assurer que vous vous concentrez sur des problèmes réels et pertinents dans votre code.

Je recommanderais également l’utilisation du support d’outils quand cela se comprend. Les outils d'analyse statiques peuvent aider à détecter certains défauts, et certains prennent même en charge la vérification de style pour renforcer la cohérence et un bon style de code. L'utilisation d'un IDE avec la complétion de code et la coloration syntaxique peut également vous aider à prévenir ou à détecter certains problèmes avant de cliquer sur "build". Les tests unitaires peuvent couvrir des problèmes de logique. Et si votre projet est suffisamment volumineux ou complexe, l'intégration continue peut les combiner dans un processus exécuté régulièrement et générer de bons rapports pour vous.

Travailler en solo signifie que, à moins que vous ne fassiez totalement confiance à des inconnus pour réviser le code en votre nom, vous devrez examiner la façon dont vous écrivez votre logiciel afin de maintenir la qualité du code.

D'abord et avant tout, vous devriez avoir un moyen de vous assurer que votre code correspond aux exigences, et ensuite que votre code sera relativement facile à modifier si vous décidez plus tard que vous avez quelque chose de mal. Ma suggestion serait d'appliquer une approche axée sur le développement fondé sur le comportement pour les raisons suivantes:

1. BDD signifie l'écriture de test de code en premier. Cela garantit que tout votre code est couvert par des tests.
2. BDD est essentiellement TDD, mais avec une focalisation et un "langage" légèrement différents. Cela signifie que vous refactorisez en permanence votre code pendant que vous y travaillez et utilisez vos tests pour vous assurer que vos efforts de refactorisation continuent de garantir que votre code respecte les spécifications de votre produit.
3. Le langage BDD encourage les tests à être écrits sous la forme d'instructions qui codent essentiellement les exigences sous forme de tests unitaires.

L’idée ici est que votre refactoring continu du code, même après que vos tests aient réussi, signifie que vous révisez effectivement votre propre code et que vous utilisez vos tests unitaires en tant que "paire d’œil supplémentaire" qui vous assure que votre code ne fonctionne pas. t sortir des exigences qui sont encodées dans les tests. En outre, une couverture de test élevée basée sur les exigences garantit que vous serez en mesure de modifier votre code à l'avenir sans manquer aux exigences.

Le vrai problème pour vous sera de savoir si vous êtes capable de détecter des problèmes potentiels dans votre code qui indiqueront la nécessité de refactoriser. Plusieurs outils de profilage sur le marché peuvent vous aider, ainsi que plusieurs autres outils concernant les métriques de qualité du code. Celles-ci peuvent souvent vous dire beaucoup de choses que les revues de code peuvent manquer, et sont indispensables lorsque vous développez des projets par vous-même. En réalité cependant, l'expérience est la clé, et une fois que vous aurez pris l'habitude d'être impitoyable dans votre refactoring, vous allez probablement devenir beaucoup plus critique à l'égard de votre propre code. Si vous ne l'avez pas déjà fait, je vous conseillerais de lire le livre de Martin Fowler sur le refactoring et de rechercher une bonne API BDD qui, selon vous, fonctionnera pour vous dans la langue avec laquelle vous avez choisi de travailler.

Chaque fois que je me suis trouvé dans la même situation que vous, j'ai essayé de résoudre le problème "d'être trop proche du code pour l'examiner objectivement" en utilisant des outils de révision de code / métriques. Il va sans dire qu'un outil ne peut pas avoir la même valeur qu'un relecteur expérimenté, mais vous pouvez toujours l'utiliser pour identifier les zones de mauvaise conception.

Un outil que j'ai trouvé assez utile à cet égard est SourceMonitor . C'est un peu simpliste, mais cela donne une bonne opinion à mi-niveau de votre code, telle que le nombre de méthodes dans une classe et la complexité de chaque méthode. J'ai toujours pensé que ce type d'informations était aussi important (sinon plus important) que l'application de styles de codage via des outils tels que StyleCop, etc. (qui sont importants, mais ne sont souvent pas la source des plus gros problèmes). Utilisez ces outils avec les clauses de non-responsabilité habituelles: savoir quand enfreindre une règle empirique et quelque chose qui est vert dans un outil de métrique de code n'est pas automatiquement de bonne qualité.

Je ne peux pas vous dire le nombre de fois où j'ai expliqué quelque chose à un réviseur de code et l'ampoule dans ma tête s'est allumée et a dit: "Hé, attendez une minute." Donc, je trouve souvent mes propres erreurs dans la révision du code que l'autre personne n'a pas vues. Pour que vous puissiez essayer, commencez simplement à expliquer le code comme s'il y avait une personne assise à côté de vous qui essayait de comprendre ce que vous faisiez et pourquoi.

Une autre chose que je trouve fréquemment dans les revues de code est que le développeur n'a pas suivi l'exigence. Donc, en comparant votre code et ce qu’il fait, l’exigence réelle est un bon contrôle.

Nous faisons souvent des choses comme des paquets SSIS qui ont des besoins structurels similaires - pour les revues de code, j’ai développé une liste de vérification des choses à vérifier (la configuration est-elle correcte, la configuration de la journalisation, utilise-t-elle la base de métadonnées, les fichiers à l’emplacement standard, etc.). Il se peut que vous ayez des éléments utiles à vérifier chaque fois dans une révision de code. Asseyez-vous et réfléchissez à ce que vous souhaitez mettre dans une liste de contrôle des éléments que vous souhaitez vérifier lors de la révision de votre code (le premier élément doit être conforme à l'exigence, le suivant peut avoir un rapport avec les erreurs de capture et de journalisation). Lorsque vous faites des erreurs et que vous les corrigez, vous pouvez ajouter d’autres éléments à la liste (dites par exemple: est-ce que je passe en boucle au prochain enregistrement ou je vais répéter inlassablement le même premier élément - il suffit d’une boucle sans fin vous apprendre à chercher ça!).

Donnez-lui 3 mois, puis revenez en arrière et regardez votre code. Je vous promets que si vous ne trouvez pas quelque chose qui ne va pas (ou la question qui a écrit cette ordure!), Vous êtes un meilleur homme que moi!

D'habitude, j'imprime tout mon code, je m'assieds dans un environnement silencieux et je le lis, je trouve beaucoup de fautes de frappe, de problèmes, de choses à refactoriser, de nettoyer en faisant cela. C'est un bon auto-contrôle que je pense que tout le monde devrait faire.

À l'université, j'étais un tuteur d'écriture. Cela m'a certainement donné des perspectives de codage auxquelles de nombreux développeurs n'auraient jamais pensé. L'un des plus importants est de lire votre code à voix haute. Cela ne semble pas beaucoup, mais je vais donner un exemple parfait auquel tout le monde peut s'identifier.

Avez-vous déjà écrit un courrier électronique ou un document, relu plusieurs fois pour vous assurer qu'il est correct, puis l'avez envoyé, pour constater que vous avez une faute d'orthographe, une faute de frappe ou une erreur grammaticale flagrante? Je viens de faire cela hier quand j'ai demandé à un client d'appuyer sur la touche merde au lieu de la touche Maj. Lorsque vous lisez dans votre tête, vous voyez ce que vous voulez voir.

C’est un raccourci pour les suggestions que d’autres ont faites: attendez un jour, une semaine ou un mois. Si vous le lisez à haute voix, vous attrapez les mêmes choses. Je ne sais pas pourquoi il est si efficace, mais après avoir passé des centaines d’étudiants et les avoir lus à haute voix, tout ce que je peux dire, c’est que cela fonctionne.

La plupart des gens ont tendance à considérer leur code comme leur propre bébé et à le nourrir d'ego plutôt que de la réalité. Comme toutes les autres critiques de code, relisez-le lorsque vous voyez le code de quelqu'un d'autre. Complètement oublier que vous avez écrit quelque chose. Passez en revue chaque ligne du code. Une liste de contrôle serait utile pour être esthétique sur la révision de son propre code. Des outils automatisés pour la révision du code peuvent aider dans une certaine mesure. J'ai utilisé des outils tels que klocwork (logiciel commercial). C'est très utile lorsque vous travaillez dans de grands projets et que plusieurs développeurs y travaillent. Concentrez-vous toujours sur la détection des défauts plutôt que sur la correction.

Mais la meilleure pratique serait de vous revoir et d’associer plus tard au moins deux autres personnes à des rôles distingués.

Pensez à faire une inspection Fagan par vous-même - vous devrez adapter le processus parce que vous êtes seul, mais vous devriez pouvoir en tirer un bon parti. L'astuce consiste à trouver le "jeu de règles" approprié pour évaluer votre code en tant que développeur solo, puis à avoir la discipline nécessaire pour poser ces questions dans un état d'esprit critique, analytique et sans pitié à chaque fois. Je pense que vous voudrez peut-être commencer par réfléchir à vos propres 4-5 questions cruciales, puis les faire évoluer au fil du temps. Certaines personnes s'opposent aux inspections formelles car elles semblent prendre beaucoup de temps ... Avant de décider qu'elles sont trop chères, gardez à l'esprit toutes les preuves statistiques qu'une inspection correcte permet de réduire le temps de projet. Voici un lien Wikipedia sur lequel vous pouvez commencer des recherches supplémentaires:

http://en.wikipedia.org/wiki/Software_inspection

Quelques ouvrages ont également été publiés, par exemple Google pour "Software Inspection Process" de Strauss et Ebenau.

Une autre option est de payer quelqu'un pour inspecter un projet important - ou peut-être de le payer occasionnellement pour inspecter tout votre code. Ce mec est plutôt bien, nous l'avons volé plusieurs fois pour former nos nouveaux développeurs:

http://www.javaspecialists.eu/

Outre toutes les recommandations relatives à la révision du code, vous pouvez utiliser des outils tels que PMD et findBug pour définir le premier niveau de sécurité de votre code.

Cela n'a pas encore été placé dans une réponse (mais a été ajouté en tant que commentaire à une réponse existante)

Révisez votre code après une bonne nuit de sommeil, par exemple, commencez la journée en examinant le code que vous avez écrit la veille.

Bien entendu, cela ne vous donnera pas l'expérience collective d'une équipe, mais vous permettra de réviser le code sous un nouvel angle.

Par exemple, si vous avez laissé un morceau de code avec un bidouillage méchant, vous pourriez ne pas être trop enclin à le réparer, si vous relisez votre code immédiatement après. Après tout, lorsque vous commencez à réviser votre code, vous savez déjà et avez accepté la présence de ce hack. Mais si vous avez bien dormi, vous êtes probablement plus motivé pour trouver une meilleure solution.

Lorsque nous dormons, le cerveau n'arrête pas de travailler sur les problèmes que nous avons, vous pouvez donc y trouver une solution, bien que ces solutions puissent parfois se présenter de manière étrange .