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.
6 errori comuni di sviluppo
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:
- 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;
- 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;
- 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;
- Lasciare il codice non commentato, tanto ci devo lavorare solo io (vedi ultimo punto)
- Posticipare i refactor per sviluppare nuove feature solo per avere la sensazione che il progetto stia andando avanti più velocemente;
- Rimandare continuamente lo studio approfondito di qualcosa…
Raccontaci la tua esperienza da “bad programmers”, scrivi nei commenti i tuoi errori comuni durante la programmazione!
