La vita completa di Java: cosa fa davvero un architetto di software tutto il giorno?

Per gli architetti del software è facile, o almeno così credono molti programmatori e ingegneri. Scopri com'è realmente la vita lavorativa quotidiana di un architetto in questa intervista completa sulla vita di Java . Il veterano della programmazione Java Bruce Brouwer discute il suo approccio all'aggiornamento delle applicazioni web Java legacy a un'architettura front-end orientata ai servizi, il suo toolkit dell'interfaccia utente web in rapida evoluzione e il motivo per cui generalmente preferisce lavorare con i vincoli di Java piuttosto che optare per un linguaggio JVM meno rigoroso.

Come molti sviluppatori di software, sono sempre stato scettico nei confronti degli architetti. Troppo spesso sembrano fare richieste su come verrà svolto il lavoro di codifica senza dover convivere con le conseguenze. Sono il ragazzo che una volta ha scritto un articolo intitolato "Perché non sono un architetto" e sono stato conosciuto per scherzare "Il suo IDE preferito è MS Outlook".

Poi ho incontrato Bruce Brouwer, un application architect presso Gordon Food Service (GFS), un distributore di prodotti alimentari a conduzione familiare con uffici nel Michigan. Quando ho incontrato Bruce, era nel profondo dello schermo del suo computer, guardando il codice reale. Il suo compito era integrare il compilatore Compass basato su Ruby di GFS in un'applicazione compilata utilizzando JRuby, e il suo approccio al lavoro sembrava tutt'altro che astratto. Ero incuriosito.

Il lavoro di Bruce in GFS, afferma, è sia impostare la visione per le future applicazioni web sia dimostrare la sua visione con applicazioni proof-of-concept. In genere lavora con i team di sviluppo sulle prime implementazioni di un roll out. Il problema all'avanguardia su cui Bruce stava lavorando, il giorno in cui ci siamo incontrati, era come spostare GFS oltre le tradizionali applicazioni web di richiesta / risposta in un'architettura front-end orientata ai servizi (SOFEA), in cui tutta la logica di presentazione è gestita nel browser piuttosto che sul server.

Bruce ha condiviso alcune delle sue idee per spingere oltre le classiche architetture orientate ai servizi (SOA) verso paradigmi più basati sui messaggi. Queste idee devono funzionare sulla carta, ma Bruce ha bisogno del consenso dei team tecnici per farle funzionare. In qualità di architetto, fornisce indicazioni per l'implementazione tra team, tecnologie e persino sistemi legacy. La sua è una prospettiva affascinante e ho pensato che valesse la pena condividere.

Matt Heusser : Parlami della tua carriera di programmatore e architetto. Come è cambiato il tuo ruolo nel tempo? Come ti sei avvicinato al tuo ruolo di programmatore junior rispetto a quello di programmatore a metà carriera o di architetto oggi?

Bruce Brouwer : Dopo il college sono passato al mio primo vero lavoro. Fin dall'inizio, mi sono spinto oltre i confini. Si è verificato questo noioso processo di aggiornamento del livello di accesso ai dati di questa applicazione. Tutti i nuovi assunti sono stati sottoposti al dolore di lavorare quel processo. Dopo la mia prima volta, ho deciso di automatizzarlo. La direzione è rimasta colpita, quindi mi hanno chiesto di eseguirla per tutte le tabelle del database. Ci è voluta circa una settimana per ripulire il casino dalla mia automatizzazione di quello che si è rivelato un processo non funzionante.

Continuando la mia carriera, ho trovato molte più opportunità per rendere le cose più facili da sviluppare. Una frase è stata rapidamente associata a me: "Una riga di codice". Ho continuato a spingere il mio lavoro per rendere le cose più semplici per gli sviluppatori. Non ero veramente soddisfatto del mio lavoro fino a quando non si poteva fare qualcosa che prima era complicato, ma ora era semplice come una riga di codice.

Ma puoi andare così lontano solo realizzando strumenti migliori. Ho dovuto iniziare a pensare su scala più grande. Quando inizi a giocare in questo mondo più grande, devi di nuovo spingere i confini. Forse un database SQL non è necessario. Forse aspettare una risposta da quel servizio non è il miglior uso del tempo. Forse Java non lo taglia più.

Va bene, l'ultimo punto è un po 'controverso, ma è una domanda che ho posto. Ma porre semplicemente queste domande non è il vero lavoro di un architetto. Anche progettare un'architettura assolutamente geniale non è sufficiente. Devi essere in grado di mostrare agli altri come arrivarci, passo dopo passo. Un architetto ha bisogno di essere radicato nel mondo reale, sperimentando i problemi che derivano da ciò che ha progettato. Ciò richiede uno sforzo sia tecnico che sociale.

Matt Heusser : Con quali tecnologie stai lavorando adesso?

