Jso

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 sito originale.

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.

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.

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)

Leggi anche l’articolo originale.

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

final Properties vProps = new Properties() {
    private static final long serialVersionUID = 1127046528812232390L;
 
    @Override
    public Enumeration keys() {	// this is for key reordering...	
       final Vector vKeysEnum = new Vector();	
       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(...);

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…

Leggi anche gli articoli originali: 1 e 2