Je suis un développeur expérimenté, mais je n'ai pas fait beaucoup de revues de code. On me demande de relire le code écrit en Python mais je ne le connais pas.
Est-il logique de réviser le code dans une langue que je ne connais pas?
Je suis un développeur expérimenté, mais je n'ai pas fait beaucoup de revues de code. On me demande de relire le code écrit en Python mais je ne le connais pas.
Est-il logique de réviser le code dans une langue que je ne connais pas?
Réponses:
Aucun sens? Oui. Même si vous ne connaissez rien à la sémantique d'un langage de programmation, vous pouvez toujours lire des caractères et constater des mises en forme incohérentes, des commentaires manquants, des identificateurs mal choisis, des duplications évidentes, etc.
Beaucoup de sens ou assez de sens pour rembourser le coût de votre temps ? Je ne suis pas sûr. Cela dépend de votre position, de l'importance des révisions de code dans le flux de travail de votre équipe et de plusieurs autres facteurs que nous ne pouvons pas quantifier suffisamment.
enumerate
.) Je pense que votre commentaire est un excellent exemple de la raison pour laquelle essayer de réviser une langue que vous ne connaissez pas devrait tout au plus être éducatif pour vous-même.
En tant que contributeur régulier à Code Review Stack Exchange , je rencontre beaucoup de questions concernant des problèmes liés à une question de langage, par exemple:
Et la liste continue. Cependant, même si je n'ai pas besoin de connaître la langue, je peux quand même examiner ces problèmes / points.
Certains de nos principaux utilisateurs ont les meilleures réponses dans des langues qu'ils n'utilisent pas activement ou ne connaissent pas. Même deux de mes dix principaux sont dans des langues que je ne connais pas et que je ne peux pas compiler / exécuter sur ma machine.
Je dirais même que ce serait la même chose que de réviser le pseudo-code de quelqu'un. Tant que vous pourrez observer et commenter des choses pertinentes par rapport à ce que vous comprenez, tout ira bien, et ce sera pertinent.
Voici la ligne de fond, à mon avis:
Pour la situation spécifique de ne pas connaître Python, je me méfierais particulièrement de cela. Python a beaucoup d'idiomes et de pratiques standard qui donnent au Python un aspect très différent de ce que vous pourriez attendre dans d'autres langages. (En effet, je pense que les choses soulignées par Python ont amélioré l' apparence de mon code dans d' autres langages, et non l'inverse.) Beyond PEP8 offre un bon exemple de la façon dont vous pourriez manquer complètement à l'état d'esprit que Python encourage.
Regardons un exemple simple. Prenez ce code:
f = open('/home/me/something.txt')
try:
content = f.read()
finally:
f.close()
Voir le problème avec ce code? Si vous n'avez pas travaillé avec Python, probablement pas. Le problème est qu’il existe un style très préféré dans Python qui fait exactement la même chose:
with open('/home/me/something.txt') as f:
content = f.read()
Ceci est un gestionnaire de contexte. Savez-vous ce qu'ils sont bons? Savez-vous quand il serait approprié d'en utiliser un? Savez-vous quand il serait approprié de créer le vôtre? Non? Dans ce cas, vous n'êtes probablement pas prêt à examiner Python.
Regardons un autre exemple.
def add_fifty(other_list):
result = list()
for i in other_list:
result.append(i + 50)
return result
x = range(10)
y = add_fifty(x)
Voir le problème? Le problème est que cette méthode est totalement inutile . Vous devriez probablement simplement utiliser une compréhension en place, lorsque l'opération est aussi simple:
x = range(10)
y = [i + 50 for i in x]
Si vous ne l'avez pas vu, vous n'êtes pas familiarisé avec les fonctionnalités et les idiomes de Python.
Ils vous ont peut-être demandé de réviser le code Python précisément parce que vous ne connaissez pas Python . Il existe une théorie de gestion selon laquelle il est utile d'avoir un "imbécile" dans une équipe. Je ne vous traite pas de mauvaise réputation :) L'idée est qu'une équipe puisse souffrir de penser en groupe et développer une vision en tunnel. Une façon de sortir de cette situation est d’inclure dans l’équipe une personne que les autres membres de l’équipe considéreraient comme un «imbécile», c’est-à-dire une personne qui ne connaît pas le sujet. Vous poserez des questions pour vous informer et les questions viendront d'un point de vue que les autres membres de l'équipe n'auraient probablement jamais envisagé.
Vous ne connaissez pas Python, donc ce qui peut sembler ordinaire aux codeurs Python peut sembler étrange pour vous. Vous pourriez suggérer une amélioration que l'équipe n'a jamais envisagée.
La révision de code ne consiste pas à rechercher des variables avec une orthographe non valide et un formatage incorrect. Si vous utilisez la révision de code pour trouver de telles choses, arrêtez de perdre votre temps et utilisez un outil.
L'examen de code a pour but d'améliorer la conception et de détecter les erreurs courantes d'un programmeur débutant.
Comme je programme en C ++ et que je ne connais pas assez Python, je n’oserais pas passer en revue le code Python. Cependant, je pourrais aider avec une révision du code Java.
Vous n'avez pas indiqué dans quelle langue vous programmez, mais je ne vois pas ce que vous pourriez contribuer à une révision de code, si vous ne connaissez pas la langue dans laquelle il est programmé.
Les révisions de code (en plus de rechercher des failles) constituent une bonne introduction d'un membre de l'équipe à d'autres pour l'ajout ou la modification de code. Si vous êtes un développeur expérimenté , vous devriez être capable de lire suffisamment pour comprendre la plupart du temps ce qui se passe.
Examinez la révision de code du point de vue du chef d’équipe: il y a une personne qui comprend ce que l’application doit faire (logique métier), une personne qui comprend le code (logique d’implémentation) et éventuellement plusieurs autres personnes. là-bas qui ont besoin d'avoir une idée de la façon dont tout cela va ensemble.
Vous ne devriez certainement pas être le seul critique, mais il existe de nombreuses bonnes raisons pour que vous en fassiez partie . Ne pas connaître la langue n'est pas un obstacle pour beaucoup de questions qui nécessitent une réponse dans une révision de code. Par exemple, je suis l'un des 20 principaux répondants du tag C # sur ce site et je n'ai pas encore beaucoup compilé hello world en C #.
Une expertise que vous pouvez partager sans connaître la langue:
C'est aussi un bon moyen de se familiariser avec un nouveau produit. Je viens de rejoindre une nouvelle équipe, où je connais très bien les langues, mais je ne connais pas le domaine. Participer à des revues de code m'a permis de mieux connaître le domaine, même si je n'ai pas encore pu contribuer beaucoup dans ce sens.
Dans votre cas, ce sera un bon moyen d’apprendre les idiomes d’une nouvelle langue, au vu des commentaires laissés par les autres commentateurs. Ce sont des choses très difficiles à apprendre autrement, parce que votre interprète ne se soucie pas de savoir si votre code est pythonique ou non.
Cela pourrait être une situation gagnant-gagnant. J'irais même jusqu'à dire que vous pourriez être un critique particulièrement utile, car vous êtes une vierge Python qui n'a pas été souillée par la malédiction de la connaissance .
Pensez-y de cette façon: si le code est suffisamment clair pour que même une vierge Python puisse le comprendre, alors il doit s'agir d'un bon code. Les parties que vous avez du mal à comprendre pourraient être retouches ou mieux commentées.
De toute évidence, cela serait également bénéfique pour vous, car vous choisiriez une nouvelle langue au fur et à mesure. (Nous espérons que le code qui vous a été fourni est un bon exemple à suivre.) Cet arrangement devrait fonctionner particulièrement bien pour Python, un langage qui a la réputation d'être un "pseudocode exécutable". Si vous êtes un développeur expérimenté, vous ne devriez pas avoir beaucoup de difficulté à comprendre l'essentiel d'un programme Python.
La mise en garde serait que vous ne devriez pas s'attendre à repérer des bogues provenant de pièges spécifiques à une langue . Mais la recherche de bogues n’est pas le seul objectif des revues de code. Si rien d'autre, vous participeriez au transfert de connaissances simplement en sachant ce qui se passe dans le code de votre collègue.
Une fois, on m'a demandé de vérifier un projet entrepris par un sous-traitant et qui semblait avoir de sérieux problèmes de performance. J'ai assez rapidement constaté que le facteur critique était un seul module Perl. Je n'avais jamais rencontré Perl auparavant et personne dans l'organisation ne le savait, alors j'ai commencé à essayer de le comprendre moi-même. Je n'ai jamais compris les détails, mais il était très clair que l'algorithme utilisé était quadratique en taille de données, ce qui était à l'origine de tous les problèmes. Alors oui, lire du code dans une langue que vous ne comprenez pas bien peut certainement être productif. Le bonus est que vous apprenez de nouveaux trucs à ce sujet.
Quelques observations:
1) Si vous êtes un développeur expérimenté, vous allez acquérir Python (ou au moins autant que vous devez savoir), simplement en travaillant avec. Ce sera un cas d’apprentissage par la pratique. Ce sera difficile au début, mais cela deviendra plus facile à mesure que vous maîtriserez la langue. Considérez cela comme une opportunité d'apprendre une autre langue (les gens apprennent souvent des langues "étrangères" par le biais de "l'immersion")
2) Il existe un certain nombre de personnes de valeur sur les sites de SE qui sont "non techniques", mais maîtrisent la grammaire, les communications et la logique. De telles personnes apportent un "regard neuf" sur les sujets et apportent un certain nombre de corrections "simples" qui ne manquent à personne, car elles sont trop "liées" dans le contenu. Vous êtes probablement consulté pour vos compétences non "techniques" (c'est-à-dire non Python) telles que la logique et la maîtrise de la programmation en général.
Et si vous n'avez pas fait beaucoup de révision de code, presque n'importe quelle expérience de révision de code vous aidera en tant que développeur. Cela semble être un bon compromis entre vos compétences et vos besoins et ceux de l'équipe.
Cela dépend de l'objectif de l'examen. c'est-à-dire ce que vous entendez par efficace .
Vous pourrez toujours détecter certains problèmes. Si vous êtes tout ce qu'ils ont à revoir avec et ils espèrent juste que vous jetez un coup d'oeil dessus ça aide et peut attraper quelque chose, alors bien sûr. De nombreux concepts de structure sont similaires entre les langues. L'une est en particulier de pouvoir revoir les commentaires. Il devrait être suffisamment commenté pour qu’un programmeur n’appartenant pas à cette langue particulière puisse néanmoins avoir une bonne idée de ce qui se passe. Sinon, vous pouvez leur dire où leurs commentaires font défaut. Si c'est aussi bien commenté ... alors vous devriez pouvoir revoir un peu leur structure en annotant ce qui se passe plutôt qu'en lisant le code de ce qui se passe.
Mais vous ne détecterez probablement pas beaucoup d'autres problèmes. Par conséquent, s’ils souhaitent que votre examen détermine de manière exhaustive si ce programme est bien conçu / viable, ils seront déçus.
Que ce résultat en vaille la peine ou non, cela dépend largement du projet.