Bruce Brouwer : Non molto tempo fa ho deciso di compilare il mio profilo LinkedIn, elencando tutte le tecnologie che effettivamente utilizzo. Durante questo sforzo, ho imparato che LinkedIn ha un limite. Non lo dico per vantarmi, penso che sia un problema. Ci sono troppe cose che devi sapere per essere un buon sviluppatore nel mondo di oggi. Dobbiamo fare di meglio nel limitare l'elenco degli strumenti che utilizziamo per svolgere il nostro lavoro.

In gran parte, quello che uso sono Java e Spring. Quello su cui ho lavorato di recente è progettare il futuro dello sviluppo di applicazioni web in GFS. GFS ha sviluppato applicazioni web utilizzando Java EE da prima che esistessero framework come Struts o JSF. Ora ci sono alcune nuove idee che mettono alla prova questi framework web lato server, come SOFEA e il responsive design. Sì, potremmo inserire queste idee nell'attuale infrastruttura di Struts 2 che abbiamo, ma è tempo di fare una vera rottura tra l'interfaccia utente e il back-end. In questo modo saremo in una posizione migliore per rispondere al ritmo del cambiamento nel livello dell'interfaccia utente web senza dover apportare modifiche così drastiche al livello del servizio.

"Ora ci sono alcune nuove idee che sfidano i framework web lato server, come SOFEA e il responsive design. Sì, potremmo inserire queste idee nell'attuale infrastruttura di Struts 2, ma è ora di fare una vera rottura tra l'interfaccia utente e il retro fine."

Per questa nuova interfaccia utente web, ho una suite di strumenti quasi completamente nuova: Angular e Twitter Bootstrap e, naturalmente, jQuery. Quello che sto perseguendo è costruire l'intera interfaccia utente da risorse statiche. Nessuno dell'interfaccia utente si baserà sul server che genera alcun contenuto dinamico dell'interfaccia utente. Deve funzionare in un semplice server Web Apache; niente PHP, niente Perl, niente.

Per quanto riguarda il livello di servizio, GFS ha un'enorme eredità Java. E per la maggior parte, in realtà è piuttosto buono. GFS ha perseguito per anni un'architettura orientata ai servizi, utilizzando i POJO Spring. I servizi sono al centro di SOFEA. JSON è il trasporto dati preferito in questi giorni e Spring MVC semplifica l'esposizione di questi POJO tramite JSON. Quindi SOFEA è davvero un'ottima soluzione per GFS.

La parte impegnativa, tuttavia, è stata quella visione di rendere quell'interfaccia utente web davvero statica. Per creare una buona web app veloce sono necessari altri strumenti. Sto usando Compass per la gestione dei CSS. Per JavaScript sto usando il compilatore Google Closure, che ha la fantastica funzionalità delle mappe sorgente. Aggiungi altri requisiti per il busting della cache e semplifica lo sviluppo e all'improvviso hai bisogno di una soluzione di compilazione completa per qualcosa che finisce per diventare solo un mucchio di file di testo.

Ci sono alcuni strumenti straordinari che hanno iniziato a rispondere a queste sfide. Sono rimasto piuttosto impressionato da Grunt e Yeoman e sono persino arrivato al GFS per abbandonare Maven per Yeoman; almeno per l'interfaccia utente web. Ho avuto l'impressione che abbandonare Maven potrebbe essere un po 'troppo lontano per strumenti che non hanno ancora nemmeno un anno. Così ho iniziato a creare un plugin Maven per mettere tutto insieme. Esistono plugin Maven per gestire Compass e Closure, ma non forniscono una soluzione completa che può persino modificare lo sviluppo HTML rispetto alla produzione e fornire anche funzionalità di ricarica dal vivo. È stata davvero un'esperienza meravigliosa scrivere questo plugin Maven, che ovviamente è scritto in Java.

Forse presto riuscirò a convincere il management a permettermi di restituirlo alla comunità open source.

Matt Heusser : Da quanto tempo fai l'architetto? A cosa stavi lavorando un anno fa?

Bruce Brouwer : Sono otto anni che sono un architetto di applicazioni. Sono passato da programmatore senior ad architetto quando sono passato a GFS.

Il mio precedente grande progetto, a cui stavo lavorando un anno fa, era il passaggio a Google Apps. Anche per me questa è stata una vera esperienza di apprendimento. Ho avuto questa grande idea di sincronizzare il calendario precedente con Google Calendar durante la transizione. Ho utilizzato le API di Google da Java insieme a Spring Integration per realizzare tutto ciò. Almeno per un po. Dopo alcuni gravi inconvenienti, ho dovuto ammettere che non valeva la pena rischiare. Essere sia l'architetto che lo sviluppatore di quel progetto mi ha aiutato a mantenere il mondo reale in prospettiva.

"Abbiamo dovuto tracciare una linea sulla sabbia per ciò che è e non è appropriato utilizzare Google per l'integrazione con i nostri sistemi esistenti. Può essere difficile quando sei costretto a mitigare un po 'di quell'entusiasmo".

