Nessun risultato. Prova con un altro termine.
Guide
Notizie
Software
Tutorial

Scott Remnant: Git e i DVCS uccidono la creatività

Link copiato negli appunti

A quanto pare Scott Remnant, il creatore di

[!] Ci sono problemi con l'autore. Controllare il mapping sull'Author Manager

, è tornato alla carica sui sistemi di controllo versione (DVCS) - e dopo il suo celeberrimo "

[!] Ci sono problemi con l'autore. Controllare il mapping sull'Author Manager

" ha lanciato, questa volta in maniera leggermente più costruttiva, un altro monito, con un suo

[!] Ci sono problemi con l'autore. Controllare il mapping sull'Author Manager

: i DVCS uccidono la creatività dei programmatori.

Perché? Beh, perché una volta lanciato ´git commit´, la modifica di un programmatore viene impressa per sempre nel log dei cambiamenti, ed in questo modo diventa molto più difficile riportare il tutto, in caso di errori eclatanti, ad uno stadio funzionante. Ciò che Remnant mette in luce, quindi, è soprattutto, esemplificando tramite

[!] Ci sono problemi con l'autore. Controllare il mapping sull'Author Manager

, la difficoltà di tornare indietro ad un commit precedente; e se questo non è esattamente vero per il commit immediatamente precedente quello incriminato, è assolutamente una certezza per i cambiamenti avvenuti in tempi precedenti.

Tuttavia, Remnant ottenebrato dal proprio odio per

[!] Ci sono problemi con l'autore. Controllare il mapping sull'Author Manager

ha divagato e secondo me non ha espresso, dopo la criticità, anche le possibili soluzioni. Riferendosi infatti soprattutto alla partenza di nuovi progetti, ha poi assolutizzato il proprio pensiero:

Il bisogno di "committare" e testare il proprio lavoro in corso d´opera significa sentirsi obbligati a fare le cose per bene tutte le volte, e ogni volta [la modifica] andrà incisa sulla pietra e questo significa che deve essere perfetta. Anche peggio se si è costretti a fare una review del codice.

Questo non è propriamente vero: un sacco di progetti infatti proseguono soprattutto grazie a contributi sperimentali e, ovviamente, non ci si può aspettare che il primo commit sia ineccepibile e contenga già le soluzioni a tutti i problemi. I branch esistono apposta: per sperimentare senza dar fastidio agli altri programmatori (o a se stessi, in vari casi) basta spostare il proprio flusso di lavoro su un branch a parte e vedere così se le proprie modifiche hanno l´effetto desiderato, senza paura di "rompere" il codice.

D´altronde,

[!] Ci sono problemi con l'autore. Controllare il mapping sull'Author Manager

si è espresso in maniera abbastanza concorde alla mia:

Puoi quindi anche dire che decidere di premere "salva" nel tuo editor farà si che tu venga congelato in una sorta di indecisione perché i tuoi errori sono stati registrati permanentemente sul disco rigido.

In ogni caso, Remnant ha ragione su una cosa: c´è la necessità, in ogni DVCS, di una feature di rollback rapido ad un commit a caso - una sorta di Time Machine del codice. Essendo Git un sistema basato su diff non è facile realizzare qualcosa di simile, ma ci si può provare senza dubbio. Magari con un branch apposito.

Questo articolo contiene link di affiliazione: acquisti o ordini effettuati tramite tali link permetteranno al nostro sito di ricevere una commissione nel rispetto del codice etico. Le offerte potrebbero subire variazioni di prezzo dopo la pubblicazione.

Ti consigliamo anche