Vous êtes prêt pour une révision de code en tant que développeur?

Je cherche quelques idées ici.

Je lis l'article Comment être pratiquée doivent revues de code et code avis, quels sont les avantages? qui étaient très instructifs mais j'ai encore besoin de plus de clarté sur la question ci-dessous.

Ma question est,

1. En tant que développeur cible, pouvez-vous suggérer quelques bonnes pratiques qu'un développeur peut intégrer avant que son code ne soit examiné.

   • Actuellement, je pratique les méthodes suivantes

     • PPT pour un flux logique
     • Commentaires détaillés.

Problème: Même si j'ai mis en œuvre les pratiques ci-dessus, elles n'aident pas à l'examen. Le problème auquel j'ai été confronté est que lorsque certaines logiques sont renvoyées, je continue de rechercher la mise en œuvre et le flux et trop de temps est gaspillé dans le processus et je suis nerveux.

Je pense que beaucoup de développeurs vivraient aussi ce que je vis.

Donc, sur la base des détails fournis par OP, il semble que la question soit: "comment puis-je apprendre mon propre code afin que lorsqu'on lui demande de trouver X ou d'expliquer Y, je puisse répondre rapidement."

Quelques suggestions auxquelles je peux penser:

• Lors du codage, vous devez prendre le temps d'apprendre et de comprendre votre propre code. C'est peut-être ce que votre TL essaie de vous faire comprendre en moins de mots. Étant un TL sur le projet en cours, j'ai fait beaucoup de révisions de code au cours des 11 derniers mois et je remarque une pratique de certains développeurs de rechercher un "exemple de code" soit dans notre propre base de code, soit ailleurs (google , etc ...) et le copier / coller dedans. Personnellement, je ne peux pas le supporter parce que même si leur code passe les tests unitaires simples, ils ne comprennent pas ce qu'il fait réellement, donc nous ne sommes jamais garantis qu'il n'y a pas ' t un cas limite ou une condition de défaillance attendue qui pourrait se produire.

• En corollaire de la déclaration précédente, si vous devez copier / coller, essayez de copier / coller uniquement le code que vous avez écrit précédemment et que vous comprenez. Il est certainement correct d'emprunter l'idée des autres, mais dans ce cas, réécrivez leur code ligne par ligne car au fur et à mesure que vous l'écrivez, vous comprendrez mieux ce qu'il fait. Si vous utilisez des API externes, même si vous avez un exemple qui utilise cette API, prenez quand même quelques minutes pour trouver une référence et apprendre comment cette API fonctionne. Ne vous contentez pas de supposer que si cela a fonctionné auparavant, cela fonctionnera également dans votre situation.

• Lisez et apprenez à aimer le principe SEC . Souvent, ce que vous êtes tenté de copier / coller peut être placé dans un emplacement commun (fonction séparée, classe séparée, bibliothèque séparée ...)

• Lisez et apprenez à aimer les principes SOLIDES et pendant que vous y êtes, passez en revue KISS qui a déjà été mentionné par mouviciel. Ces principes visent tous à produire un code très concis, propre et modulaire. Si vous avez de grandes classes et de grandes fonctions au sein de celles-ci, il sera clairement beaucoup plus difficile de trouver des choses et, en plus, essayez d'expliquer ce que fait le code. D'un autre côté, si vous suivez (ou du moins essayez de suivre) SRP et rendez chaque classe / fonction responsable d'une seule chose, votre code sera petit et très lisible.

• Procurez-vous une copie de Clean Code . Très bon livre. Il s'agit d'écrire du code explicite et facile à lire, à entretenir et à étendre. Si vous vous entraînez à écrire du code facile à lire, vous ne devriez pas avoir de problèmes pour lire votre propre code dans les revues de code. Et c'est la partie amusante, j'ai demandé aux gens de lire leur propre code ou simplement de me dire ce que les variables représentaient et ils n'ont pas pu répondre même s'ils ont écrit ce code (classes toutes nouvelles, pas héritées) il y a seulement une semaine . Une bonne dénomination va un long chemin.

• Si après toute la simplification et la refactorisation, vous avez toujours une fonction qui doit exécuter une sorte d'algorithme qui n'est pas très apparent, prenez le temps et écrivez un bloc de commentaires dans cette fonction expliquant l'algorithme. Non seulement cela sera utile lorsque vous devrez modifier cette fonction dans 2 mois, mais si vous êtes pris en embuscade dans une révision de code, vous pourrez simplement relire ce que vous avez écrit.

