Scrivere una richiesta pull efficace

Le richieste di pull sono l'elemento fondamentale di un repository. Mantengono tutto in movimento e in salute. Questa pagina spiega come creare una PR completa e facile da esaminare, il che aumenta le probabilità che venga unita.

Ecco i passaggi che puoi seguire per creare le migliori RP possibili.

  1. Comunica
  2. Inizia la configurazione
  3. Mantieni piccolo
  4. Mantieni uno stile semplice
  5. Testare la modifica
  6. Comunica (pt2)

Comunica

Prima di iniziare a scrivere codice, è utile comunicare con il team di base in modo che sappia cosa ti interessa.

Se c'è un problema che ti interessa, aggiungi un commento per indicare che inizierai a lavorarci. In questo modo, evitiamo che più persone lavorino alla stessa cosa. Un membro del team ti risponderà per confermare che è tuo.

Se hai un'idea che non è coperta da un problema, scrivila prima di iniziare a lavorare. In questo modo il team ha la possibilità di discutere del modo migliore per implementare la modifica prima di iniziare a creare, il che ti farà risparmiare lavoro nel lungo periodo.

Configurazione iniziale

Se è la prima volta che collabori a Blockly o blockly-samples, inizia dalla pagina Configurazione dello sviluppo.

Mantieni piccolo

Cerca sempre di mantenere le modifiche piccole e mirate. Preferiamo esaminare più richieste di pull più piccole anziché una sola richiesta di pull di grandi dimensioni. Ecco alcune buone regole generali:

  • Risolvi un problema. Non provare a risolvere più problemi contemporaneamente.
  • Limita l'ambito. In genere, una PR dovrebbe richiedere meno di 8 ore (a seconda della tua familiarità con la base di codice).
  • Utilizza i commit. Se la RP ti sembra un po' grande, suddividi le modifiche in gruppi logici utilizzando i commit di Git.

Puliscilo regolarmente

Perché è importante lo stile del codice? Il nostro obiettivo è duraturo e uno stile coerente semplifica la manutenzione. Lo stile si riferisce al modo in cui assegni i nomi alle variabili, ma riguarda anche la struttura del codice, la scrittura dei commenti e altro ancora. Ove possibile, utilizziamo strumenti come eslint per automatizzare i controlli dello stile.

Oltre a eslint, segui queste guide:

Testa la modifica

Prima di pubblicare una PR, devi sempre verificare che le modifiche funzionino, in modo da non dover tornare indietro e correggere le cose in un secondo momento. Ecco alcune idee per testare le diverse categorie di progetti:

  • Per i plug-in: scrivi test mocha automatici che coprono le modifiche.
  • Per esempi: testa manualmente tutte le funzionalità dimostrate.
  • Per i codelabs: esegui l'intero tutorial in un ambiente pulito e testa il codice di esempio fornito.

Comunica

Questa è l'ultima e, senza dubbio, la parte più importante della creazione di una nota stampa: scrivere il riepilogo.

Scrivere un riepilogo delle RP efficace aiuta gli altri sviluppatori a esaminare le modifiche, aumentando così la probabilità che vengano accettate più rapidamente.

Il riepilogo deve includere, ad esempio:

  • Il problema relativo alla RP.
  • La modifica apportata dalla RP.
  • Come hai testato la modifica.
  • Qualsiasi elemento che vuoi che venga esaminato dai revisori.
  • Qualsiasi altra informazione che ritieni necessaria per i revisori.

Se segui il modello PR quando crei la richiesta, non dovresti avere problemi. Ricorda solo di essere il più conciso e completo possibile.

Buona programmazione!