Le worst practices di sviluppo – Nel corso degli anni, quanti di voi si sono trovati a dire: “Questo errore non lo farò mai più! Giuro. È l’ultima volta che ci casco!”.

I buoni propositi sono una cosa meravigliosa, ti servono per superare i tuoi limiti e contribuiscono a farti sentire uno sviluppatore migliore. Ogni volta un po’ di più.

Il problema è che, nonostante i buoni propositi, gli errori tendono a ripresentarsi con una regolarità sconcertante.

Per questo motivo, dopo una serie di utilissimi post sulle best practices di programmazione sul nostro profilo Linkedin, in una sorta di catarsi/autoflagellazione rituale abbiamo deciso di fare una lista di “worst practices di sviluppo” che, come una brutta dipendenza, ci affliggono da anni:

  1. Usare valori hardcoded per prototipare al volo e poi dimenticarli lì fino a quando, magari dopo un pomeriggio passato a cercare di riprodurre risultati attendibili, ti ricordi che un determinato valore non può cambiare perché “immortalato” nel codice neanche fosse stato inciso con una Snapmaker;
  2. Abusare delle features di annidamento degli stili dei pre-processori CSS per tentare di seguire fedelmente l’annidamento del markup per trovarsi con regole lunghe migliaia di caratteri e file da troppi KB per dire giusto che un paragrafo che compare una o due volte deve essere in grassetto;
  3. Sovrascrivere i valori di default dei framework tipo Bootstrap a livello di regole di stile e non settando le giuste variabili e poi accorgersi di doverlo rifare per ogni nuovo componente; 
  4. Lasciare il codice non commentato, tanto ci devo lavorare solo io (vedi ultimo punto)
  5. Posticipare i refactor per sviluppare nuove feature solo per avere la sensazione che il progetto stia andando avanti più velocemente;
  6. Rimandare continuamente lo studio approfondito di qualcosa…

Raccontaci la tua esperienza da “bad programmers”, scrivi nei commenti le tue worst practices di sviluppo!