linee guida

  1. INDEROGABILE: rispetto delle interfacce.

    Se per qualche motivo non vi piace una interfaccia parlatene con analista e sviluppatore dell'altro lato. Se a questo punto c'e' qualche modifica aspettate che sia documentata prima di modificare l'interfaccia della vostra classe.
  2. PROPRIETA' DEL CODICE: il tempo e' poco e il codice da scrivere tanto. Se qualcuno finisce di scrivere la propria parte di codice in anticipo faccia un checkout del progetto e si metta a scriver il codice di qualcun altro (avvisandolo ovviamente).
  3. ROTAZIONE DEL CODICE: con regolarita' il codice da realizzare verra' assegnato ad altri. Cosi' tutti avranno un'idea di quello che viene fatto all'interno di ogni sottoparte.
  4. TEST: chi rompe un test lo aggiusta il prima possibile.
  5. TEST: a chiunque viene in mente un test su qualunque sottoparte del progetto, fa il checkout, lo aggiunge e poi fa il commit.
  6. TEST: prima il test poi il codice (prima si comincia a pensare in questi termini prima verra' vinto il panico da test).
  7. BACHI: chi li trova in qualunque fase dello sviluppo prima di correggerli aggiunge la entry su sourceforge in modo da assegnare al baco un codice univoco, scrive un test con codificato il codice del baco es: testBaco234324() e poi corregge il codice bacato.
  8. SVN: e' uno strumento nuovo per molti. il consiglio e' di sfruttarlo il piu' possibile. Sarebbe d'uopo far il commit solo di codice che compila. Se si ha paura di perdere il lavoro fatto allora si puo' far il commit di codice ancora in fieri
  9. SVN: non si deve aver paura di fare un commit, se qualcuno ha aggiornato qualcosa il server stesso lo segnalera'
  10. JAVADOC: va scritta! Prima di ogni funzione e' opportuno documentare le pre/post condizioni e gli invarianti. E' bene comunicare cosa sono i parametri e riportare il riferimento al documento di progetto.
  11. JAVADOC: lingua: l'inglese dovrebbe essere lo standard.
  12. COMUNICAZIONE: e' vitale, piu' si comunica meno si fatica
  13. COOPERAZIONE: chi pensa di non stare nei tempi lo comunica, appena se ne rende conto al project leader, e non cerca di far l'eroe salvo poi capitolare a mezzora dalla consegna.
  14. REFACTORING: sarebbe bene finire le proprie priorita' prima di mettersi a riscrivere. Arrivare il piu' presto possibile ad una soluzione anche se non e' quella ideale e' importante. Il processo da seguire e': keep it working, keep it simple, keep it fast
  15. RISORSE: chi trova tecnologie nuove o che ritiene utili allo sviluppo le segnala agli altri magari facendo un breve riassunto delle possibilita' che la risorsa offre.
  16. TEMPI: segnate il tempo in cui si lavora al progetto servira' per il business. Il tempo speso a scriver mail o comunicare online per questioni riguardante il progetto sono da annotare nel tempo che state dedicando al progetto.

Implementazione del sistema

Generics

Per aumentare la leggibilita' del codice e per ridurre il numero di cast espliciti si e' scelto di rinunciare alla compatibilita' all'indietro utilizzando i generics disponibili solo in Java versione 1.5. Sono stati usati in HumanDevicesController per realizzare l'elenco dei display connessi e poter poi sfruttare il pattern iterator ogni volta che avveniva la notifica di un nuovo valore da parte di countercontroller.

Factory nelle interfacce

Spesso programmando ci si domanda quale possa essere una realizzazione di una determinata interfaccia. Includere nelle interfacce una factory che restituisca una realizzazione concreta a seconda delle necessita' ci e' sembrato ordinato e vincente.

Costruttori e parametri di default

Si e' evitato il piu' possibile di realizzare costruttori con parametri in meno, nascondendo nell'implementazione un default. La linea seguita invece e' stata quella di esplicitare nell'interfaccia o nella classe i valori di default in modo che chiunque potesse utilizzarli.

Test a little, code a little

Il test prima dell'implementazione e' un buon modo di procedere spediti e sicuri. I test verdi infondono sicurezza. Quelli rossi segnalano immediatamente allo sviluppatore la presenza di un problema. Il debugging di un test e' decisamente piu' agevole di quello dell'applicazione completa poiche' sgrava del carico delle parti non interessate al problema. Spesso, solo abbozzando il codice delle chiamate nei test ci si rende conto che manca qualcosa o che qualcosa non va come dovrebbe.

SVN+CruiseControl o Maestro, che purtroppo al momento non si e' riusciti ad introdurre agevolerebbero di molto il lavoro di integrazione tra le parti e sgraverebbero dal pensiero di ricordarsi di eseguire i test gli sviluppatori. CruiseControl ad esempio, verifica periodicamente se non ci siano stati commit sul repository di recente ed esegue un ciclo completo di testing informando con una mail direttamente gli sviluppatori incaricati di realizzare la parte che non si comporta correttamente. Come valore aggiunto realizza un sito in cui sono presenti statistiche e risultati.