On m'a confié le rôle d'améliorer le développement de notre entreprise. La première chose que je voulais commencer était les revues de code car cela n'avait jamais été fait ici auparavant.

Il y a 3 programmeurs dans notre entreprise. Je suis programmeur web, mes langages connus sont principalement PHP, ActionScript et JavaScript. Les 2 autres développeurs écrivent des applications internes dans VB.net

Nous faisons des revues de code depuis quelques semaines maintenant. J'ai du mal à comprendre le code VB. Donc, quand ils disent ce que ça fait, pour la plupart, je dois juste croire sur parole.

Si je vois quelque chose qui ne va pas, j'explique mon opinion et j'explique comment je la traiterais dans une des langues que je connais.

Parfois mes suggestions sont les bienvenues mais souvent on me dit des choses comme "c'est la meilleure façon de le faire dans cette langue" ou "qui ne s'applique pas à cette langue" ou des choses similaires de cette nature.

Cela peut être vrai, mais sans connaître la langue, je ne sais pas comment confirmer ou réfuter ces affirmations.

Je sais qu'une solution possible serait d'apprendre vb afin que je puisse faire de meilleures révisions de code. Je n'ai vraiment aucun intérêt à apprendre le vb (d'autant plus que j'ai une liste d'autres technologies que j'essaie d'apprendre pour mes propres projets) et je voudrais garder cela en dernier recours mais c'est une option.

Une autre idée qui m'est venue est qu'ils ont tous les deux un intérêt pour C # et moi aussi. C'est par rapport à eux parce que c'est .net et par rapport à moi parce que c'est plus similaire aux langages que je connais. Pourtant, c'est nouveau pour nous tous. J'ai pensé aux avantages de notre collaboration à un projet C # .net pour animaux de compagnie et de l'examen du code de chacun.

Je suppose qu'il y a aussi la possibilité d'embaucher un consultant pour venir nous donner quelques revues de code.

Que recommanderiez-vous que je fasse dans cette situation.

