J’accuse: Contro i Programmatori che Ignorano Git

on

Ovvero: un girone dantesco per chi copia composer.json invece di fare commit

Il Misfatto

Mi sono trovato davanti a questo scempio:

composer.json
composer.json.bak245p8
composer.json.bak245p8bis
composer.lock
composer-lock

E mentre contemplavo questo olocausto della ragione, ho capito: serve un girone dantesco dedicato.

Il Nono Cerchio dell’Inferno dei Programmatori

Girone dei Traditori del Version Control

«Nel mezzo del cammin della nostra codebase
mi ritrovai per una selva oscura
ché la retta via di git era smarrita»

Le Pene Eterne

I. La Bolgia dei Suffissatori Compulsivi

Qui soffrono coloro che invece di fare git commit aggiungono .bak.old.backup.2.final.final2.final_DEFINITIVO.final_DEFINITIVO_stavolta_si.

Pena: Condannati a cercare per l’eternità quale sia la versione giusta tra 47 file con nomi simili, mentre un demonio alle loro spalle urla “ERA NELL’ALTRO .BAK!”

II. Il Pozzo dei Commentatori di Codice

Programmatori che invece di cancellare codice vecchio lo commentano “per sicurezza”, creando migliaia di righe di codice zombie.

// function vecchia() {
// // non cancellarla mai
// // potrebbe servire
// // chi lo sa
// }

Pena: Leggere all’infinito codice commentato cercando di capire quale pezzo sia ancora in uso, mentre il codice commentato si moltiplica più velocemente di quanto possano leggere.

III. La Palude dei Maledetti composer.json

Il cerchio più profondo. Qui dimorano coloro che:

  • Copiano composer.json invece di fare branch
  • Creano composer.json.bak245p8bis (BIS! C’ERA GIÀ UN .bak245p8!)
  • Usano anche un altro pattern per fare la copia di composer.lock e ti buttano li in scioltezza un composer-lock
  • Fanno composer update in produzione alle 3 di notte
  • Committano vendor/ nel repository

Pena: Condannati a risolvere dependency conflict infiniti mentre ogni loro composer install installa versioni random di librerie incompatibili tra loro. Il comando composer update impiega 40 giorni e alla fine fallisce sempre con “Your requirements could not be resolved”.

IL PECCATO SUPREMO: Il Caso Magento 2

Ma c’è di peggio. Oh, c’è MOLTO di peggio.

Perché questa non è una codebase qualunque. Questa è Magento 2.

E questi maledetti hanno commesso il peccato imperdonabile: hanno installato lo stesso modulo (Amasty_CheckoutThankYouPage) in DUE POSTI DIVERSI:

  • Una volta tramite Composer in vendor/
  • Una volta copiato manualmente in app/code/

Il risultato?

Autoload error: Module 'Amasty_CheckoutThankYouPage' from '/var/www/html/app/code/Amasty/CheckoutThankYouPage' 
has been already defined 

Magento non sa quale usare. Io non so quale sia aggiornato. Dio stesso ha perso la speranza.

Ora dovrò passare ORE a:

  1. Controllare quale versione è in vendor/
  2. Controllare quale versione è in app/code/
  3. Verificare quale è quella “vera”
  4. Capire se le dipendenze in composer.lock corrispondono a quello che c’è realmente
  5. Scoprire quali altri moduli sono duplicati
  6. Piangere silenziosamente
  7. Bestemmiare rumorosamente
  8. Scrivere questo pamphlet

Questo è il vero inferno: non solo non hanno usato git, ma hanno violato la regola fondamentale di Magento 2: O composer O app/code/, MAI ENTRAMBI PER LO STESSO MODULO.

L’Accusa Formale

Io accuso questi programmatori di:

  1. Crimini contro l’Umanità Digitale: Aver reso impossibile capire quali modifiche sono state fatte, quando, e perché.
  2. Tradimento della Fiducia: Git esiste dal 2005. DUEMILA-CINQUE. Vent’anni per imparare git addgit commitgit push. Non è chiedere troppo.
  3. Pigrizia Attiva: Perché copiare un file e rinominarlo richiede più sforzo che fare un commit. È pigrizia che genera lavoro extra. È pigrizia inefficiente. È la peggiore forma di pigrizia.
  4. Assassinio della Collaborazione: Come dovrebbe lavorare un team quando il “version control” consiste nel leggere i nomi dei backup come foglie di tè?
  5. Devastazione del Composer.json: Un file elegante, semplice, che dichiara le dipendenze del progetto. Ridotto a un arlecchino di backup incomprensibili.
  6. Doppia Installazione dei Moduli: Il crimine più grave in Magento 2. Installare lo stesso modulo sia via Composer che copiandolo in app/code/. Questo non è solo ignoranza. È sabotaggio attivo.

La Sentenza

Git non è un optional. Non è “roba da smanettoni”. Non è “complicato”.

È il MINIMO sindacale della professione.

È come un idraulico che non sa dove si chiude l’acqua.

È come un elettricista che non sa distinguere fase e neutro.

È come un chirurgo che dice “i guanti? Mah, se ho tempo”.

Appello alle Generazioni Future

Giovani sviluppatori, ascoltate bene:

  • Non copiate mai file sorgente per “tenerli da parte”
  • Git è vostro amico: ogni modifica merita un commit
  • I branch esistono: usateli invece di creare file paralleli
  • Composer.lock è sacro: va committato, non duplicato
  • Vendor/ non va committato: MAI

E se un giorno vi trovate a scrivere composer.json.bak2:

FERMATEVI.

Respirate.

Fate quel commit che state rimandando.

Non diventate anche voi abitanti del nono cerchio.

Post Scriptum

Al collega dev stolto che ha creato .bak245p8bis:

Ti perdono.

Ma solo dopo che avrai fatto un corso di git.

E una confessione pubblica su Stack Overflow.

E 100 ore di community service sistemando repository aziendali.

«Lasciate ogne speranza, voi ch’intrate…

…in una codebase senza git»

Fine del J’accuse

Related Posts:

Rispondi

Questo sito utilizza Akismet per ridurre lo spam. Scopri come vengono elaborati i dati derivati dai commenti.