Programvarearkitekter har det enkelt, eller så mange kodere og ingeniører tror. Finn ut hvordan arkitektens daglige arbeidsliv virkelig ser ut i dette Fullt Java-liv intervju. Java-programmeringsveteren Bruce Brouwer diskuterer sin tilnærming til å oppgradere eldre Java-webapplikasjoner til en serviceorientert frontendarkitektur, hans raskt utviklende verktøy for nettverksgrensesnitt, og hvorfor han generelt foretrekker å jobbe med Java's begrensninger fremfor å velge et mindre strengt JVM-språk.
Som mange programvareutviklere har jeg alltid vært skeptisk til arkitekter. Altfor ofte ser det ut til at de stiller krav til hvordan arbeidet med kodingen skal gjøres uten å måtte leve med konsekvensene. Jeg er fyren som en gang skrev en artikkel kalt "Why I'm not an architect", og jeg har vært kjent for å si "Hans favoritt IDE er MS Outlook."
Så møtte jeg Bruce Brouwer, en applikasjonsarkitekt hos Gordon Food Service (GFS), en familieeid distributør med kontorer i Michigan. Da jeg møtte Bruce, var han dypt inne i dataskjermen og så på den faktiske koden. Hans oppgave var å integrere GFSs Ruby-baserte kompass kompilator i en applikasjonsbygging med JRuby, og hans tilnærming til arbeidet virket alt annet enn abstrakt. Jeg ble fascinert.
Bruces jobb i GFS, sier han, er å både sette visjonen for fremtidige webapplikasjoner og demonstrere sin visjon med proof-of-concept-applikasjoner. Han jobber vanligvis med utviklingsteam på de første implementeringene av en utrulling. Den nyeste saken Bruce jobbet med, den dagen vi møttes, var hvordan man flyttet GFS forbi tradisjonelle forespørsels- / respons-webapplikasjoner til en serviceorientert frontend-arkitektur (SOFEA), der all presentasjonslogikken håndteres i nettleseren i stedet for på serveren.
Bruce delte noen av ideene sine for å presse utover klassiske serviceorienterte arkitekturer (SOA) til mer meldingsbaserte paradigmer. Disse ideene må fungere på papir, men Bruce trenger innkjøp fra tekniske team for å få dem til å fungere. Som arkitekt gir han implementeringsveiledning på tvers av team, teknologier og til og med eldre systemer. Hans er et fascinerende perspektiv, og et jeg syntes det var verdt å dele.
Matt Heusser: Snakk med meg om karrieren din som programmerer og arkitekt. Hvordan har rollen din endret seg over tid? Hvordan nærmet du deg rollen din som juniorprogrammør versus som midtkarriere eller som arkitekt i dag?
Bruce Brouwer: Etter college flyttet jeg inn i min første virkelige jobb. Helt fra begynnelsen presset jeg på grensene. Det var denne kjedelige prosessen med å oppdatere datatilgangslaget til dette programmet. Alle nyansatte ble utsatt for smerten ved å jobbe den prosessen. Etter første gang bestemte jeg meg for å automatisere det. Ledelsen var imponert, så de ba meg om å kjøre den for alle tabellene i databasen. Det tok omtrent en uke å rydde opp i rotet etter at jeg automatiserte det som viste seg å være en ødelagt prosess.
Da jeg fortsatte i karrieren, fant jeg mange flere muligheter for å gjøre ting lettere å utvikle. Et uttrykk ble raskt assosiert med meg: "En linje med kode." Jeg fortsatte å presse arbeidet mitt for å gjøre ting enklere for utviklere. Jeg var ikke virkelig fornøyd med arbeidet mitt før du kunne gjøre noe som tidligere var komplisert, men som nå var så enkelt som en kodelinje.
Men du kan bare gå så langt ved å lage bedre verktøy. Jeg måtte begynne å tenke i større skala. Når du begynner å spille i denne større verden, må du igjen skyve grensene. Kanskje en SQL-database ikke er nødvendig. Kanskje det ikke er best å bruke tid på å vente på svar fra den tjenesten. Kanskje Java ikke kutter det lenger.
Ok, det siste punktet er litt omstridt, men det er et spørsmål jeg har stilt. Men det å bare stille disse spørsmålene er ikke den virkelige jobben til en arkitekt. Selv å designe en helt strålende arkitektur er ikke nok. Du må kunne vise andre hvordan du kommer dit, trinn for trinn. En arkitekt må være jordet i den virkelige verden og oppleve problemene som kommer fra det de har designet. Dette krever både teknisk og sosial innsats.
Matt Heusser: Hvilke teknologier jobber du med nå?
Bruce Brouwer: For ikke lenge siden bestemte jeg meg for å fylle ut LinkedIn-profilen min, med en liste over alle teknologiene jeg faktisk bruker. Under den innsatsen lærte jeg at LinkedIn har en grense. Jeg sier ikke det for å skryte, jeg tror det er et problem. Det er bare for mange ting du trenger å vite for å være en god utvikler i dagens verden. Vi må gjøre det bedre å begrense listen over verktøy som vi bruker for å gjøre jobben vår.
I stor grad, det jeg bruker er Java og Spring. Det jeg nylig har jobbet med er å designe fremtiden for utvikling av webapplikasjoner hos GFS. GFS har utviklet webapplikasjoner ved bruk av Java EE fra tiden før det var rammer som Struts eller JSF. Nå er det noen nye ideer som utfordrer disse web-rammene på serversiden, som SOFEA og responsiv design. Ja, vi kan lage disse ideene i den nåværende Struts 2-infrastrukturen som vi har, men det er på tide å gjøre en virkelig pause mellom brukergrensesnittet og bakenden. På denne måten vil vi være bedre posisjonert til å svare på endringstakten i nettets UI-lag uten å måtte gjøre så drastiske endringer i tjenestelaget.
"Nå er det noen nye ideer som utfordrer websidene på server-siden, som SOFEA og responsiv design. Ja, vi kan skohorn disse ideene i den nåværende Struts 2-infrastrukturen, men det er på tide å gjøre en virkelig pause mellom brukergrensesnittet og baksiden slutt."
For dette nye nettgrensesnittet har jeg nesten en helt ny verktøypakke: Angular og Twitter Bootstrap, og selvfølgelig jQuery. Det jeg forfølger er å bygge hele brukergrensesnittet fra statiske ressurser. Ingen av brukergrensesnittet vil stole på at serveren genererer noe dynamisk brukergrensesnittinnhold. Det må fungere i en vanlig Apache Web Server; ingen PHP, ingen Perl, ingenting.
Når det gjelder tjenestelaget, har GFS en enorm Java-arv. Og for det meste er det faktisk ganske bra. GFS har forfulgt en serviceorientert arkitektur i årevis ved å bruke Spring POJOs. Tjenester er kjernen i SOFEA. JSON er den valgte datatransporten i disse dager, og Spring MVC gjør det enkelt å eksponere disse POJOene via JSON. Så SOFEA passer faktisk veldig bra for GFS.
Den utfordrende delen har imidlertid vært visjonen om å gjøre nettgrensesnittet virkelig statisk. For å lage en god webapp som er rask krever noen andre verktøy. Jeg bruker Compass for å administrere CSS. For JavaScript bruker jeg Google Closure-kompilatoren, som har den fantastiske funksjonen til kildekart. Kast inn noen andre krav til hurtigbuffering og gjør det enkelt å utvikle, og plutselig trenger du en komplett løsning for noe som ender opp med å bli bare en haug med tekstfiler.
Det er noen imponerende verktøy som har begynt å svare på disse utfordringene. Jeg har vært ganske imponert over Grunt og Yeoman, og jeg har til og med kommet til GFS for å forlate Maven for Yeoman; i det minste for nettgrensesnittet. Jeg fikk inntrykk av at grøfting av Maven kan være litt for langt for verktøy som ikke en gang er ett år. Så jeg begynte å lage et Maven-plugin for å trekke dette sammen. Det er Maven-plugins for å håndtere kompass og lukking, men de gir ikke en komplett løsning som til og med kan modifisere HTML-utviklingen i forhold til produksjon og også gi funksjoner for live-omlasting. Dette har faktisk vært en fantastisk opplevelse å skrive dette Maven-pluginet, som selvfølgelig er skrevet på Java.
Kanskje snart vil jeg være i stand til å overbevise ledelsen om å tillate meg å gi dette tilbake til open source-fellesskapet.
Matt Heusser: Hvor lenge har du vært arkitekt? Hva jobbet du med for ett år siden?
Bruce Brouwer: Jeg har vært søknadsarkitekt i åtte år nå. Jeg hoppet fra senior programmerer til arkitekt da jeg flyttet til GFS.
Mitt forrige store prosjekt, som jeg jobbet med for et år siden, var overgangen til Google Apps. Dette var en skikkelig lærerfaring for meg også. Jeg hadde denne store ideen om å synkronisere den eldre kalenderen med Google Kalender under overgangen. Jeg brukte Google API-er fra Java sammen med Spring Integration for å få det til å skje. I det minste en stund. Etter noen alvorlige feil måtte jeg innrømme at det ikke var verdt risikoen. Å være både arkitekt og utvikler på det prosjektet hjalp meg med å holde den virkelige verden i perspektiv.
"Vi har måttet tegne en linje i sanden for hva som er og ikke er hensiktsmessig å bruke Google til når vi integrerer med våre eksisterende systemer. Det kan være vanskelig når du blir tvunget til å temperere noe av den entusiasmen."
Google bringer en helt ny verden av muligheter til GFS. Vi begynner bare å føle dens innvirkning på måten vi designer systemene våre på. Jeg har allerede hatt mange samtaler med folk som vil bruke Google fordi det er det skinnende nye leketøyet. Vi har måttet tegne en linje i sanden for hva som er og ikke er hensiktsmessig å bruke Google til når vi integrerer med våre eksisterende systemer. Det kan være vanskelig når du blir tvunget til å temperere noe av den entusiasmen.
Matt Heusser: Som arkitekt har du nådd et nivå som bare en liten prosentandel av programmererne oppnår. Har du råd til programmerere som starter i karrieren?
Bruce Brouwer: Jeg elsker det når nye programmerere kommer med en idé om å utfordre den nåværende status quo. Vanligvis vil de bruke noe nytt verktøy for å gjøre en oppgave enklere. Det er når dette skjer at jeg kan hjelpe dem med å se på det større bildet. Ofte betyr det å peke på problemene med å få inn verktøyet. Å snakke gjennom problemene tvinger noen ganger den nye programmereren til å åpne øynene for større problemer.
Så mitt råd er til en ny programmerer er å gå videre og utfordre noen ideer. Finn en senior programmerer eller arkitekt som du kan bruke som en mentor og gi uttrykk for ideen din. Sannsynligvis vil ikke ideen slå ut, men du vil lære mye ved å finne ut av det Hvorfor du tar feil, ikke bare at du tar feil. Men husk også at eldre programmerere og arkitekter kan lide av nærsynthet, og du kan bare finne en ide det er verdt å forfølge.
Matt Heusser: Hvem er kunden din? (Eller å låne en linje fra Bobs i "Office Space": Hva vil du si du gjør her?)
Bruce Brouwer: Jeg støtter egentlig ikke noen kunder direkte i den forstand at det ville være et direkte forretningsfokus. Jeg er faktisk plassert innenfor infrastruktursiden av IS, sammen med DBAer og serveradministratorer. Resten av IS har virkelig fokus på å betjene et bestemt område av virksomheten. Det kan virke rart å plassere en Java-utvikler i infrastruktur, men det lar meg fokusere på problemer som har større arkitektonisk fokus enn andre måtte ha. Mens andre prøver å jobbe gjennom å definere forretningsprosesser, får jeg fokusere mer på teknologien som brukes til å løse alles problemer på en gjenbrukbar måte.
Folk ber meg ofte om å hjelpe andre prosjekter; noen ganger i lengre perioder. Dette hjelper meg å holde meg jordet i den virkelige verden. Det hjelper meg også å spre nye ideer gjennom resten av utviklingsteamene. Jeg har funnet ut at da jeg ble bedt om å spille rollen som prosjektets arkitekt, var min innflytelse begrenset til flere juniorutviklere. Det har faktisk vært mer nyttig for meg å bidra med andre prosjekter som allerede har en arkitekt, fordi jeg kan presse ideene mine med de som er mer innflytelsesrike i sin del av organisasjonen.
Matt Heusser: Hvor lenge har du programmert i Java? Hvordan har du sett språket og Java-programmeringen endres i løpet av disse årene?
Bruce Brouwer: Jeg tok egentlig ikke Java seriøst før Java 1.3. Så det ville være omtrent 13 år. Men selv da ble ikke Java virkelig en fryd å utvikle seg i før 1,5 kom med generiske legemidler. Det er så mange gode bruksområder for generiske stoffer, og de fleste ser ikke ut til å bruke dem utover rammene for Java-samlinger.
Da jeg begynte med Java, skrev vi nesten alt selv. Over tid har jeg sett hvordan resten av verden har omfavnet Java, spesielt i open source-fellesskapet. Den eksplosjonen av åpen kildekode er den viktigste endringen jeg har vært igjennom i løpet av min karriere innen Java-programmering. Det er noe som egentlig ikke har blitt matchet av noe annet språk før nylig.
Matt Heusser: Snakk med meg om bruk av JRuby på GFS. Hva tar du med JVM-språk; skal vi alle bli Clojure-programmerere nå?
Bruce Brouwer: JRuby var virkelig et middel til et mål i Gordons. Kompass er virkelig premieren på Sass-implementeringen der ute, og det skjer tilfeldigvis i Ruby. Jeg har også brukt Rhino og Groovy også på JVM. Jeg har sett hvor kraftige og dyktige disse andre språkene er, men det er også Java.
Andre språk som Scala, og du nevnte Clojure, har fått popularitet i det siste. Mens du kan gjøre det samme i Scala med noe som halvparten av Java-koden, tror jeg at lesbarheten kan lide raskere enn den gjør i Java. For en stund tilbake så jeg en rekke entreprenører med klistremerker på den bærbare datamaskinen som sa "Å skrive er ikke flaskehalsen." Jeg er helt enig. Å tenke gjennom problemet og gjøre det klart for neste fyr er viktigere enn å finne smarte måter å redusere antall kodelinjer du skriver. Ikke misforstå, det er bedre å opprettholde mindre kode enn mer kode, men det må være klart hva som skjer.