Vos désirs personnels d'apprendre d'autres choses devraient prendre du recul pour apprendre ce dont vous avez besoin en ce moment pour votre travail. Apprenez VB.net. Vous pouvez efficacement coder le code de révision que vous ne comprenez pas lorsque vous connaissez la langue dans laquelle il se trouve en posant beaucoup de questions (généralement c'est un signe que le code n'est pas bien écrit si vous connaissez la langue et ne pouvez pas comprendre ce qu'il fait et Pourquoi). Mais ne comprenant pas le code, le mieux que vous puissiez faire est de les faire vous expliquer et espérons qu'ils verront des bogues tout au long du processus de l'explication. Ce n'est pas que je n'ai pas trouvé de bogues dans mon propre code lors d'une révision en faisant exactement cela, mais ce n'est pas le moyen le plus efficace de coder la révision. La révision du code fait maintenant partie de votre travail, traitez-le et apprenez ce que vous devez apprendre pour le faire efficacement.

Pendant que vous apprenez, quand ils disent bien que ce n'est pas la façon dont nous le faisons dans cette langue, faites-leur montrer une source qui dit que c'est une bonne technique à utiliser. C'est à eux de vous justifier dans une revue de code et non l'inverse. Vous améliorerez également la langue une fois que vous commencerez à voir ces liens.

En fait, je suis en désaccord avec tout ce qui précède. Avec JS / PHP / ActiopnScript, vous avez une compréhension fondamentale de ce qu'un langage de programmation a et comment il fonctionne. En fait, je dirais qu'il y a beaucoup de similitudes entre VB et JS. Cependant, ce n'est pas mon point. Même si vous êtes très compétent avec la langue, il est facile d'oublier quelque chose lorsque vous essayez de suivre les processus de réflexion de quelqu'un d'autre, donc ce que l'examen devrait faire, c'est donner au programmeur l'occasion d'expliquer ce qu'il a fait et pourquoi.

Un ami a décrit cela comme "The Janitor Theory": en expliquant les détails à quelqu'un, n'importe qui, même le concierge, le programmeur expose à lui-même toute faiblesse du code, ce qui est, bien sûr, le but ultime de l'examen processus. Cela nécessite cependant que le code soit expliqué de manière approfondie et ouverte (les critiques ne fonctionnent pas lorsque les développeurs sont défensifs).

La version courte

1. N'oubliez pas que les révisions de code sont une chance pour le réviseur et le réviseur d'apprendre.
2. Expression de commentaires en tant que question.
3. Ne laissez pas le manque de connaissances vous empêcher de fournir des commentaires (tant que vous faites # 2).
4. Évitez les "avis sur les préférences" ou essayez au moins de faire clairement comprendre qu'il s'agit de vos propres préférences personnelles et qu'elles n'ont pas nécessairement besoin d'être d'accord.
5. Essayez de soumettre des correctifs au lieu d'être un «réviseur de code fauteuil».

La version plus longue

Tout d'abord, rappelez-vous que la révision du code n'est pas seulement une occasion pour le candidat d'apprendre. C'est aussi l'occasion pour le réviseur d'apprendre également. En fait, j'ai entendu parler de plusieurs organisations qui obligent les nouveaux programmeurs à commencer à réviser le code afin qu'ils puissent se faire une idée du code.

Dans cet esprit, il y a un conseil de révision de code que j'ai toujours trouvé utile en général, mais qui est particulièrement pertinent dans votre position. Formulez vos commentaires sous forme de question plutôt que sous forme de déclaration. En d'autres termes, au lieu de dire "Ce code craint!", Vous pourriez dire "Pourquoi avez-vous écrit le code de cette façon au lieu de le faire ..." Cela rend le processus de révision du code plus agréable et vous permet également d'apprendre.

Un autre conseil que j'ai pour vous est de ne pas laisser votre manque de connaissances vous faire reculer. Si vous voyez quelque chose que vous percevez comme incorrect, et que vous obtenez une réponse ondulée de la part de la personne évaluée, ne reculez pas (du moins pas en raison d'un manque de connaissances). N'oubliez pas que ce qui fait du bon code dans une langue est rarement différent de ce qui fait du bon code dans une autre langue. Oui, certaines langues ont des idiomes différents pour vous aider à écrire du bon code. Mais il est important de réaliser que ces idiomes sont des outils plutôt que des fins en soi.

Ensuite, évitez de faire des "révisions des préférences". C'est quelque chose que je (et beaucoup d'autres) dois faire un effort très conscient. En d'autres termes, essayez d'éviter de faire des critiques qui vont dans le sens de "Vous avez fait x , mais je préfère y ". Maintenant, il n'y a rien de mal à énoncer des préférences, mais vous devez clairement les étiqueter comme telles et noter que l'autre partie est libre de ne pas être d'accord. C'est important, car la plupart des choses qui diffèrent d'une langue à l'autre entrent dans cette catégorie.

Enfin, utilisez-vous un système de contrôle de version distribué? Une chose qui pourrait être utile est que, plutôt que de simplement noter ce qui ne va pas avec le code, vous pouvez réécrire le code comme vous l'auriez écrit, le tester, puis soumettre un correctif pour cela. Cela permet de montrer que vous êtes vraiment intéressé à améliorer leur code et pas seulement à être un "réviseur de code en fauteuil" et vous donne une chance d'apprendre la langue mieux. De plus, il est généralement plus facile d'être en désaccord avec «Je pense que vous devriez faire ça» que «Voici comment je l'aurais fait, et voici un patch si vous êtes d'accord». Je suppose que vous n'avez pas nécessairement besoin d' un DVCS pour cela, mais cela aide certainement.

Vous avez perdu le focus sur le problème et avez trouvé une mauvaise solution. Vous avez été chargé d'améliorer le développement et votre solution est de confier à une personne chargée de la révision du code (vous-même) qui ne comprend pas la langue. Qui examine votre code? Pourquoi ne peuvent-ils pas se revoir jusqu'à ce que vous appreniez la langue?

Il doit y avoir un autre problème qui aurait pu être choisi pour une amélioration plus immédiate. De cette façon, ils vous envoient de la fumée et rien ne s'améliore.

Diriger un nouveau développement vers un langage qu'aucun de vous ne comprend (C #) va prendre beaucoup de temps à porter ses fruits, surtout si vous apportez avec vous leurs mauvaises habitudes.

