Expériences personnelles chez Babel #1 — Une PR avec un nombre inhabituel de revues

Traduction Bêta Non Officielle

Cette page a été traduite par PageTurner AI (bêta). Non approuvée officiellement par le projet. Vous avez trouvé une erreur ? Signaler un problème →

Nous avons intégré la prise en charge par le parser de la spécification des décorateurs en stage 2 la semaine dernière dans Babylon — le parser de Babel. Si vous ne savez pas ce qu'est un décorateur, l'essentiel est qu'il fournit une syntaxe concise pour modifier la définition d'une classe ou d'une méthode de classe que vous décorez.

JavaScript

@frozen class Foo {
  @configurable(false)
  @enumerable(true)
  method() {}

  @throttle(500)
  expensiveMethod() {}
}

L'une des choses les plus remarquables concernant cette PR fut le nombre de revues qu'elle a reçues

Cela s'explique probablement par le fait que les décorateurs sont réellement l'une des fonctionnalités les plus médiatisées de JavaScript. Angular avait même envisagé de créer sa propre variante de JS appelée AtScript avant d'opter pour TypeScript, tant ils affectionnent les décorateurs (ou comme ils aimaient les appeler « annotations »).

Well, there is more to the story. As I was recently discussing with a mentor, reviewing PRs is a tough job. Reviewing PRs is comparably as hard as solving the bug in the first place was. Apart from the technical aspect of reviewing — which is ensuring that the bug is being fixed optimally (by perhaps even getting an idea of how they would solve the issue and seeing how the submitted patch compares to their idea) — there’s another big hindrance. A reviewer has to be aware of the whole issue, the discussion surrounding it, and have familiarity with the part of the codebase that the PR makes changes to.¹

Lorsque j'ai rejoint Babel initialement, sans être très familier avec la codebase, chaque problème que je rencontrais était résolu presque instantanément après que je l'aie posté dans le chat de Babel, ce qui m'a laissé l'impression (erronée) que les mainteneurs étaient peut-être des figures divines omniscientes et que chacun devait respecter ces standards fictifs.

Même après avoir maîtrisé la codebase, je soumettais des PR sans documentation appropriée, partant du principe qu'il m'avait fallu du temps pour résoudre le problème et tout comprendre, mais que si les réviseurs voyaient le code, ils pourraient l'évaluer instantanément comme ils répondaient à mes questions.

Eh! Very wrong. Let me just bust this myth (assuming I’m not the only one who has felt it). Even they (maintainers) won’t have all the answers at times, and sometimes you’ll have to search for yourself — and that’s how it should be.²

In open source, there are a lot of people who want to contribute, but are unable to because they don’t know how to code / they don’t know how to present PRs / they don’t know what the project wants / they don’t know what the maintainers want / a ton of other things. A lot of times you’ll find help along the way, but a lot of that is controlled by factors beyond your control.³

L'une des joies de voir sa PR fusionnée ne réside pas seulement dans la programmation, mais aussi dans le fait de faire avancer le projet comme il est censé l'être. Et d'y parvenir en identifiant ce dont le projet a besoin et en étant capable de le fournir.

In order to merge this PR I had to find people and talk to them — people who use decorators, people who are interested in seeing an implementation of decorators, people who want to contribute to babel for decorators. After getting consensus on how to move forward⁴, I had to go through the spec and all the existing discussions surrounding it so that my understanding of the spec could be up to speed with other people.

Enfin — l'aspect le plus important qui selon moi a valu à cette PR le nombre de revues observé — faciliter la tâche des personnes qui allaient examiner ma PR en expliquant tout ce dont elles auraient besoin pour se mettre à jour sur l'ensemble de la situation. Par chance, à ce moment-là, la PR que j'ai faite a pu satisfaire certains des critères mentionnés précédemment :

1. S'assurer que les réviseurs connaissent l'intégralité du problème (en détaillant les décisions que j'ai prises pour qu'ils n'aient pas nécessairement à examiner le code pour les comprendre)

2. Mentionner les discussions autour du sujet (en évoquant les points de vue alternatifs sur certaines décisions pour faciliter leur comparaison avec les choix effectués)

3. Expliquer clairement ma stratégie pour résoudre le problème (pour assister l'aspect technique de la revue — afin que les réviseurs comprennent ce que j'ai fait avant d'examiner le code plutôt que l'inverse)

Et c'est ce qui a fait la différence ! (du moins je le pense). Voilà donc le mystère élucidé — Une PR avec un nombre inhabituel de revues¹.

PS : Je souhaitais partager mon expérience personnelle avec ce billet de blog, pas écrire un guide à suivre ou un article technique. Par conséquent, certaines affirmations que j'énonce peuvent ne pas être universellement valables ou être discutables, elles doivent donc être lues dans le contexte de l'expérience que je relate.

Notez également que si vous cherchez la prise en charge des décorateurs dans Babel, nous avons encore du chemin à parcourir. Ceci n'est que le parser et le travail sur la transformation (qui convertit votre code en ES5 fonctionnellement équivalent) reste à faire. Mais maintenant que nous avons pris les décisions nécessaires, les choses avanceront plus fluidement à partir de là.

Notes

1. Nous manquons de main-d'œuvre pour examiner les PR. Cette question a récemment été abordée lors d'une réunion hebdomadaire (notes de réunion). Vous pourriez peut-être nous aider ! Passez sur notre salon Slack pour proposer votre aide.

2. Je pense que ce mythe vient du fait qu'en tant que nouveau sur le projet, les mentors maîtrisent effectivement mieux le codebase que vous.

3. (pour illustrer) Quelques facteurs aléatoires pouvant influencer vos chances d'obtenir de l'aide :

• Qu'une personne travaillant sur le même sujet soit en ligne lorsque vous posez votre question dans le chat

• Qu'une personne comprenant que votre requête nécessite du temps veuille vous accorder une attention personnelle plutôt que de vous bombarder d'informations

• Qu'une personne soit capable de cerner votre niveau de compréhension, etc.

4. Nous étions bloqués depuis un moment car beaucoup d'utilisateurs emploient une implémentation non standard des décorateurs datant de l'époque où la spécification était en stage-0. Les changements actuels ne sont pas rétrocompatibles, nous hésitions donc sur la manière d'implémenter la nouvelle spécification sans perturber les utilisateurs de Babel. Nous avons finalement décidé de proposer cette fonctionnalité en opt-in pour permettre une migration progressive.

Pour finir

Peeyush Kushwaha est étudiant au GSoC 2017. Suivez-le sur Twitter : @PeeyFTW !

Cet article a originellement été publié sur Medium. Consultez notre premier billet sur le Summer of Code pour plus d'informations !