Experiencias personales en Babel #1 — Un PR con un número inusualmente alto de revisiones

Traducción Beta No Oficial

Esta página fue traducida por PageTurner AI (beta). No está respaldada oficialmente por el proyecto. ¿Encontraste un error? Reportar problema →

La semana pasada implementamos el soporte del parser para la especificación de decoradores en etapa 2 en Babylon — el parser de Babel. Si no sabes qué es un decorador, en resumen, un decorador proporciona una sintaxis concisa para afectar la definición de una clase o un método de clase que decoras.

JavaScript

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

  @throttle(500)
  expensiveMethod() {}
}

Uno de los aspectos más destacados de este PR fue la cantidad de revisiones que recibió.

Quizás esto se deba a que los decoradores son una de las características más publicitadas de JavaScript. Angular incluso consideró crear su propio sabor de JS llamado AtScript antes de decidirse por TypeScript, ya que les encantan tanto los decoradores (o como les gustaba llamarlos, "anotaciones").

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.¹

Cuando me uní inicialmente a Babel y no estaba muy familiarizado con la base de código, cada problema que encontraba se respondía casi al instante después de publicarlo en la sala de chat de Babel, lo que me dejó con la impresión (errónea) de que quizás los mantenedores son figuras divinas que lo saben todo y que se espera que todos se adhieran a los mismos estándares ficticios.

Incluso después de familiarizarme con la base de código, seguía enviando PRs sin documentación adecuada, bajo el supuesto de que me tomó tiempo resolver el problema y ver todos los aspectos, pero que si los revisores veían el código, podrían evaluarlo al instante, tal como respondían mis preguntas.

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.³

Uno de los placeres de que fusionen tu PR no es solo la programación, sino también hacer que el proyecto avance en la dirección esperada. Y lograrlo identificando lo que el proyecto necesita y pudiendo entregarlo.

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.

Y finalmente —la parte más importante que creo que generó tantas revisiones para este PR— fue facilitar a las personas que revisarían mi PR explicándoles todo lo que necesitarían para ponerse al día con la situación completa. Por casualidad, en ese momento el PR que hice pudo satisfacer algunos de los criterios que mencioné anteriormente:

1. Asegurarme de que los revisores conocieran todo el problema (mencionando en detalle las decisiones que tomé para que no necesitaran revisar el código para entenderlo)

2. La discusión en torno a ello (mencionando puntos de vista alternativos sobre algunas decisiones para facilitar su comparación con las decisiones tomadas)

3. Explicar claramente mi estrategia para resolver el problema (para ayudar en el aspecto técnico de la revisión —para que los revisores supieran lo que hice antes de ver el código, y no al revés)

¡Y eso fue lo que funcionó! (o eso creo). Así que aquí está el misterio resuelto — Un PR con un número inusualmente alto de revisiones¹.

PD: Quería compartir mi experiencia personal con esta publicación, no escribir una guía a seguir ni un artículo técnico. Por lo tanto, algunas afirmaciones que hago pueden no ser ciertas en general o ser debatibles, así que deben leerse en el contexto de la experiencia que narro.

También ten en cuenta que si buscas soporte para decoradores en Babel, aún nos queda un largo camino por recorrer. Esto es solo el parser y el trabajo en la transformación (que convierte tu código en un ES5 funcionalmente equivalente) aún está pendiente. Pero ahora que hemos tomado las decisiones necesarias, las cosas avanzarán con mayor fluidez de aquí en adelante.

Notas al pie

1. Tenemos escasez de personal cuando se trata de revisar PRs. También se discutió recientemente en una de nuestras reuniones semanales (enlace a las notas de la reunión). ¡Quizás podrías ayudarnos con esto! Pasa por nuestra sala de chat en Slack y ofrece tu ayuda.

2. Siento que el mito surge del hecho de que cuando eres nuevo en el proyecto, los mentores definitivamente saben más sobre el proyecto que tú.

3. (a modo de ilustración) Algunos factores aleatorios que podrían afectar las posibilidades de que recibas ayuda:

• Si alguien estaba en línea que trabajó en lo mismo cuando publicas una pregunta en la sala de chat

• Alguien que sabe que tu duda llevará mucho tiempo resolver y quiere darte atención personal y no solo arrojarte información

• Alguien que es capaz de evaluar de dónde vienes, y así sucesivamente.

4. Habíamos estado estancados por un tiempo ya que mucha gente usa una implementación no estándar para decoradores que surgió cuando la especificación estaba en la etapa 0. Los cambios en la especificación no son compatibles con versiones anteriores, así que no estábamos seguros de cómo introducir soporte para la nueva especificación sin causar mucha interrupción para las personas que usan Babel. Finalmente decidimos que introduciríamos este PR como una opción para permitir que las personas migraran a su propio ritmo.

Cierre

Peeyush Kushwaha es un estudiante del GSoC 2017. ¡Síguelo en Twitter: @PeeyFTW!

Esto fue publicado originalmente aquí en Medium. ¡Consulta nuestra primera publicación sobre el Summer of Code para más información!