Esperienze Personali in Babel #1 — Una PR con un Numero Insolitamente Alto di Revisioni

Traduzione Beta Non Ufficiale

Questa pagina è stata tradotta da PageTurner AI (beta). Non ufficialmente approvata dal progetto. Hai trovato un errore? Segnala problema →

La scorsa settimana abbiamo integrato il supporto nel parser per la specifica dei decoratori allo stage-2 in Babylon — il parser di Babel. Se non sapete cosa sia un decoratore, in sintesi fornisce una sintassi concisa per influenzare la definizione di una classe o di un metodo di classe che viene decorato.

JavaScript

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

  @throttle(500)
  expensiveMethod() {}
}

Uno degli aspetti più notevoli di questa PR è stato il numero di revisioni che ha ricevuto

Probabilmente perché i decoratori sono una delle funzionalità più acclamate in JavaScript. Angular aveva persino valutato di creare un proprio linguaggio JS chiamato AtScript prima di optare per TypeScript, poiché apprezzano così tanto i decoratori (o come preferivano chiamarli "annotazioni").

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

Quando mi sono unito inizialmente a Babel, senza ancora padroneggiare la codebase, ogni problema che incontravo veniva risolto quasi istantaneamente dopo averlo postato nella chatroom di Babel. Questo mi aveva lasciato con l'impressione (errata) che i maintainer fossero figure quasi divine che sapevano tutto, e che tutti dovessero aderire a quegli stessi standard fittizi.

Anche dopo aver acquisito familiarità con la codebase, continuavo a inviare PR senza una documentazione adeguata, presupponendo che se a me era servito tempo per risolvere il problema e analizzare ogni aspetto, i revisori avrebbero comunque potuto valutare il codice immediatamente, proprio come rispondevano alle mie domande.

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

Una delle soddisfazioni nel vedere la propria PR approvata non risiede solo nella programmazione, ma nel contribuire a far progredire il progetto nella direzione prevista. Riuscire a identificare ciò di cui il progetto ha bisogno e poterlo fornire.

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.

Infine — l'aspetto più importante che secondo me ha generato questo numero di revisioni — è stato semplificare il lavoro dei revisori spiegando tutto ciò di cui avevano bisogno per comprendere a fondo la situazione. Per caso, la PR che ho creato soddisfava alcuni dei criteri menzionati:

1. Assicurarsi che i revisori conoscano l'intero problema (descrivendo in dettaglio le decisioni prese, così da non dover necessariamente analizzare il codice per capirlo)

2. La discussione circostante (citando prospettive alternative su alcune decisioni per facilitare il confronto con le scelte effettuate)

3. Spiegare chiaramente la mia strategia risolutiva (per supportare l'aspetto tecnico della revisione — consentendo ai revisori di comprendere il mio approccio prima di esaminare il codice, e non viceversa)

Ed è stato questo a fare la differenza! (o almeno credo). Ecco svelato il mistero — una PR con un numero insolitamente alto di revisioni¹.

PS: Volevo condividere la mia esperienza personale con questo post, non scrivere una guida da seguire né un articolo tecnico. Pertanto, alcune affermazioni potrebbero non essere universalmente valide o essere opinabili, dovrebbero essere lette nel contesto dell'esperienza che racconto.

Notate inoltre che se cercate il supporto per i decoratori in Babel, c'è ancora molto lavoro da fare. Questo riguarda solo il parser, mentre la trasformazione (che converte il codice in ES5 funzionalmente equivalente) deve ancora essere implementata. Ma ora che abbiamo preso le decisioni necessarie, le cose procederanno più fluidamente.

Note a piè di pagina

1. Abbiamo carenza di personale per quanto riguarda la revisione delle PR. Questo tema è stato recentemente discusso in uno dei nostri meeting settimanali (link agli appunti del meeting). Potresti aiutarci in questo? Passa nella nostra chatroom di Slack e offri il tuo contributo!

2. Credo che questo mito nasca dal fatto che quando sei nuovo al progetto, i mentor conoscono sicuramente meglio il progetto di te

3. (a titolo esemplificativo) Alcuni fattori casuali che potrebbero influenzare le possibilità di ricevere aiuto:

• Se qualcuno era online e aveva lavorato sulla stessa cosa quando hai postato una domanda nella chatroom

• Qualcuno che sa che il tuo dubbio richiederebbe molto tempo per essere affrontato e vuole darti attenzione personale anziché limitarsi a lanciarti informazioni

• Qualcuno in grado di capire da dove stai partendo, e così via.

4. Siamo rimasti bloccati per diverso tempo poiché molte persone utilizzano un'implementazione non standard per i decoratori, risalente al periodo in cui la specifica era allo stage-0. Le modifiche nella specifica non sono retrocompatibili, quindi eravamo incerti su come introdurre il supporto per la nuova specifica senza causare troppi disagi agli utenti di Babel. Abbiamo infine deciso di introdurre questa PR come funzionalità opt-in per consentire alle persone di migrare con i propri tempi.

Conclusione

Peeyush Kushwaha è uno studente del GSoC 2017. Seguitelo su Twitter: @PeeyFTW!

Questo articolo è stato originariamente pubblicato qui su Medium. Consultate il nostro primo post sul Summer of Code per maggiori informazioni!