Concentrez-vous sur le design (cela a été mentionné). S'ils éprouvent des difficultés à maintenir le code actuel, examinez certains outils de refactorisation pour VB. Beaucoup de pratiques de base sont les mêmes.

Vous pouvez «relire» des choses que vous ne connaissez pas vraiment, mais vous ne pouvez pas les examiner correctement . Je suis très compétent en C, je connais assez bien le C ++, mais je ne rêverais pas de revoir quelque chose en C #.

Je ne pense pas que vous ayez besoin d'aller jusqu'à faire appel à un consultant, car certaines entreprises se spécialisent dans l'exécution de votre code à travers une tonne de tests et vous disent ce qui pourrait ne pas y aller.

Pourtant, ce serait au développeur individuel qui connaît la langue d'interpréter le résultat. Par exemple, si un réviseur de code me faisait peur de ne pas utiliser la valeur de retour de printf(), je les regarderais étrangement et questionnerais leur sobriété, puis demanderais "Ok, super, que puis-je faire quand rien ne peut être imprimé sur la console qui soit utile?"

Ce que vous voudrez peut-être envisager, c'est de parler à vos patrons de la création de départements et de chefs d'équipe, afin que vous puissiez être efficace dans votre domaine, tandis que quelqu'un d'autre est efficace dans leur domaine.

Pourtant, je pense que vous pourriez être en mesure d'utiliser un tiers pour l'audit. La plupart des programmeurs dignes de ce nom prêteront attention aux préoccupations légitimes , même s'ils rejettent la moitié comme faux (comme je le ferais dans mon printf()exemple).

Fournir des conseils sur quelque chose que vous ne comprenez pas s'apparente à l'aveugle conduisant l'aveugle comme vous le savez bien.

Une approche consisterait à utiliser des outils lint tels que FxCop et StyleCop qui aborderont le front d'analyse statique de la base de code. Cela vous fournirait un point de départ pour débattre des rapports générés à partir des outils.

Une autre approche consisterait à transformer les revues de code en revues de conception. Les revues de conception ne révèlent plus souvent des problèmes bien avant que le code ne soit même écrit. Si un programmeur a une conception sur laquelle il peut travailler, il est en général beaucoup plus efficace dans son approche et les bogues diminuent à cause de cela. Quand une conception est inexistante, elle devient adhoc dans l'approche et le code souffre avec l'augmentation du nombre de bogues. Détectez les problèmes dans la revue de conception avant qu'ils n'apparaissent dans la revue de code en vous assurant que chacun de vous a une conception concrète à mettre en œuvre; UML est votre ami ici et des outils tels que umlet sont rapides et rapides à utiliser.

La mauvaise nouvelle est que pour participer efficacement aux revues de code, vous devrez apprendre le VB. Il sera également utile d'utiliser VB dans une sorte de projet (pas nécessairement pour la production).

La bonne nouvelle est qu'une fois que vous avez fait cela, une partie de ce que vous avez appris sera toujours utile lorsque vous passerez au C #.

L'idée que vous devez garder en tout temps lors de l'examen par les pairs est la suivante:

"JE SUIS LE PROCHAIN ​​POUR MAINTENIR CE CODE!"

Vous devez le comprendre assez bien pour pouvoir le faire dans le cadre de votre préparation à l'examen, et votre travail consiste à informer le programmeur d'origine de toute lacune qui le rendait plus lourd que nécessaire pour bien comprendre le code pour le maintenir. .

Si vous ne pouvez pas programmer en VB, vous ne pouvez pas conserver le code et vous n'êtes pas qualifié pour être le pair examinateur.

Vous ne devriez pas revoir le code que vous ne comprenez pas, cela ne fera qu'énerver les développeurs qui doivent expliquer chaque chose étrange qu'ils ont faite.

Ce que vous pouvez faire choisissez / définissez des directives de codage et comparez le code avec ces directives. Lorsque quelque chose n'est pas conforme aux directives, vous pouvez demander des explications au développeur.

