Polymorphic Rants

In questo articolo Ron Jeffries analizza l’impatto (spesso negativo) degli straordinari sulla produttività .

Tags: XP, Ron Jeffries, sustainable pace

In questo articolo Ron Jeffries analizza l’impatto (spesso negativo) degli straordinari sulla produttività .

Tags: XP, Ron Jeffries, sustainable pace

il 20 giugno a Londra si terrà il Java06UK RoadShow.

Qua il l’agenda della giornata.

Tags: Java06UK RoadShow, London

il 26, 27 e 28 Giugno si terrà tra Roma e Milano la Java Conference 2006

Speaker d’eccezione: James Gosling

Tags: Java Conference, Roma, Milano.

Da tempo cerco di evitare che qualsiasi field di un oggetto sia a null, o implementando il null pattern o aggiungendo delle constraint ai costruttori ed ai metodi in modo che non ci possano essere dei riferimenti a null in tutto il ciclo di vita di un oggetto. Questo rende il codice estremamente pulito, meno error prone e ti costringe a lavorare in in modalità “cervello enabled” ([TM] ), cioè devi sempre cercare di capire come e quando può servire una constraint.

Prendiamo questa classe:

class Person {
private String name;
public void Person (String name) {
this.name = name;
}
public void setName(String name) {
this.name = name;
}
}

La classe non ha alcuna constraint, nè nel costruttore ne tantomeno nell’accessor. Ora però, abbiamo bisogno di implementare il metdo equals:

public boolean equals(Object object) {
if (object == null || !(object instanceof Person) ) {
return false;
}
Person otherPerson = (Person) object;
if ( (object.name == null && otherPerson.name == null) || (object.name != null && object.name.equals(otherPerson.name) ) {
return true;
} else {
return false;
}

Terribile!!! La possibilità che name sia null costringe a testare due condizioni in più in equals!!! Se avessimo definito delle constraint su name per evitare che sia null, il controllo di uguaglianza sarebbe semplicemente stato:

public boolean equals(Object object) {
[...] return object.name.equals(otherPerson.name);
}

La ricetta della nonna quindi prevede:

• null pattern dove possibile (e sensato)
• constraint: testare i parametri del costruttore e dei metodi ed eventualmente lanciare una IllegalArgumentException se sono null
• istanziare tutti gli oggetti nel costruttore, non aspettare di farlo in qualche altro metodo

Tags: pattern, Java, good practices

Darren Hobbs ci spiega come può essere dura la vita di un oggetto in JavaLand…e poi qualcuno sostiene che gli accessor sono buon design!!

Tags: OOD

Uno degli aspetti più complessi nella transizione verso un team agile è la gestione della documentazione di progetto. Nell’ambito di un processo Waterfall l’analisi crea un volume di documentazione (spreadsheet, documenti di testo, diagrammi) piuttosto importante; questo volume di informazioni tende a crescere con un successivo livelllo di specifiche tecniche prima dell’inizio della fase di scrittura del codice delineando e definendo l’intero sistema. La documentazione prodotta risulta però spesso di scarsa utlità , causa magari una bassa qualità del codice sviluppato o, caso ancora più comune, perchè semplicemente tutto quanto è stato prodotto nella fase di documentazione up-front non è in grado di cogliere l’istantanea che realmente serve in futuro per capire le scelte tecniche e farle evolvere.

Le metodologie agili hanno sempre posto l’accento su questo fatto, sottolineando come l’elemento portante della documentazione deve essere il codice sorgente stesso: a supporto dei sorgenti bisogna essere in grado di scegliere di volta in volta i giusti strumenti (UML, testo tradizionale, Wiki…) per fotografare quel particolare parte del sistema.

In XP, il pair programming è uno degli strumenti di comunicazione usati dal team: lavorando sempre in coppie e ruotando i pair sulle storie, si crea un base di conoscenza comune sulle scelte di progetto, riducendo al minimo la necessità di documentazione informativa (quella che dovrebbe rispondere alla domanda : "cosa leggo per capire come funziona quel pezzo del sistema ?")

Tutti i membri hanno un’idea aggiornata su tutte le componenti del progetto ed hanno contribuito alle scelte di design, e quindi si è rimosso alla radice il problema di dover creare una base di conoscenza tradizionale comune.

 La necessità (o volontà ) di documentare le scelte con modelli tradizionali, sposta implitamente il processo verso Waterfall: la documentazione e le scelte che ne seguono (attenzione: già si è creata una pipeline !) vengono generalmente filtrare tramite review fino a raggiungere un documento che è considerato completo: solo a quel punto parte la codifica.

(analisi-documentazione formale dell’analisi-codifica…suona familiare…)

Per poter gestire la documentazione di progetto in modo veramente agile, e capire cosa è veramente necessario documentare ed in che modo, si vede come il pair programming è un tassello fondamentale: senza si ricade in una gestione waterfall delle informazioni con conseguente difficoltà di dimensionare adeguatamente la documentazione e l’incubo di mantenere aggiornata la mole di documenti che si evolve task dopo task.

Tags: agile, XP, Waterfall, agile documentation

Grazie ad un post su questo blog Ho deciso di provare Qumana, un publishing tool per blog.

Dateci un occhio, sembra veramente ben fatto.

Powered by Qumana

Durante il Daily Scrum di venerdì mattina, ho assistito a questa conversazione:

R: credo che la stima per questo task sia da correggere, abbiamo fatto alcuni workshop ma non ho ancora scritto una riga di codice.

G: beh…con i vari workshop abbiamo definito il design….ormai il più è fatto, devi solo implementare quello…

Sono rabbrividito, e sospetto che una goccia di sudore freddo mi sia scesa dalla fronte; ho come l’impressione che il caro vecchio design up-front sia vivo e vegeto nella mente dei membri del team.

La cosa mi spaventa, e non poco.

posizione aperta: Senior Software Engineer

domanda:

how would you convert an int in to a String ?

riposta:

int i = 5;

String s = (String)i;

il colloquio è finito qui.