Google offre un intero nuovo mondo di possibilità a GFS. Stiamo solo iniziando a sentire il suo impatto nel modo in cui progettiamo i nostri sistemi. Ho già avuto molte conversazioni con persone che vogliono usare Google perché è il nuovo giocattolo brillante. Abbiamo dovuto tracciare una linea sulla sabbia per ciò che è e non è appropriato utilizzare Google per l'integrazione con i nostri sistemi esistenti. Può essere difficile quando sei costretto a mitigare un po 'di quell'entusiasmo.

Matt Heusser : Come architetto, hai raggiunto un livello che solo una piccola percentuale di programmatori raggiunge. Hai consigli per i programmatori che iniziano la loro carriera?

Bruce Brouwer : Mi piace quando i nuovi programmatori hanno un'idea per sfidare l'attuale status quo. Di solito vogliono usare qualche nuovo strumento per rendere più facile un compito. È quando questo accade che posso aiutarli a guardare il quadro più ampio. Spesso ciò significa sottolineare i problemi con l'introduzione di quello strumento. Parlare dei problemi a volte costringe il nuovo programmatore ad aprire gli occhi su questioni più grandi.

Quindi il mio consiglio è che un nuovo programmatore vada avanti e sfidi alcune idee. Trova un programmatore o architetto senior che puoi usare come mentore e dai voce alla tua idea. Probabilmente l'idea non avrà successo, ma imparerai molto scoprendo perché ti sbagli, non solo perché ti sbagli. Ma ricorda anche che i programmatori e gli architetti senior possono soffrire di miopia e potresti trovare un'idea che vale la pena perseguire.

Matt Heusser : Chi è il tuo cliente? (Oppure, per prendere in prestito una battuta da Bob in "Office Space": cosa diresti di fare qui?)

Bruce Brouwer : In realtà non supporto direttamente nessun cliente, nel senso che ci sarebbe un focus diretto sul business. In realtà sono inserito nel lato infrastruttura di IS, insieme agli amministratori di database e agli amministratori del server. Il resto di IS ha davvero l'obiettivo di servire una particolare area del business. Potrebbe sembrare strano collocare uno sviluppatore Java nell'infrastruttura, ma mi consente di concentrarmi su questioni che hanno un focus architettonico più ampio rispetto ad altri. Mentre altri stanno cercando di lavorare attraverso la definizione dei processi aziendali, riesco a concentrarmi maggiormente sulla tecnologia utilizzata per risolvere i problemi di tutti in modo riutilizzabile.

Le persone spesso mi chiedono di assistere altri progetti; a volte per lunghi periodi di tempo. Questo mi aiuta a rimanere con i piedi per terra nel mondo reale. Mi aiuta anche a diffondere nuove idee nel resto dei team di sviluppo. Ho scoperto che quando mi è stato chiesto di interpretare la parte dell'architetto del progetto la mia influenza era limitata agli sviluppatori più giovani; in realtà è stato più utile per me contribuire ad altri progetti che hanno già un architetto, perché posso spingere le mie idee con coloro che sono più influenti nella loro parte dell'organizzazione.

Matt Heusser : Da quanto tempo programmi in Java? Come hai visto cambiare il linguaggio e la stessa programmazione Java in quegli anni?

Bruce Brouwer : Non ho preso davvero sul serio Java fino a Java 1.3. Quindi, sarebbero circa 13 anni. Ma anche allora, Java non è diventato davvero una gioia da sviluppare fino a quando 1.5 non è uscito con i generici. Ci sono così tanti buoni usi dei generici e la maggior parte delle persone non sembra utilizzarli al di fuori del framework delle raccolte Java.

Quando ho iniziato con Java, scrivevamo quasi tutto da soli. Nel tempo, ho visto come il resto del mondo ha abbracciato Java, soprattutto nella comunità open source. Questa esplosione di open source è il cambiamento più importante che ho vissuto durante la mia carriera nella programmazione Java. È qualcosa che in realtà non è stato eguagliato da nessun'altra lingua fino a poco tempo fa.

Matt Heusser : Parlami dell'utilizzo di JRuby in GFS. Qual è la tua opinione sui linguaggi JVM; dovremmo diventare tutti programmatori Clojure adesso?

Bruce Brouwer : JRuby era davvero un mezzo per raggiungere un fine alla Gordons. Compass è davvero la prima implementazione di Sass in circolazione e sembra essere scritta in Ruby. Ho anche usato Rhino e Groovy anche sulla JVM. Ho visto quanto siano potenti e capaci questi altri linguaggi, ma lo è anche Java.

Altre lingue come Scala, e tu hai citato Clojure, hanno guadagnato popolarità ultimamente. Sebbene tu possa fare la stessa cosa in Scala con qualcosa come la metà del codice di Java, credo che la leggibilità possa soffrire più rapidamente di quanto non faccia in Java. Qualche tempo fa, ho visto un certo numero di appaltatori con adesivi sul loro laptop che dicevano "La digitazione non è il collo di bottiglia". Sono completamente d'accordo. Pensare al problema e renderlo chiaro per il prossimo è più importante che trovare modi intelligenti per ridurre il numero di righe di codice che scrivi. Non fraintendetemi, mantenere meno codice è meglio di più codice, ma deve essere chiaro cosa sta succedendo.