Je commencerais par choisir les directives existantes (je ne connais pas de normes de codage VB.net mais google m'a donné:

• Consignes de codage VB .Net
• Principal sous
• Cadre de code tout en un

Utilisez des outils de style stylecop pour VB .net

Analyser les sources avec NDepend (il a des règles sur la complexité cyclomatique, les longueurs, les profondeurs, etc.)

Lorsque vous avez fait cela, vous pouvez dire que le code est conforme aux normes choisies, cela ne dit rien sur la fonctionnalité correcte ou le code utilisant les principes de POO appropriés. Mais au moins c'est quelque chose.

Un bon examen du code porte sur des choses qui nécessitent de comprendre le langage - utilisation appropriée du langage, API et bibliothèques, style, noms de variables, etc. - et sur la façon dont le code résout le problème - bons commentaires, architecture appropriée, conception pertinente modèles, prend en compte tous les cas d'erreur, etc. Lorsque vous commencez à faire des revues de code, vous avez tendance à vous concentrer sur le premier. Ils sont plus faciles à voir et à choisir. (Par exemple, je n'aime pas vos noms de variables. Vous devez utiliser des noms de style XXXX.)

La révision du code devient plus utile lorsque l'accent est mis sur la façon dont le code résout les problèmes. Puisque vous ne pouvez pas fournir autant de valeur dans le premier domaine maintenant, concentrez-vous sur des questions et des conseils sur la solution au problème, pas sur la façon dont il est fait.

Bien sûr, il y a chevauchement entre les deux. Connaître VB.NET vous permettrait de fournir des conseils sur les raisons pour lesquelles un certain modèle de conception n'est pas un bon choix dans une situation particulière, par exemple.

Surtout, soyez humble à ce stade. Changer le processus est difficile. Même si vous étiez un gourou de VB.NET, le changement ne serait probablement pas facile. Les gens qui n'ont pas utilisé la révision de code ne l'aiment pas au début. Demander aux autres de regarder votre code est une expérience difficile. Il faut du temps pour voir la valeur et la patience tout autour. C'est un excellent processus lorsque vous obtenez l'adhésion, mais cela prendra du temps.

Pourriez-vous déplacer l'accent pour être davantage sur les tests plutôt que de regarder le code directement? Je ne dis pas abandonner les revues de code, mais au début, il peut être plus judicieux d'obtenir ces applications internes pour avoir suffisamment de tests qui peuvent aider à décoder une partie de ce qui se passe. L'idée ici étant que les tests pourraient également vous aider à vous familiariser un peu avec certaines fonctionnalités. Je vois juste cela comme une voie différente à prendre. L'idée ici étant que les critiques reviennent plus tard et peuvent être faites en quelques parties car il peut être utile d'avoir une vue d'ensemble / une session initiale, puis un peu de pause. Cette pause est jusqu'au lendemain ou au lendemain afin qu'il y ait suffisamment de temps pour quiconque voudra dormir une nuit en pensant au code ou à quelque chose de similaire avant de revenir avec des questions et d'avoir une discussion.

Bien sûr, si vous avez déjà des tests, ce n'est malheureusement pas si significatif. L'autre pensée est de donner un exemple où ils prétendent que dans VB.Net cela se fait d'une manière particulière, car cela peut aider à rendre cette question plus claire d'une manière que je pourrais imaginer que cela varie de peu de normes de code à une partie de le cœur de la façon dont VB.Net a été construit dans un sens.

Même si vous apprenez les bases de VB, effectuer une révision de code sans connaître toutes les fonctionnalités de la langue ne vous permettra pas de détecter l'utilisation de fonctionnalités non sécurisées dans la langue.

Supposons que vous ne saviez pas que la fonction input () de Python 2 a réellement évalué l'entrée avant de la renvoyer, afin de faciliter l'analyse des types d'entrée non chaîne. Ensuite, le code serait vulnérable à l'exécution de code arbitraire, permettant à l'utilisateur d'entrer quelque chose comme __import__('os').execl('/bin/sh', '/bin/sh')sur un système Linux pour transformer le processus Python en shell. À la place, raw_input () doit être utilisé pour obtenir les données d'entrée non traitées.

Tenter d'effectuer une révision de code sans être au courant de toutes les fonctionnalités du langage pourrait non seulement vous empêcher de réaliser une meilleure façon d'effectuer une certaine procédure dans le langage; cela pourrait également conduire à des failles de sécurité préjudiciables.