Blog | Settembre 2012

19/09/12

Il buono e il cattivo programmatore

Per rimanere in tema, una lunga e accurata classificazione (con caratteristiche e sintomi) del buon programmatore e, ovviamente, per contro anche del cattivo programmatore. Gli articoli sono lunghissimi, ne riassumo solo i punti principali.

Segni distintivi del buon programmatore

  1. Instinto di sperimentare le cose (verificare che funzionino)
  2. Distacco emotivo dal codice e dal progetto
  3. Desiderio di riparare ciò che non funziona
  4. Fascino per l’incomprensibile
  5. E’ costretto a insegnare

Segni distintivi del “fantastico” programmatore

  1. Pazienza incorruttibile
  2. Ricerca distruttiva della perfezione
  3. Conoscenza enciclopedica della piattaforma
  4. Pensiero in codice
  5. A Roma, si comporta da romano (per ogni linguaggio e ogni progetto sa scegliere il giusto approccio)
  6. Creazione dei propri tool

Segni distintivi di chi è destinato a compiti superiori

  1. Indifferenza alla gerarchia
  2. Eccitazione per i fallimenti
  3. Indifferenza alle circostanze
  4. Ininfluenza agli obblighi
  5. Dedizione all’impegno
  6. E’ guidato dall’esperienza

E per continuare, c’è anche l’altra faccia della medaglia:

Segni distintivi del cattivo programmatore

  1. Incapacità di ragionare sul codice
  2. Scarsa comprensione del modello di programmazione del linguaggio
  3. Scarsa conoscenza della piattaforma e capacità di ricerca
  4. Incapacità di comprendere i puntatori
  5. Difficoltà a ragionare sulla ricorsione
  6. Creazione di codice “fuorviante”

Segni distintivi del programmatore mediocre

  1. Incapacità di pensare per insiemi o blocchi
  2. Mancanza di spirito critico
  3. Programmazione “flipper” (un colpo a destra e un colpo a sinistra finchè le cose funzionano)
  4. Scarsa familiarità con i principi di sicurezza
  5. Creazione di codice “incasinato”

Segni distintivi di chi non avrebbe mai dovuto programmare

  1. Incapacità di determinare l’ordine di esecuzione di un programma
  2. Insufficiente capacità di pensare in modo astratto
  3. Sindrome dei “Collyer brothers” (accaparramento compulsivo)
  4. Senso di causalità non funzionante
  5. Indifferenza ai risultati

Leggi anche gli articoli originali: good e bad.

11/09/12

La giornata dello sviluppatore

Come programmatore sono rimasto positivamente colpito da quest’articolo. Quali sono le attività principali nella giornata dello sviluppatore e che percentuale di tempo viene dedicata alle stesse? Nessun programmatore dedica il 100% del suo tempo a scrivere righe di codice! E’ chiaro (ed è anche buona cosa) che non sia così…

Le attività principali sono quindi:

  • Analisi del codice: il tempo che viene dedicato a questa attività da parte dei bravi programmatori può andare dal 50% al 80% dell’intera giornata lavorativa. E la cosa non mi stupisce, anch’io mi comporto così.
    Se si vuole scrivere del buon codice ed ottenere un’applicazione elegante e funzionale non si possono semplicemente incollare dei pezzi di codice già scritto e collaudato, ma serve anche saper “incastrare bene i pezzi tra loro”, valutando per bene anche i possibili incastri. E perciò un’attenta analisi e una perfetta conoscenza del codice preesistente sono indispensabili.
  • Progettazione: anche questa è un’attività indispensabile. Farla bene o male può significare un grosso investimento, come una grossa perdita di tempo. Per progettare del buon software (soprattutto se si prevedono un lungo ciclo di vita e future evoluzioni) occorre pensare “a lungo termine”.
  • Verifica: anche se molte aziende hanno degli interi settori dedicati al testing e al controllo di qualità, il primo lavoro di testing deve partire dal programmatore stesso. I test possono essere di vario tipo: di unità, di integrazione, generativi, di accettazione ecc. e nessuno di questi andrebbe trascurato. La riuscita di un buon progetto dipende anche dall’esecuzione di tutti i i tipi di test sopra citati, senza esclusioni, sia automatici, sia manuali.
  • Scrittura del codice: ovviamente non può mancare, è una fase essenziale! Ma ormai credo che sia definitivamente superata la vecchia concezione degli sviluppatori pagati un “tot a riga di codice”. Non dimentichiamo che scrivere codice può anche voler dire aggiungere cattivo codice ad un progetto. Per questo motivo questa fase segue e dipende da tutte le precedenti!

Leggi anche l’articolo originale.

Facebook
LinkedIn
error: