Posts | Sviluppo Software

28/01/14

Manifesto for minimalist Software Engineers

Alcuni semplici concetti che un Software Engineer dovrebbe sempre ricordare:

  • Seguire la legge di Pareto, ovvero cercare di trovare la soluzione che consente di ottenere l’80% dei risultati con il 20% del lavoro
  • Dare priorità alle cose più importanti
  • Ricordare che “perfetto è nemico di ben fatto
  • Innovare: non aver paura di distruggere e ricostruire
  • Aggiungere valore al team di sviluppo
  • Sviluppare prima i concetti di base
  • Pensare “differente”, essere creativi nel semplificare
  • Sintetizzare, per comunicare meglio
  • Mantenere le cose semplici
  • Eliminare ciò che non si usa

Così, come riportato nel manifesto:

19/09/12

Signs that you’re a good (or bad) programmer

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 programmatore fantastico

  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

Per approfondimenti:

11/09/12

What do developers do all day?

Come programmatore sono rimasto positivamente colpito da quest’articolo. Quali sono le attività principali nella giornata di un programmatore 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!

Segue l’articolo originale:

15/03/12

Are you a Software Architect?

Come si può definire oggi un “Software Architect”? Il termine è molto utilizzato, ma spesso non viene inteso con la giusta connotazione e si tende a confondere il concetto di architettura del software con le tecniche di sviluppo del software a vari livelli.

Si può dire, in termini generali, che un Software Architect è colui che è in grado di avere una visione d’insieme del progetto e quindi capire (progettare, immaginare) il funzionamento dell’intero sistema.

Per essere un buon Software Architect occorre innanzitutto esperienza. Successivamente vengono evidenziati vari aspetti essenziali:

  • Definizione dell’architettura del software
    • Gestione dei requisiti non-funzionali (qualità del sistema)
    • Definizione dell’architettura (come risolvere il problema?)
    • Scelta delle tecnologie (gestione di rischi, complessità, costi)
    • Valutazione (astratta) dell’architettura
    • Capacità di interoperabilità dell’architettura (nei confronti di altri sistemi esistenti)
  • Realizzazione dell’architettura, occorrono:
    • Piena consapevolezza e visione del disegno finale (bisogna poter seguire tutto il ciclo di sviluppo per portare il progetto a compimento con successo)
    • Leadership (responsabilità, capacità decisionali e tecniche)
    • Coaching e mentoring (per supportare i vari membri coinvolti nello sviluppo)
    • Qualità (non solo nella scelta dell’architettura, ma in tutto il processo! Revisioni e analisi del codice, applicazione di standard e principi di design, continuous integration, test automatici di unità, misurazione del code coverage…)
    • Progettazione, sviluppo, testing (anche se non necessariamente nelle attività di tutti i giorni, il bravo Software Architect deve prendere parte al processo di sviluppo)

Per approfondimenti:

07/07/09

An ordered properties file

Mi è capitato di dover salvare un file di properties “ordinato” ovvero nel quale le chiavi fossero ordinate rispetto ad un certo criterio. Poichè la classe java.util.Properties estende java.util.Hashtable<Object, Object> normalmente le properties sono memorizzate senza alcun ordinamento specifico.
In qualche caso invece, se il file ottenuto è di grandi dimensioni, può essere utile disporre di un qualche tipo di ordinamento. La soluzione è abbastanza “tricky”, pertanto la pubblico.
La seguente classe rappresenta la chiave:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
/**
 * A key in the form Sn, where n is an integer number.
 *
 */
public class MessageKey implements Comparable {
 
    private Integer key;
 
    public MessageKey(final String pKey) {
        final String vKey = pKey.substring(1);
        try {
            key = Integer.valueOf(vKey);
        } catch (NumberFormatException vExc) {
            Logger.error(vExc);
        }
    }
 
    public Integer getId() {
        return key;
    }
 
    public int compareTo(final MessageKey pKey) {
        return key.compareTo(pKey.getId());
    }
 
    @Override
    public String toString() {
        return "S" + key;
    }
 
}

A questo punto occorre creare il nuovo oggetto Properties, facendo l’override del metodo keys() per ottenere, all’atto del salvataggio, il file ordinato. Il tutto senza ridefinire classi di sistema. Sono necessari alcuni passaggi per costruire una Enumeration ordinata (utilizzata nell’implementazione base della classe Properties), transitanto attraverso un Vector ed una List, riordinabile con il metodo standard Collections.sort(…). La soluzione risulta compatibile con Java5 e Java6.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
final Properties vProps = new Properties() {
    private static final long serialVersionUID = 1127046528812232390L;
 
    @Override
    public Enumeration<Object> keys() {
	// this is for key reordering...
	final Vector<MessageKey> vKeysEnum = new Vector<MessageKey>();
	for (Enumeration<Object> vEn = super.keys(); vEn.hasMoreElements();) {
	    vKeysEnum.add(new MessageKey((String) vEn.nextElement()));
	}
	final List<MessageKey> vKeysList = Collections.list(vKeysEnum.elements());
	Collections.sort(vKeysList);
 
	final Vector<Object> vOrderedKeys = new Vector<Object>();
	for (final MessageKey vKey : vKeysList) {
	    vOrderedKeys.add(vKey.toString());
	}
	return vOrderedKeys.elements();
    }
 
};
//...
vProps.setProperty("S" + vMsgKey.getId(), "something");
//...
vProps.store(...);
05/03/08

Agile Software Development…

Le Metodologie Agili stanno facendo molto parlare di sè. Recenti sondaggi dimostrano come la popolarita di queste metodologie (XP, Scrum, TDD) dal 2005 ad oggi sia costantemente in ascesa. Ma in quali contesti reali queste metodologie sono applicate con successo? Ovvero.. in quali contesti rappresentano un reale vantaggio (anche economico!) nello sviluppo? Secondo alcuni se il beneficio derivante dall’adozione di queste metodologie era decisamente “sottostimato” fino a qualche anno fa, ora probabilmente è addirittura “sovrasimato”.

E’ sicuramente vero che non si può certo pretendere di ridurre il tutto ad una semplice metodologia, impacchettarla, infiocchetterla ed inserirla in azienda sperando che tutto magicamente funzioni… la vera potenza di tutta la metodologia è il team, ovvero le persone che lo compongono. Ad oggi ci sono aziende che pretendono di essere agili, senza implementare l’essenza dell’approccio. Il consiglio è quello di essere “pratici” e di non accettare la metodologia come un credo religioso ma di utilizzarla sempre con spirito critico. Un esempio:

  • Status Meeting – un incontro mattutino ed una mail serale di riscontro
  • Short Iterations – mantenere i cicli di sviluppo semplici e brevi ed espandere secondo necessità
  • Continuous Integration – test JUnit automatici e altamente parallelizzati
  • Minimal Documentation – può bastare Javadoc…
  • Team Collaboration Tools – wiki e Jira tickets…
  • Strict Coding Guidelines – uniformità nello stile, naming, spacing…
  • Constant Code Reviews – controllare ogni riga di codice che va in produzione!
  • Pair Programming – scegliere oculatamente l’accostamento tra i 2 developers (rotazioni)
  • TDD – nella forma “pura” rischia di essere troppo oneroso, si può valutare un compromesso…

Per approfondimenti:

29/10/07

Open Sourcing a Saturday Project

Alcune interessanti riflessioni sulla tematica dell’open-source: quando un progetto realizzato nel tempo libero può diventare un progetto open-source da proporre alla comunità degli sviluppatori?

Geertjan Wielenga, sviluppatore del NetBeans Team, racconta la sua esperienza spiegando i passi che hanno portato il suo JFugue Music NotePad (un editor musicale scritto utilizzando la NetBeans Platform e JFugue API, una potente API per la gestione dei file midi) a diventare un progetto open-source.

In sintesi, secondo la sua opinione occorre:

  • disporre di un progetto che abbia raggiungo almeno un certo livello di coerenza (ovvero che possa attrarre l’interesse di altri sviluppatori)
  • rilasciare un prototipo, anche non completo, alla comunità
  • attendere che qualcuno si interessi al progetto (nel frattempo lo sviluppo da parte dell’autore non si arresta)
  • se qualcuno si interessa al progetto ed ha una conoscenza specifica del dominio maggiore di quella dell’autore diviene “contributor”
  • altri utenti sono semplici utilizzatori, “observers”
  • negli anni il progetto può evolvere raggiungendo buoni livelli, addirittura oltre le aspettative dell’autore stesso!

Ecco l’articolo completo: http://www.javalobby.org/articles/sat-open-source/

27/09/07

7 Top Tips for Quality Java Software

Alcuni accorgimenti che possono rendere un programmatore più efficiente nello scrivere un codice di migliore qualità. Poche regole semplici, ma a mio parere azzeccate:

  1. Eliminare il codice non utilizzato
  2. Non documentare codice complesso, piuttosto scrivere codice semplice
  3. Non scrivere tanti commenti, ma migliorare il log
  4. Applicare la legge di Demeter per mantere il codice semplice
  5. Non ripetersi (non duplicare codice)
  6. Marcare volutamente le porzioni di codice incomplete
  7. Controllare le assunzioni nel codice (rilevare subito il fallimento)

L’articolo completo si trova al seguente indirizzo: http://www.javalobby.org/java/forums/t101755.html

06/09/06

Lo sviluppatore software “moderno”

Chi ritiene la programmazione una pura fase di “manovalanza” all’interno di un progetto, è portato a ricredersi. L’utilizzo sistematico di pattern e l’evoluzione ciclica del design attraverso refactoring riportano lo sviluppatore, con la sua personalità ed esperienza al centro del progetto.

Sviluppo non significa solo scrivere codice. Sviluppo significa prendere decisioni concernenti il design. L’attività di sviluppo è qualcosa di creativo che richiede nel contempo grande disciplina. È un’attività di grande responsabilità che permette di progettare, creare, controllare e fare evolvere l’architettura e la funzionalità del progetto.

08/08/06

Testing the code…

To test or not to test, this is the question… o meglio, quanto tempo e quante risorse dedicare al testing automatico del software?

E’ vero, JUnit è un ottimo strumento per il test di unità, ma predisporre gli unit test richiede tempo (anche il 50% del tempo totale di programmazione) e non si può dimenticare che il test di integrazione e funzionale è ben altra cosa… c’è ancora bisogno dei tester manuali? Pare di sì…