Le 5 regole di un buon programmatore

7 Flares 7 Flares ×

Mai come in questo periodo mi sono trovato a scrivere codice e leggere codice (il mio e quello degli altri). Ho dovuto rimettere mano a vecchio codice prodotto, a piccole librerie create in passato (che a distanza di anni non valuto certo con voti altissimi). Mi sono ritrovato a confrontare un vecchio lavoro con quelli attuali, notando incredibili differenze in fatto di qualità del codice, prima ancora delle qualità delle conosocenze. A quel punto è stato facile derivare un paio di fattori chiave che potrebbero distinguere un buon programmatore da un ottimo programmatore, in attesa di capire la categoria nella quale sistemarmi. Sperando di poter regalare al lettore qualche utile consiglio.

1. Documentare il codice

Scrivere chiari e precisi commenti è impagabile. Permettono di leggere più facilmente il codice senza impazzire dietro ad algoritmi o funzioni o parametri conditi di mistero e di cui se ne disconosce la funzione, il significato e il motivo della loro esistenza. Gli stessi commenti devono essere scritti con coscienza, senza badare troppo alla forma magari, ma senza rinunciare a una certa formalità e un certo stile. Bisogna cercare di essere sempre chiari nelle spiegazioni e di non dare nulla per scontato. Prolissi e completi quando è rischiesto dal contesto, concisi quando è inutile divagare o spiegare cose ovvie e facilmente deducibili. Quando a distanza di tempo ci toccherà rimettere mano a un codice che abbiamo scritto di nostro pugno e di cui non ricordiamo molto, una veloce lettura dei commenti ci permette in pochi secondi di ritornare nella dimensione di quel progetto. Una buona documentazione del codice permette un alto livello di maintainability dello stesso. Nel caso, poi, ci fosse la necessità di collaborare con altri sviluppatori, il non dover chiedere costantemente chiarimenti su una funzione o un parametro permette di velocizzare il lavoro e migliorarlo sotto tutti i punti di vista, in quanto troveremo tutte le risposte dentro i commenti.

E’ possibile, in ultimo, estrarre dal codice sorgente i commenti formattati in un certo modo e produrre così un manuale per gli sviluppatori o una reference. Tutto in modo automatico ed evitando un doppio e tedioso lavoro. Uno strumento molto apprezzato, in tale contesto, è phpDoc (facile immagine per quale linguaggio).

Ultima raccomandazione, che a molti potrà suonare strana o esagerata. Se pensate che il vostro codice possa essere degno del panorama internazionale, cioè di un pubblico non solo italiano, allora è bene cominciare a prendere confidenza con l’inglese-scritto e commentare il codice in questa lingua.

2. Scrivere buon codice

E’ difficile in poche righe capire cosa significa “scrivere buon codice”, ma ci provo. Fra l’altro è una delle prime cose che uno studente si sente dire da un buon professore. Il pieno significato di un simile avvertimento dal sapore di consiglio lo si coglie solo quando si lavora seriamente a qualche progetto. O quando ci si confronterà con altri sviluppatori. Scrivere buon codice significa scrivere i nomi delle funzioni scegliendo i migliori termini, i più espressivi in assoluto. Conviene eliminare inutili abbreviazioni, solo per risparmiare qualche carattere e guadagnare qualche decimo di secondo in più sulla digitazione. Significa scrivere un codice la cui sola lettura è bastevole per capirne l’implementazione. Generalmente una funzione chilometrica è sintomo di scarsa progettazione del codice, il che non vuol dire che poi le cose non funzionano. La migliore palestra, in tal senso, è la lettura di codice dei migliori programmatori che potete trovare in rete e l’analisi di progetti dal codice aperto.

3. Framework e librerie

Spesso ci si trova a riscrivere del codice che in realtà esiste già e probabilmente risulta più completo del nostro, oltre che più efficace. Pertanto prima di buttarsi a capofitto nella scrittura di nuove classi occorre capire cosa offre Internet. Esistono diversi utilissimi siti dove poter trovare del buon codice (citiamo su tutti Sourceforge). Ed esiste Google per cercare eventuali librerie già pronte per essere usate nei nostri progetti. Se nulla ci soddisfa allora non resta che scrivere quanto abbiamo di bisogno. Se abbiamo intrapreso quest’ultima strada è buona cosa pensare non al progetto in sé, quanto piuttosto ai problemi generali che intendiamo risolvere. E’ questo infatti il caso migliore per pensare a una libreria riutilizzabile pure in altri progetti. Se poi siamo soliti lavorare su applicazioni che in qualche modo hanno molte somiglianze fra di loro, beh allora conviene pensare a qualche framework. Generalmente una grande società di software ne progetta uno e provvede a usarlo nei vari lavori. Uno sviluppatore indipendente può lanciare a se stesso la stuzzicante sfida di costruirne uno nuovo, o studiare per bene un framework esistente.