• Si après tous les éléments ci-dessus, vous trouvez-vous toujours des ennuis? êtes-vous nouveau dans l'équipe et invité à travailler avec beaucoup de code hérité? Dans ce cas, il se pourrait que votre TL soit un A $$ et vous pourriez être proactif en lui demandant avant la réunion de se détendre et de ne pas perdre le temps de toutes les personnes impliquées. Lorsque de nouvelles personnes rejoignent une équipe, TL doit avoir assez de patience car travailler dans une nouvelle plate-forme, un nouveau produit, de nouvelles personnes, un nouvel environnement prend beaucoup de concentration à une nouvelle personne, et cette personne manquera de détails au début. Fonctionne comme conçu et votre TL devrait simplement l'accepter.

• Si après tous les éléments ci-dessus, vous sentez toujours que vous avez d'horribles critiques de code. Parlez à votre TL. Parfois, les gens se sentent mal à cause de la nature des réunions de révision du code alors qu'en fait TL est parfaitement satisfait de vous. Lorsque je fais des revues de code, mon objectif est de mettre en évidence ce qui doit être changé, de m'assurer de bien comprendre les changements et de continuer. Souvent, je n'ai pas le temps d'être poli et certaines personnes sont sur la défensive et tentent de répondre à chacun de mes commentaires. Dans ces situations, la réunion de révision du code s'arrête donc j'ai tendance à les interrompre et à continuer. Généralement, après la réunion, je parlais aux nouveaux gars pour m'assurer qu'ils comprenaient le processus et que ce n'était rien de personnel. Après quelques révisions de code, les gens sont généralement beaucoup plus à l'aise.

Les pratiques varient, mais d'après mon expérience:

• Ne faites rien de spécial au code. Il est naturel de relooker un peu plus votre code lorsque vous apprenez qu'il va être révisé, et il n'y a aucun mal à corriger des choses évidentes comme des fautes d'orthographe et autres. Mais n'entrez pas et n'ajoutez pas beaucoup de commentaires détaillés ou changez le code simplement parce qu'il est prévu de le réviser.

• Le code est préparé et distribué aux examinateurs bien avant l'examen. Cela est généralement effectué par un tiers neutre, probablement le facilitateur de révision du code. S'il est imprimé, le code doit être suffisamment petit pour que les lignes ne soient pas trop souvent enroulées, mais suffisamment grand pour que tout le monde puisse le lire facilement. Imprimez-le au format paysage si c'est ce qu'il faut.

• Le code doit être imprimé ou affiché avec des numéros de ligne . De préférence, le numéro doit continuer d'un fichier à l'autre. Il est beaucoup plus facile de se référer à la "ligne 3502" qu'à la "ligne 238 de foo.c", et avoir les numéros permet à tout le monde de parler de lignes spécifiques sans perdre de temps à trouver ces lignes.

• Il devrait certainement y avoir un facilitateur , au fait. Son travail consiste à empêcher l'examen de s'enliser dans les moindres détails, à l'empêcher de devenir personnel ou chauffé et à limiter strictement la durée de l'examen.

• En tant qu'auteur, vous devez réviser le code vous-même avant la réunion de révision. Notez les modifications que vous suggéreriez s'il s'agissait du code de quelqu'un d'autre. Cela vous rafraîchit la mémoire du code que vous n'avez peut-être pas consulté en quelques jours et vous aide également à vous entraîner à regarder votre propre code avec un œil critique. Après avoir passé en revue quelques critiques, à la fois en tant que critique et en tant qu'auteur, vous constaterez que vos propres notes correspondront mieux à celles du reste du groupe.

• Soyez prêt à prendre des notes pendant l'examen. Cela ne devrait pas être votre principale préoccupation - quelqu'un d'autre devrait enregistrer les éléments d'action sur lesquels le groupe est d'accord afin que vous puissiez vous concentrer sur l'explication du code et écouter les commentaires. Mais il y aura des moments où vous obtiendrez des commentaires précieux qui ne sont pas un élément d'action, et vous devriez corriger ces choses lorsqu'elles se produisent.

• N'oubliez pas que ce n'est pas personnel. Il est difficile d'éviter de se sentir (et d'agir) défensif lors d'un examen. C'est bien d'expliquer votre code si vous pensez qu'il a été mal compris, mais surtout essayez d'écouter.

Une dernière chose à ajouter aux autres réponses: pour faciliter les réviseurs de code formels , effectuez BEAUCOUP de révisions de code informelles ! Par exemple:

"Hey Bob, je peux te montrer comment j'ai implémenté la fonction foo ()?" "Hey Steve, peux-tu jeter un œil à ce diagramme de classe et me dire ce que tu en penses?" "Hey Karen, pouvez-vous m'aider à réfléchir à ce problème? Je pense que j'ai une bonne solution, mais je pourrais utiliser votre aide ..."

Faites-en une habitude régulière. Lorsque vous impliquez vos collègues au début du processus de conception, vous:

• Établir des relations
• Obtenez de nouvelles informations sur le problème
• Améliorez votre capacité à expliquer le problème / la solution à portée de main
• Gagnez du temps plus tard dans les révisions de code formelles