Cosa abbiamo imparato? Sencha Test, Chain of Trust e refactoring

Ext JS e Sencha Studio – Carlo Mandelli

Dovendo testare un’applicazione web estesa bisogna chiedersi se esiste un modo per velocizzare l’esecuzione dei test end-to-end dell’interfaccia grafica.

L’esecuzione manuale dei test, oltre ad inserire una probabilità di errore umano dovuta alla continua ripetizione di operazioni identiche, comporta anche, qualora si volesse tenerne traccia, uno sforzo ulteriore per la compilazione di documenti.

Carlo Mandelli nel suo articolo introduce Sencha Studio e Sencha Test, due prodotti ideali appunto per  la realizzazione di test end-to-end per applicazioni Sencha.

Chain of Trust e SSL – Davide Ornaghi

Avrete sentito parlare almeno una volta di catene di certificati e autorizzazioni per servizi nel Web.

Che cosa vuol dire Chain of Trust?

Che cos’è una Certificate Authority?

Come funziona il meccanismo per recuperare questi certificati?

Esistono dei rischi nel quale si può incorrere?

Partendo da una simulazione di un microservizio Java, Davide ha indagato per dare risposta a tutte queste domande.

Se volete approfondire, potete leggere l’articolo specifico.

Refactoring – Fabio Manzi

E’ proprio vero.
Pay off migliore non potevamo avere.
LEARN / CODE / DEPLOY VALUE sintetizza ciò che quotidianamente svolgiamo. Ciò vale anche per Fabio il quale ha imparato e sta imparando moltissimo da quando è approdato in Intré.

Che cos’è il refactoring?

Con questo termine si intende una pratica che consente di raffinare il codice senza modificare o rivoluzionarne la funzionalità. Una tecnica che se usata correttamente permette di migliorare molto la qualità del codice, limitando la presenza di bug.
L’obiettivo del refactoring è quello di semplificare quello che si sta sviluppando.

Lo scenario tipico

In un contesto lavorativo capita spesso di iniziare a sviluppare una funzionalità con un determinato algoritmo che via via nel tempo viene inevitabilmente stravolto; il rischio è quello di scrivere una disastrosa quantità di codice.
Codice che avrà di sicuro un elevato rischio di bug e indubbiamente diventerà incomprensibile anche allo sviluppatore stesso che lo ha pensato, rendendo così ogni tipo di modifica estremamente difficoltosa, con la sensazione che prima o poi tutto cadrà in mille pezzi.

Come possiamo evitare che il castello crolli?

Per non arrivare a questo punto di rottura si possono adottare diversi accorgimenti:

• Sviluppare piccole funzionalità una alla volta.
• Raggiunto il seppur piccolo risultato, è il momento giusto per guardare il codice e cercare le parti migliorabili e fare quindi un po’ di refactoring.

Refactoring e Code smell

Durante il refactoring è buona norma avere dei test in modo da garantire che la modifica che si sta apportando sia corretta o stia andando a modificare la funzionalità, e quindi la correttezza dell’algoritmo generato.
Guardando il codice saltano all’occhio alcune “stranezze”:

• Il codice presenta delle ripetizioni; la soluzione potrebbe essere quella di estrarre il codice ripetuto magari in un metodo a parte.
• La presenza di commenti è sicuramente segno di poca comprensibilità del codice poiché non bisogna spiegare a parole ciò che si sta facendo bensì capire tutto senza incertezze direttamente leggendo il codice. Un possibile rimedio potrebbe essere rinominare una variabile o un metodo per renderlo più comprensibile.

Queste e molte altre brutte abitudini vengono classificate in una lista di errori classici. Un errore nel codice, una qualunque stranezza che può far storcere il naso di chi la osserva è chiamato code smell, letteralmente “puzza nel codice”.
Esistono pratiche da seguire o design pattern da applicare che permettono di riscrivere e risolvere questi problemi.

Adottando questi accorgimenti si sviluppa sicuramente codice semplice e di qualità.

Riferimenti

• Sencha Test
• Certificate Authority
• Refactoring – Martin Fowler
• Code Smell – Martin Fowler