In tal senso un buon framework (Rails per i programmatori Ruby, Zend o Symfony per i programmatori PHP, Django per gli appassionati di Python) potrebbe essere una ottima base per sviluppare una grande applicazione. Ma occorre valutare per bene ogni fattore. Spesso un framework rischia di appesantire lo sviluppo e se non riusciamo ad ottimizzarne la configurazione rischiamo pure di ottenere un prodotto dalle scarse performance. E’ opportuno inoltre non focalizzarsi soltanto su un prodotto, ma studiarne più di uno per capire realmente benefici e svantaggi di ognuno di loro. A quel punto, e solo a quel punto, conviene sceglierne uno e provare a padroneggiarlo al meglio. In altre parole: non limitarsi a leggere qualche articolo su Internet (raramente ho scovato delle analisi pienamente oggettive sui software e sui framework), ma sperimentare le soluzioni. Quindi specializzarsi su un prodotto.

4. Standard e best practices

I design pattern vanno studiati, compresi e quindi usati. Spesso ci si accorge che bravi programmatori li disconoscono ed è un male. Pattern quali MVC offrono una potenza incredibile. E numerosi altri pattern offrono una soluzione ottimale a ricorrenti problemi per quanto riguarda la programmazione (che è poi la definizione di Design Pattern).

Quando parliamo di best practices ci riferiamo a delle esperienze che altri hanno già maturato in qualche settore professionale e nelle quali hanno raggiunto ottimi risultati. Potete pensare a delle regole generali, più o meno formalizzate, o a degli esempi opportunamente descritti e commentati. Per quanto mi riguarda mi sono stati utilissimi i libri di ingegneria del software che ho letto e sui quali ho trovato diversi riferimenti a ulteriori libri e articoli. Potete recuperare su internet diverse interviste a eminenti sviluppatori che raccontano le loro esperienze e le loro idee.

5. Pensare. Poi scrivere codice

Lontano da una schermo e una tastiera si riesce meglio a programmare. Sembra un paradosso, invece è la pura realtà. Provate a pensare alla vostra architettura fuori da una finestra di Mac o di Windows o di Linux. Fogli di carta, penna, matita e idee. Non è tempo sprecato, anzi tutto il contrario. Uno schermo con icone e testo, una tastiera e un mouse possono risultare degli elementi destabilizzanti e di distrazione. Si è tentati di scrivere subito del codice funzionante, salvo poi scoprire che una funzione poteva essere scritta meglio, o un insieme di classi poteva essere progettato in modo più intelligente. A quel punto tornare indietro è complicato. Rifattorizzare equivale a partire da zero (e a un livello iniziale non si parla certo di refactoring) e, si realizzerà con estremo rammarico, di aver buttato via preziose ore di lavoro.

Ponderare bene le scelte: tracciare diagrammi, appuntare note e idee, provare a scrivere un piano di sviluppo. Anche senza badare alla forma, una sorta di brainstorming solitario. Fate una lista dei problemi da risolvere, delle possibili soluzioni cui avete pensato e, dopo una pausa lontano da tutti e tutto, rileggete con attenzione quanto avete scritto e cercate di capire se è l’ora di mettersi a scrivere codice o conviene dedicare ancora qualche minuto a questa meditazione pre-sviluppo.

Non esiste un libro delle soluzioni in informatica. Esiste però una quantità smisurata di handle di soluzioni. Queste maniglie altro non sono che il codice e gli applicativi che altri programmatori hanno già realizzato e rilasciato. Dare uno sguardo all’interno del codice scritto da terzi (e dovete ovviamente scegliere i migliori terzi, perché conviene imparare soltanto dai migliori) si rivelerà presto preziosa lettura e fonte di soluzioni. Il che non vuol dire che dovete copiare, ma certamente ispirarvi. O, più umilmente, imparare.

7 Flares Twitter 2 Facebook 4 Google+ 1 LinkedIn 0 Buffer 0 Email -- 7 Flares ×

4 Comments Le 5 regole di un buon programmatore

  1. Pingback: diggita.it

  2. Pingback: Le 5 regole di un buon programmatore « Francesco Corsentino .net

  3. odino

    il codice, a parte *documentazione* di metodi e classi, non va commentato ;-)

    il secondo punto si chiama domain driven design :)

    Reply
  4. Kiko

    Ottima la precisazione sul secondo punto.

    E’ però pure evidente che io mi riferivo, quando dico documentare il codice, ad alcune parti eccezionalmente complesse.

    Reply

Lascia il tuo commento

Tranquillo: la tua email non verrà pubblicata.

Puoi usare i seguenti tag HTML e attributi: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>