Settimana intensa di formazione in smart working con uno switch fondamentale a livello IDE: IntelliJ IDEA!
Il mio tutor, Alessandro Rossignoli, sta puntando alto cercando di elevare considerevolmente il livello del mio codice (a prescindere dal linguaggio di programmazione), pertanto, come promesso, ha spinto sull’acceleratore su argomenti particolarmente “croccanti” che abbracciano la programmazione da molteplici angolazioni.
A livello di astrazione mi sono concentrato su tre argomenti specifici:
- Creational Design Patterns – ovvero stili rodati con cui creare le classi basi estendendo o implementandone altre. Oltre a fornire un modo universale per ricreare situazioni reali, permette anche una gestione logica e scalabile delle classi risparmiando molte linee di codice e pensieri contorti per gestirle. Così, tra peculiarità e controindicazioni di Factory Method, Abstract Factory, Singleton, Builder e Prototype, ho iniziato a vedere con un occhio diverso le classi astratte e le interfaccie che fino a ieri mi sembravanodi poca utilità.
- Progettazione e relazione tra gli oggetti – progettare sulla carta, e via software, esercizi su situazioni reali, è stato fondamentale per comprendere molti aspetti relazionali ed implementativi che mi erano sempre sfuggiti. Un po’ abituato ormai ad usare i database. Non mi ero mai reso conto che, senza di loro, avrei erroneamente scritto codice ridondante per avere i dati in memoria in modo coerente. Dando per scontate le relazioni di un database relazionale, in sua assenza avrei passato dati tra un metodo e l’altro con strategie assolutamente poco performanti senza usare strategie mirate e riutilizzo corretto delle classi e sue strutture dati.
- Strutture dati complesse – non ero nuovo a questo argomento, ma l’introduzione (dai miei tempi ovviamente) di concetti e strutture dati avanzate nell’OOP, mi ha aperto un mondo nuovo. Mappe, Generics, Linked List, e le grandi possibilità date da Stream unite alle Lambda Expressions, aprono porte incredibile alla semplificazione del codice ed implementazioni più sofisticate grazie a filtraggi mirati.
E dopo la teoria, ovviamente si passa alla pratica; ed è qui la vera novità, il passaggio da Spring Tool Suite a IntelliJ IDEA Community. Non posso dire che con STS abbia lavorato male, anzi Eclipse è sempre stato il mio tool preferito per Java, ma questo cambio di rotta mi ha sorpreso per l’efficienza di questo IDE gratuito sviluppato da JetBrains. Per quanto era semplice gestire un applicazione Spring nel primo, è indubbio che con qualsiasi altro framework o lavorando in modalità console, IntelliJ diventi uno strumento senza paragoni. Non è agevole magari partirci per un progetto in Spring a meno di avere la versione Ultimate che lo supporta appieno, ma configurato il progetto Maven con l’initializer online, la strada è subito in discesa, soprattutto nel caso di Boot che embedda direttamente anche tutta la parte Tomcat!
A livello codice ho simulato (prima su carta,) in precisi progetti strutturati con Java, due app virtuali: acquisto di un biglietto dei treni e negozio di comics/manga. Se il primo progetto è stato complesso a livello di prima implementazione, il secondo lo è stato a livello di testing.
Era previsto che avrei avuto più difficoltà sulla linea ferroviaria per tenere traccia senza un database di tutto, infatti nella fase finale abbiamo addirittura affrontato le linked list bidirezionali, un concetto che conoscevo con i puntatori, ma mai implementato in Java. Per poter usare al meglio anche tutte sue sfaccettature, sono passato per la prima volta da Java 8 a Java 11. Si è quindi aperto anche un capitolo importante per List, Set e l’override di Equals e hashCode al fine di implementarli ed usarli correttamente.
Per il negozio, memore degli errori e tricks del primo, sono partito molto meglio nello strutturare il codice, ma questa volta volta abbiamo aggiunto un altro grado di perfezione: il JUnit Test 5 sfruttando le librerie Jupiter. Ho sempre trascurato il testing strutturato, e finora ho sempre usato l’approccio sbagliato del test end-to-end, pertanto ho dovuto nuovamente ampliare i miei orizzonti per capire quale sia il giusto “code coverage“, che porti ad un codice il più possibile immune da bugs banali. Da un lato non è stato semplice capire immediatamente cosa e come andava implementato, soprattutto quale fosse la miglior chain di assert, dall’altro invece trovare il perchè il test fallisse e il bug che creava l’errore. E qui sicuramente IntelliJ mi ha dato una mano importante nella sua completezza di informazioni nel debug.
Domani affronterò il terzo esercizio che alza davvero tanto la posta: gestione di un’Università (sempre senza un database d’appoggio) , con tutti i tipi di lavoratori, studenti, corsi, dipartimenti, ecc … e chissà quali altre idee “croccanti” avrà questa settimana il mio tutor!! E se ce la faccio a terminarlo, probabilmente torneremo al vecchio progetto PLC ricco di insidie e API.