Convenzioni e standard

Le convenzioni e gli standard adottati per la realizzazione dei progetti � quella definita nei documenti Java Naming & Coding Conventions e Database Naming Conventions.

Tracciamento degli errori

E' buona norma avere una tracciatura degli errori uniforme e consistente su tutta l'applicazione ed a questo scopo � opportuno utilizzare la libreria Jakarta Commons Logging ed il toolkit Log4j che rendono disponibili una intera gamma di funzionalita' estremamente utili.

E' molto importante per� imparare ad utilizzare correttamente gli strumenti con cui si lavora e per quanto concerne il logging � fondamentale imparare ad utilizzare correttamente il livello di logging. Rimando ad un documento molto esauriente sull'argomento e con una serie di utili suggerimenti.

E' sempre consigliabile avere una tracciatura separata per le differenti applicazioni cos� da poter analizzare separatamente e con pi� semplicit� lo stato e le cause di errore dell'applicazione, specialmente in ambienti di produzione dove piu' applicazioni vengono eseguite contemporaneamente dallo stesso server.

Ottenere questa separazione � molto semplice ed � sufficiente modificare il file conf/log4j.xml quando si installa una nuova applicazione aggiungendo un appender ed una category come i seguenti.

<!-- MyApp appender -->
<appender name="MYAPP" class="org.jboss.logging.appender.DailyRollingFileAppender">
  <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/>
  <param name="File" value="${jboss.server.home.dir}/log/myapp.log"/>
  <param name="Append" value="true"/>
  <!-- Rollover at midnight each day -->
  <param name="DatePattern" value="'.'yyyy-MM-dd"/>
  <layout class="org.apache.log4j.PatternLayout">
    <!-- The default pattern: Date Priority [Category] Message\n -->
    <param name="ConversionPattern" value="%d %-5p [%c] %m%n"/>
  </layout>
</appender>

<!-- MyApp logger -->
<category name="net.smartlab.myapp-package">
  <priority value="INFO"/>
  <appender-ref ref="MYAPP"/>
  <appender-ref ref="SMTP"/>
</category>

Questa modifica, come molte altre, non richiede il riavvio dell'application server perch� abbia effetto.

In generale � anche consigliabile:

• l'attivazione della notifica dei messaggi pi� gravi attraverso posta elettronica;
• la variazione del comportamento del logger su file per evitare la perdita di messaggi al riavvio del server od alla variazione della configurazione di log;
• la notifica via SMS delle condizioni di blocco delle applicazioni pi� critiche; da realizzare
• la notifica via email dello stop o riavvio dell'application server, utile in ambiente di produzione;
• la notifica via istant messenger di eventuali fallimenti o condizioni critiche, come Yahoo o Jabber.
• la notifica via email del deploy/redeploy di applicazioni, utile per i server di produzione onde evitare aggiornamenti od installazioni maligne o non previste.

E' disponibile per il download un file di configurazione per JBoss 4.0.3 modificato per abilitare le caratteristiche appena elencate.

La domanda pi� ricorrente in merito al logging �: "Cosa � necessario tracciare e cosa invece � inutile tracciare?".

La risposta � molto semplice: se ritenete che una certa informazione possa essere utile per capire se l'applicazione sta funzionando correttamente o perch� non abbia funzionato a dovere allora e� utile tracciare, purch� venga fatto con il livello corretto.

Tenete sempre in considerazione che il logging porta via una fetta delle capacit� computazionali del vostro computer quindi esagerare � comunque controproducente, ma potrebbe salvarvi la vita quando si verifica un errore nell'ambiente di produzione e non potete entrare in debug per verificare che diavolo sta succedendo alla vostra applicazione!

Per ulteriori informazioni vi rimandiamo ai siti delle relative librerie dove � possibile trovare molta documentazione e tanti altri utili suggerimenti:

• Jakarta Commons Logging
• Log4j

Gestione delle eccezioni

La gestione corretta delle eccezioni � di fondamentale importanza per la riuscita di un progetto: le eccezioni sono lo strumento attraverso il quale � possibile gestire condizioni di lavoro impreviste per il vostro software!

Tra gli errori che si commettono nella gestione delle eccezioni questi sono quelli che si ripetono con maggiore frequenza o implicano la maggiore gravita' delle loro conseguenze:

• eccezioni create ad hoc mancano dei costruttori, in particolare quelli adibiti ad impostare l'eccezione causante impedendo un utilizzo decente della gestione delle eccezioni;
• una volta catturata un'eccezione ne viene lanciata un'altra senza indicare l'eccezione causa rendendo impossibile determinare la vera origine del problema e complicando le operazioni di debug;
• catturata un'eccezione viene effettuato il log e poi ne viene lanciata un'altra o addirittura la stessa rendendo quasi impossibile decifrare il file di log prodotto;
• un metodo dichiara in maniera generica di lanciare Exception quando dovrebbe dichiarare esattamente quali tipologie di eccezioni verranno rilanciate;
• nel blocco catch vengono catturate tutte le eccezioni dichiarando Exception e generalizzando in questo modo la gestione anche per quelle eccezioni che invece non dovrebbero essere gestite;
• catturata un'eccezione viene prodotto il log e restituito null anche quando tale valore di ritorno ha un significato indeterminato od impreciso;
• catturata un'eccezione viene silenziosamente ignorata ed impedendo in questo modo che qualcuno possa gestirla ad un altro livello.

Molti sono gli approfondimenti disponibili in rete, tra cui gli articoli disponibili su java.net.

Test unitari

L'importanza dei test unitari e l'enorme vantaggio che da questi deriva nel migliorare il rapporto qualita'/prezzo del ciclo di vita del software non sempre risulta evidente e molto spesso viene sottovalutato.

Ci limitiamo qu� a sottolineare i consigli, gi� di per s� impliciti nell'utilizzo del framework JUnit, ma che spesso vengono dimenticati da coloro che sviluppano i test unitari:

• le classi di test dovrebbero risiedere nello stesso package della classe da testare ma in una directory separata;
• le classi di test dovrebbero chiamarsi come la classe che testano pi� il suffisso Test;
• � inutile realizzare il test dei metodi getter e setter di un JavaBean a meno che questi non implichino della logica specifica;
• scrivendo il test bisogna tenere bene a mente che si sta testando una unit� di programmazione e non l'intera applicazione, quindi non bisogna pensare a come pi� metodi o entit� interagiscano fra di loro, ma solo se il singolo metodo o la singola entit� � funzionale a quanto dichiarato nella sua documentazione;
• sarebbe preferibile scrivere il test subito dopo la definizione della classe e prima della sua implementazione, questo � tanto pi� valido quando il team di sviluppo � costituito da una sola persona;
• lo sviluppo delle classi di test non dovrebbe essere svolto dalla stessa persona che ha sviluppato la classe da testare.

Poich� il test di applicazioni web che interagiscono con una base di dati attraverso un framework complesso come Hibernate non � semplice n� di immediata comprensione � stata realizzata una classe base da estendere che intende semplificare la scrittura dei casi di test per le classi di tipo Factory. Tale classe � presente nel framework SmartWeb nel package net.smartlab.web.test e fa uso di una estensione del framework JUnit per la preparazione della base dati all'esecuzione del test denominata DbUnit.