Le cattive abitudini sono difficili da rompere e ancora di più se non ti rendi conto che quello che stai facendo sta minando il tuo lavoro. Se lo sai ma non ti interessa, sarebbe la cosa peggiore. Ma voi siete qui, no?
Come programmatore, ho visto un sacco di pratiche scadenti, non solo per quanto riguarda il codice, ma anche per quanto riguarda le abilità di lavoro di squadra. Io stesso sono stato colpevole di praticare molte di queste cattive abitudini. Ecco le mie 35 migliori cattive abitudini di programmazione, organizzate in quattro categorie: organizzazione del codice, lavoro di squadra, scrittura del codice, test e manutenzione.
Organizzazione del codice
1. Dire, “Lo aggiusto dopo”
L’abitudine di rimandare le correzioni del codice non è semplicemente un problema di priorità. Organizzare il vostro issue tracker potrebbe generare qualche progresso, ma avete anche bisogno di avere un modo per tracciare i problemi più piccoli che si presentano. Aggiungere commenti “TODO” è un modo veloce per assicurarsi di non perdere nulla.
2. Insistere su una soluzione one-liner
Essere ossessivi nello scrivere pezzi di codice efficienti ed eleganti è un tratto comune dei programmatori. È come risolvere un puzzle: si trova una combinazione di funzioni ed espressioni regolari che trasformano 20 linee di codice in 2 o 3. Sfortunatamente, non sempre il risultato è un codice leggibile, e questo è generalmente il risultato più importante. Rendete il vostro codice accessibile prima, poi intelligente.
3. Fare ottimizzazioni inutili
Un altro posto in cui spesso non mettiamo i nostri sforzi è l’ottimizzazione. Sembra bello ridurre la dimensione del tuo sito web di qualche byte, ma gzip non lo farà comunque? E le richieste non sono più importanti? Affrontate le ottimizzazioni alla fine di un progetto, perché il più delle volte i requisiti cambieranno e il vostro tempo sarà stato sprecato.
“L’ottimizzazione prematura è la radice di ogni male.”
-Donald Knuth
4. Convincersi che i problemi di stile non sono così importanti
Se ho imparato qualcosa in anni di osservazione del codice di altre persone, è che affrontare i problemi di stile di codifica è la cosa che gli sviluppatori rimandano più facilmente. Forse è difficile per i codificatori inesperti vedere cosa di buono verrà fuori dall’affrontare i problemi di stile, ma col tempo diventerà evidente che una volta che la qualità del codice deraglia, un effetto valanga trasformerà qualsiasi progetto in un completo disastro. Siate rigorosi sulle migliori pratiche anche se sembrano trascurabili. Impostate il controllo del codice e gli strumenti di linting per darvi spazio per preoccuparvi delle cose più importanti.
5. Spazzare le cose sotto il tappeto
Catturando e ignorando le eccezioni, o usando librerie che non riportano errori (come jQuery), ci sono molti modi per spazzare le cose sotto il tappeto. Ma quando uno di questi errori diventa una priorità, la sfida di risolverlo sarà molto più grande, considerando che non avrete idea da dove cominciare. Un modo semplice per evitarlo è registrare questi errori ignorati in modo da poterli studiare in seguito.
6. Usare nomi che non aggiungono informazioni
Nominare è difficile, ma c’è un modo semplice per assicurarsi che i nomi delle vostre variabili e funzioni siano almeno di qualità decente. Finché i nomi aggiungono qualche tipo di informazione che il resto del codice non trasmette, gli altri sviluppatori avranno un tempo più facile per leggere il vostro codice. La ragione per cui la denominazione è così importante è che i nomi possono dare un’idea generale di cosa fa il codice. Ci vuole più tempo se avete bisogno di scavare nei calcoli per capire cosa fa un pezzo di codice, ma un buon nome può aiutarvi a capire cosa fa il codice in pochi secondi.
7. Ignorare le migliori pratiche comprovate
Revisioni del codice, sviluppo guidato dai test, assicurazione della qualità, automazione della distribuzione: queste pratiche, e molte altre, hanno dimostrato il loro valore in innumerevoli progetti, ed è per questo che gli sviluppatori ne parlano costantemente nei blog. Un grande riferimento per queste best practices è il libro Making Software: What Really Works, and Why We Believe It. Prendetevi il tempo per imparare a farle correttamente, e il vostro processo di sviluppo migliorerà in tutti i vostri progetti in modi che vi sorprenderanno.
Lavoro di squadra
8. Abbandonare i piani troppo presto
Un modo sicuro per rendere il vostro sistema imperscrutabile è quello di non impegnarsi in un piano. Potete sempre dire, ogni volta che il vostro codice viene criticato, che il piano non è completo. Tuttavia, avere moduli mezzi finiti porterà ad un codice strettamente accoppiato non appena proverete a far funzionare quei moduli non finiti tra loro. Questo tipo di complicazione si presenta anche quando i ruoli di leadership di un progetto cambiano e i nuovi leader decidono che fare a modo loro è più importante della coerenza architettonica. Insistere su un piano che ha poche possibilità di funzionare
Così come abbandonare i tuoi piani può causare problemi, lo stesso vale per l’attenersi ad un piano che non funziona. Ecco perché dovreste condividere le vostre idee con il vostro team per ottenere feedback e consigli quando le cose si fanno difficili. A volte una prospettiva diversa può fare la differenza.
10. Lavorare sempre da solo
Dovresti sforzarti di condividere i tuoi progressi e le tue idee con la squadra. A volte pensi che stai costruendo qualcosa nel modo giusto, ma non è così, quindi la comunicazione costante è molto preziosa. È anche vantaggioso per le altre persone quando si lavora con loro. Il loro lavoro spesso migliora quando discuti le idee con loro e fai da mentore ai membri meno esperti del tuo team, che hanno maggiori probabilità di rimanere bloccati.
11. Rifiutarsi di scrivere cattivo codice
Arriva un momento nella vita di ogni sviluppatore in cui le scadenze ti costringono a scrivere codice terribile, e questo va bene. Avete provato ad avvertire il vostro cliente o manager delle conseguenze, ma loro insistono nel rispettare la scadenza, quindi ora è il momento di scrivere codice. O forse c’è un bug urgente che non può aspettare che tu trovi una soluzione pulita. Ecco perché è importante essere versatile come programmatore ed essere in grado di scrivere codice povero molto rapidamente così come codice buono. Si spera di poter rivedere il codice e ripagare il debito tecnico.
12. Incolpare gli altri
Non è un segreto che l’arroganza è un tratto fin troppo comune tra gli sviluppatori e altri professionisti tecnici. Prendersi la responsabilità dei propri errori è una virtù che vi farà brillare tra i vostri pari. Non abbiate paura di ammettere che avete fatto un errore. Una volta che vi sta bene, sarete liberi di concentrarvi sull’imparare perché avete fatto quell’errore e come evitarlo. Se non lo ammetti, imparare diventa impossibile.
13. Non condividere con il tuo team ciò che hai imparato
Il tuo valore come sviluppatore non è solo posto sul codice che scrivi, ma anche su ciò che impari mentre lo scrivi. Condividi le tue esperienze, scrivi commenti in merito, fai sapere agli altri perché le cose sono come sono, e aiutali a imparare nuove cose sul progetto e le sue complessità.
14. Essere troppo lenti nel dare feedback ai manager/clienti
Uno dei tratti caratteriali più preziosi di qualsiasi artigiano sta nell’assicurarsi che tutti siano sulla stessa pagina riguardo al lavoro, per quanto possibile. La ragione di questo non è perché il vostro manager possa riempire dei fogli di calcolo. È anche per il tuo guadagno personale: Avrete meno insicurezze e ridurrete l’incertezza sulla durata e sul futuro del progetto.
15. Non usare abbastanza Google
Il modo migliore per risolvere rapidamente un problema complesso è non doverlo risolvere affatto. In caso di dubbio, cercatelo su Google. Certo, puoi disturbare l’ingegnere accanto a te, ma raramente sarà in grado di dare una risposta così dettagliata come Stack Overflow, senza contare che interromperai anche il suo lavoro.
16. Sopravvalutando il tuo stile personale
Cercare sempre di coordinare il tuo stile di lavoro e la configurazione dell’ambiente con il tuo team. Idealmente, tutti nella tua squadra dovrebbero lavorare in condizioni simili e seguire lo stesso stile di codifica. Fare le cose a modo tuo può essere più divertente, ma i colleghi potrebbero non essere abituati al tuo stile di codifica, e se è insolito, sarà più difficile per il prossimo sviluppatore lavorare su ciò che hai costruito.
17. Avere un attaccamento personale al tuo codice
Quando qualcuno commenta il tuo codice, non prenderlo sul personale. Il vostro codice dovrebbe stare su un terreno solido; cioè, dovreste essere in grado di spiegare perché lo avete scritto in quel modo. Se ha bisogno di miglioramenti, questo è solo un riflesso della correttezza del codice, non di te stesso.
Scrivere codice
18. Non sapere come ottimizzare
Una buona strategia di ottimizzazione richiede una certa esperienza per essere corretta. Richiede esplorazione, analisi e conoscenza di ogni sistema coinvolto in un processo. Informatevi su queste cose. Impara la complessità algoritmica, la valutazione delle query del database, i protocolli, e come misurare le prestazioni in generale.
19. Usare lo strumento sbagliato per il lavoro
Non si può sapere molto, ma la ragione per cui si deve continuare ad imparare è che ogni nuovo problema porta un contesto diverso e richiede uno strumento diverso, uno più applicabile al compito da svolgere. Siate aperti a nuove librerie e linguaggi. Non prendere decisioni basate strettamente su ciò che si conosce.
20. Non preoccuparsi di padroneggiare gli strumenti e l’IDE
Ogni nuovo tasto di scelta rapida, scorciatoia o parametro che si impara mentre si utilizzano gli strumenti con cui si lavora ogni giorno avrà un effetto più positivo sulla velocità di codifica di quanto si pensi. Non si tratta di risparmiare qualche secondo usando un tasto di scelta rapida; si tratta di ridurre il cambio di contesto. Più tempo passate su ogni piccola azione, meno tempo avrete a disposizione per pensare al perché lo state facendo e a cosa viene dopo. Padroneggiare le scorciatoie libererà la vostra mente.
21. Ignorare i messaggi di errore
Non date per scontato di sapere cosa c’è di sbagliato nel vostro codice senza nemmeno leggere un messaggio di errore, o che lo capirete abbastanza velocemente. Avere più informazioni su un problema è sempre meglio, e prendersi il tempo per raccogliere queste informazioni farà risparmiare più tempo nel lungo periodo.
22. Romanticizzare il tuo toolkit da sviluppatore
A volte il tuo editor preferito o lo strumento a linea di comando non è lo strumento migliore per il lavoro a portata di mano. Visual Studio è ottimo per scrivere IDE, Sublime è ottimo per i linguaggi dinamici, Eclipse è ottimo per Java, e così via. Potreste amare vim o emacs, ma questo non significa che sia lo strumento giusto per ogni lavoro.
23. Hardcoding dei valori invece di renderli configurabili
Pensate sempre a quali cambiamenti potrebbero arrivare e a come affrontarli. Il debito tecnico crescerà ad una velocità mostruosa se non separate i pezzi mobili dal resto del vostro lavoro. Usate costanti e file di configurazione dove appropriato.
24. Reinventare sempre la ruota
Non scrivere codice di cui non hai bisogno. Forse qualcun altro ha già speso una buona quantità di tempo sul vostro problema, e lui o lei potrebbe avere una soluzione ben testata che potete riutilizzare. Risparmiatevi dei problemi.
25. Copiare/incollare ciecamente il codice
Capire il codice prima di riutilizzarlo. A volte non si nota immediatamente tutto quello che il codice sta facendo a prima vista. Imparerete di più su un problema quando vi prenderete il tempo di leggere il codice in dettaglio.
26. Non prendersi il tempo di imparare come funzionano veramente le cose
Cogliere sempre l’opportunità di espandere la propria conoscenza pensando a come funzionano le cose e leggendo i problemi sottostanti. Potresti risparmiare tempo non preoccupandoti in questo momento, ma quello che impari su un progetto sarà più importante a lungo termine di quello che hai effettivamente fatto.
27. Avere eccessiva fiducia nel proprio codice
È pericoloso assumere che solo perché hai scritto qualcosa, deve essere grande. Si impara di più sulla programmazione quando si lavora su cose nuove e si acquisisce esperienza, quindi date un’occhiata al vostro vecchio codice di tanto in tanto e riflettete su come siete progrediti.
28. Non pensare ai compromessi di ogni progetto, soluzione o libreria
Ogni prodotto ha i suoi punti deboli che imparerai a conoscere solo usandolo e analizzandolo. Vedere alcuni esempi d’uso di una libreria non vi renderà padroni di essa, né significa che sia la misura perfetta per ogni situazione che si presenterà nel vostro progetto. Siate continuamente critici su tutto ciò che usate.
29. Non chiedere aiuto quando sei bloccato
Mantenere un breve ciclo di feedback sarà sempre meno doloroso per te. Chiedere aiuto non significa che sei incompetente. Le persone giuste vedranno il vostro sforzo e l’ammissione della vostra ignoranza come una spinta ad imparare, e questa è una grande virtù da avere.
Test e manutenzione
30. Scrivere test per passare
Scrivere test che si sa che passeranno è necessario. Renderanno il refactoring e la riorganizzazione di un progetto molto più sicuri. D’altra parte, dovete anche scrivere test che sapete che non passeranno. Sono necessari per portare avanti il progetto e tenere traccia dei problemi.
31. Trascurare i test di performance per i casi critici
Preparare una configurazione di test di performance automatizzata a circa metà del processo di sviluppo di un progetto in modo da assicurarsi di non avere problemi di performance in aumento.
32. Non controllare che la tua build funzioni
È raro che una build passi ma non funzioni veramente, ma può succedere, e potrebbe essere fastidioso risolvere il problema più a lungo aspetti ad esaminarlo. Testare rapidamente ogni build è un’abitudine importante da avere.
33. Spingere grossi cambiamenti in ritardo, o andarsene dopo aver fatto un grosso push
Questo è il punto in cui l’eccessiva fiducia ti porterà, e può essere necessario scottarsi più volte per imparare perché non dovresti farlo, quindi segui il mio consiglio ora e assicurati di essere sempre lì quando la tua build alla fine si rompe.
34. Disconoscere il codice che avete scritto
Siate disposti a supportare il codice che avete scritto. Siete la persona più adatta per aiutare gli altri a capirlo. Dovresti sforzarti di far sì che il tuo codice rimanga leggibile a te stesso e agli altri per molti anni a venire.
35. Ignorare i requisiti non funzionali
Quando stai cercando di consegnare qualcosa, può essere facile dimenticare alcune aree importanti come le prestazioni e la sicurezza. Tenete una lista di controllo per quelle. Non volete che vi rovinino la festa perché avete stabilito le vostre scadenze senza pensare a queste preoccupazioni non funzionali.
Quali sono le vostre peggiori abitudini di programmazione?
Come si dice spesso, siamo creature abitudinarie. Migliorare il vostro modo di lavorare attraverso le abitudini è un ottimo modo per evitare di dover pensare troppo ad ogni singola situazione. Una volta che hai assimilato un buon modo di fare qualcosa, diventa senza sforzo.