I commit convenzionali non salveranno i tuoi messaggi di commit

Una ricerca veloce su internet rivelerà una miriade di articoli che ti insegnano come scrivere messaggi di commit. Il 90% di questi articoli ti dice di usare i commit convenzionali. Tuttavia, un numero considerevole di sviluppatori continua a lottare con questo. Sanno che dovrebbero seguire queste convenzioni, ma trovano difficile applicarle nella pratica. Ogni volta che fanno un commit del codice, si angosciano sul fatto di scrivere "refactor" o "chore". Ho persino visto progetti in cui la lista dei messaggi di commit consiste interamente dello stesso messaggio: "feat: add page", perché scrivere i messaggi di commit era troppo difficile per loro, e semplicemente hanno rinunciato.

È troppo presto per parlare di commit convenzionali#

Non sto dicendo che i commit convenzionali siano cattivi. Hanno molti benefici ben noti:

• Forniscono un formato unificato, rendendo i messaggi di commit più standardizzati
• Sono facili da analizzare per strumenti automatici, consentendo la generazione automatica del changelog
• Aiutano i membri del team a comprendere lo scopo e la portata delle modifiche al codice
• Permettono una rapida identificazione di diversi tipi di modifiche al codice

Tuttavia, quando uno sviluppatore ancora lotta a scrivere buoni messaggi di commit anche dopo aver utilizzato i commit convenzionali, gettare loro un articolo su come usare i commit convenzionali, insegnando cosa significa il tipo feat, cosa significa il tipo fix, è in realtà inutile. È come dare un libro di cucina avanzato a qualcuno che non sa cucinare, senza insegnargli come usare ingredienti e utensili di base. Eppure, tali articoli sono ovunque su internet. Pochi sanno che i commit convenzionali possono essere veramente efficaci solo quando gli sviluppatori hanno un chiaro pensiero e la capacità di dividere precisamente i compiti.

Quindi, i commit convenzionali non sono cattivi, ma prima di arrivarci, dobbiamo stabilire la giusta mentalità di sviluppo e usare un pensiero scientifico da sviluppatore per fare le cose.

Pensiero chiave per scrivere buoni messaggi di commit#

Le modifiche al codice dovrebbero fare una cosa alla volta#

Nello sviluppo software, "fare una cosa alla volta" è un principio importante. Questo si applica non solo alla scrittura del codice ma anche al fare commit del codice. Quando ci concentriamo su un compito o una modifica specifica alla volta, il nostro codice diventa più chiaro e le nostre intenzioni più esplicite. Questo metodo non solo migliora la leggibilità del codice ma semplifica notevolmente il processo di revisione del codice. I revisori possono comprendere e verificare più facilmente lo scopo di ciascuna modifica.

Inoltre, questo metodo offre convenienza per potenziali rollback del codice. Se si verificano problemi, possiamo individuare e annullare più facilmente modifiche specifiche senza influenzare altre parti non correlate. Soprattutto, quando ogni modifica fa solo una cosa, il messaggio di commit che descrive questa modifica diventa naturalmente più preciso e significativo.

In pratica, questo significa che dobbiamo definire chiaramente il compito da completare prima di iniziare a codificare. Dopo aver completato un compito, dovremmo immediatamente fare un commit del codice, anziché aspettare che più compiti siano completati prima di fare commit insieme. Se scopriamo altre aree che necessitano di modifiche mentre completiamo il compito attuale, il miglior approccio è annotarle e gestirle separatamente dopo aver completato il compito attuale. Ad esempio, quando stai implementando una funzionalità e scopri dei bug esistenti, ciò che dovresti fare non è correggere il bug immediatamente insieme al tuo nuovo codice di funzionalità, ma piuttosto implementare prima la funzionalità e poi correggere il bug che hai scoperto in un altro commit, o correggere prima il bug e poi fare commit della funzionalità.

I messaggi di commit in realtà esistono prima di scrivere il codice#

Molti sviluppatori iniziano a pensare a come scrivere i messaggi di commit solo dopo aver completato il codice, ma in realtà, i messaggi di commit dovrebbero esistere prima di iniziare a codificare. Questo perché i messaggi di commit essenzialmente riflettono i passi che compiamo per completare un compito. In altre parole, sono i nostri elementi di lavoro da fare (todo).

Quando iniziamo un compito, dovremmo prima pensare a quali passi specifici sono necessari per completare questo compito. Questi passi sono la nostra lista di cose da fare, e allo stesso tempo, sono i nostri futuri messaggi di commit. Con questa lista di cose da fare, ciascuna delle nostre modifiche al codice ha uno scopo, mantenendoci concentrati durante la codifica e prevenendo deviazioni dal compito.

Più importante, questo metodo può migliorare significativamente la nostra efficienza. Quando completiamo un passo, il messaggio di commit corrispondente è già preparato, e possiamo usarlo direttamente, riducendo il tempo trascorso a pensare a come descrivere la modifica. Allo stesso tempo, poiché questi messaggi di commit sono completati quando abbiamo una comprensione completa del compito, sono generalmente di qualità superiore e più informativi.

Supponiamo che tu debba implementare una nuova funzionalità di registrazione utente. Potresti pianificare i passi del tuo compito in questo modo:

1. Rifattorizzare il componente di modulo esistente per renderlo più generico e riutilizzabile
2. Creare un modulo di registrazione utente
3. Implementare l'integrazione API per la registrazione utente
4. Aggiungere test unitari per la funzionalità di registrazione utente
5. Aggiornare la documentazione per la funzionalità di registrazione utente

I messaggi di commit corrispondenti a questi passi potrebbero essere i seguenti:

1. refactor: migliorare il componente di modulo esistente per riutilizzabilità
2. feat: creare modulo di registrazione utente
3. feat: implementare integrazione API per registrazione utente
4. test: aggiungere test unitari per registrazione utente
5. docs: aggiornare documentazione per funzionalità di registrazione utente

In questo modo, hai chiari i passi del compito e i corrispondenti messaggi di commit concisi prima di iniziare a codificare. Questi messaggi di commit sono in realtà la tua lista di cose da fare, guidandoti attraverso l'intero processo di implementazione della funzionalità.

Man mano che completi ogni passo, puoi usare il messaggio di commit corrispondente per fare commit del tuo codice. Questo non solo ti aiuta a organizzare ed eseguire meglio i compiti, ma garantisce anche che ogni commit si concentri su uno specifico passo, rendendo l'intero processo di sviluppo più chiaro e gestibile. Se hai bisogno di regolare leggermente il messaggio di commit durante la codifica reale, puoi fare piccole modifiche per descrivere più accuratamente le modifiche effettive.

I commit convenzionali diventano una scelta naturale#

Quando sviluppiamo la giusta mentalità di sviluppo, usare i commit convenzionali diventa naturale. A questo stadio, scoprirai che scegliere il giusto prefisso di tipo (come feat, fix, refactor, ecc.) diventa senza sforzo perché i tuoi messaggi di commit già riflettono chiaramente i tuoi passi del compito.

Se vuoi saperne di più su come usare i commit convenzionali, ci sono molti eccellenti articoli disponibili online. Ma ricorda, questi standard possono essere veramente efficaci solo quando sono costruiti sulla base della giusta mentalità di sviluppo.

Conclusione#

Scrivere buoni messaggi di commit non riguarda solo seguire un certo formato. Richiede che manteniamo un pensiero chiaro durante il processo di sviluppo, chiarire lo scopo di ogni cambiamento, e considerare come descrivere il nostro lavoro prima di iniziare a codificare.

I commit convenzionali sono effettivamente uno strumento utile, ma possono esercitare il loro massimo effetto solo quando combinati con la giusta mentalità di sviluppo. Praticando i due principi di "fare una cosa alla volta" e "pensare ai messaggi di commit in anticipo", possiamo non solo migliorare la qualità dei messaggi di commit ma anche migliorare l'efficienza complessiva dello sviluppo e la qualità del codice.

Spero che questo articolo ti aiuti a ripensare al tuo processo di sviluppo e ti incoraggi a provare questi metodi. Ricorda, le buone abitudini di sviluppo richiedono tempo per essere coltivate, ma una volta formate, miglioreranno notevolmente la tua efficienza lavorativa e la qualità del codice.