Software arkitekter har det let, eller så mange kodere og ingeniører tror. Find ud af, hvordan arkitektens daglige arbejdsliv virkelig ser ud i dette Fuldt Java-liv interview. Java-programmeringsveteren Bruce Brouwer diskuterer sin tilgang til at opgradere ældre Java-webapplikationer til en serviceorienteret frontend-arkitektur, hans hurtigt udviklende web-UI-værktøjssæt, og hvorfor han generelt foretrækker at arbejde med Java's begrænsninger frem for at vælge et mindre stringent JVM-sprog.
Som mange softwareudviklere har jeg altid været skeptisk over for arkitekter. Alt for ofte ser de ud til at stille krav til, hvordan kodningsarbejdet skal udføres uden at skulle leve med konsekvenserne. Jeg er den fyr, der engang skrev en artikel kaldet "Hvorfor jeg ikke er arkitekt", og jeg har været kendt for at sige "Hans foretrukne IDE er MS Outlook."
Derefter mødte jeg Bruce Brouwer, en applikationsarkitekt hos Gordon Food Service (GFS), en familieejet maddistributør med kontorer i Michigan. Da jeg mødte Bruce, var han dybt inde i sin computerskærm og så på den faktiske kode. Hans opgave var at integrere GFSs Ruby-baserede kompas kompilator i en applikationsbygning ved hjælp af JRuby, og hans tilgang til arbejdet syntes alt andet end abstrakt. Jeg var fascineret.
Bruces job hos GFS, siger han, er at både sætte visionen for fremtidige webapplikationer og demonstrere sin vision med proof-of-concept applikationer. Han arbejder typisk med udviklingshold på de første par implementeringer af en udrulning. Det banebrydende spørgsmål, som Bruce arbejdede med, på den dag, vi mødtes, var, hvordan man flytter GFS forbi traditionelle anmodninger / svar-webapplikationer til en serviceorienteret frontend-arkitektur (SOFEA), hvor al præsentationslogik håndteres i browseren snarere end på serveren.
Bruce delte nogle af sine ideer til at skubbe ud over klassiske serviceorienterede arkitekturer (SOA) i mere beskedbaserede paradigmer. Disse ideer skal arbejde på papir, men Bruce har brug for buy-in fra de tekniske teams for at få dem til at fungere. Som arkitekt giver han implementeringsvejledning på tværs af teams, teknologier og endda ældre systemer. Hans er et fascinerende perspektiv, og et synspunkt, jeg synes var værd at dele.
Matt Heusser: Tal med mig om din karriere som programmør og arkitekt. Hvordan har din rolle ændret sig over tid? Hvordan tilnærmede du dig din rolle som junior-programmør versus som en midt-karriere-programmør eller som arkitekt i dag?
Bruce Brouwer: Efter college flyttede jeg til mit første rigtige job. Helt fra begyndelsen skubbede jeg på grænserne. Der var denne kedelige proces med at opdatere dataadgangslaget i denne applikation. Alle de nye ansættelser blev udsat for smerten ved at arbejde den proces. Efter min første gang besluttede jeg at automatisere det. Ledelsen var imponeret, så de bad mig køre den til alle tabeller i databasen. Det tog cirka en uge at rydde rodet fra min automatisering, hvad der viste sig at være en ødelagt proces.
Da jeg fortsatte i min karriere, fandt jeg mange flere muligheder for at gøre tingene lettere at udvikle. En sætning blev hurtigt forbundet med mig: "En linje kode." Jeg fortsatte med at skubbe på mit arbejde for at gøre tingene enklere for udviklere. Jeg var ikke virkelig tilfreds med mit arbejde, før du kunne gøre noget, der tidligere var kompliceret, men nu var så simpelt som en linje kode.
Men du kan kun gå så langt ved at lave bedre værktøjer. Jeg måtte begynde at tænke i større skala. Når du begynder at spille i denne større verden, skal du igen skubbe grænserne. Måske er en SQL-database ikke nødvendig. Måske er det ikke den bedste brug af tid at vente på svar fra denne tjeneste. Måske klipper Java det ikke længere.
Okay, det sidste punkt er lidt omstridt, men det er et spørgsmål, jeg har stillet. Men simpelthen at stille disse spørgsmål er ikke arkitektens egentlige job. Selv at designe en absolut strålende arkitektur er ikke nok. Du skal være i stand til at vise andre, hvordan man kommer der, trin for trin. En arkitekt skal have jordforbindelse i den virkelige verden og opleve de problemer, der kommer fra det, de har designet. Dette kræver både teknisk og social indsats.
Matt Heusser: Hvilke teknologier arbejder du med nu?
Bruce Brouwer: For ikke så længe siden besluttede jeg at udfylde min LinkedIn-profil med en liste over alle de teknologier, som jeg faktisk bruger. Under denne indsats lærte jeg, at LinkedIn har en grænse. Det siger jeg ikke for at prale, det synes jeg er et problem. Der er bare for mange ting, du har brug for at vide for at være en god udvikler i nutidens verden. Vi er nødt til at gøre det bedre med at begrænse listen over værktøjer, som vi bruger til at udføre vores job.
Stort set, hvad jeg bruger er Java og Spring. Det, jeg for nylig har arbejdet med, er at designe fremtiden for udvikling af webapplikationer hos GFS. GFS har udviklet webapplikationer ved hjælp af Java EE fra tiden før der var rammer som Struts eller JSF. Nu er der nogle nye ideer, der udfordrer disse webservere på serversiden, som SOFEA og responsivt design. Ja, vi kunne sko-horn disse ideer ind i den nuværende Struts 2-infrastruktur, som vi har, men det er på tide at gøre en reel pause mellem brugergrænsefladen og back-end. På denne måde vil vi være bedre positioneret til at reagere på tempoet i ændringer i web-UI-laget uden at skulle foretage så drastiske ændringer i servicelaget.
"Nu er der nogle nye ideer, der udfordrer serverrammer på websiden, som SOFEA og responsivt design. Ja, vi kunne skohorn disse ideer i den nuværende Struts 2-infrastruktur, men det er på tide at gøre en reel pause mellem brugergrænsefladen og bagsiden ende."
Til dette nye web-UI har jeg næsten en helt ny værktøjssuite: Angular og Twitter Bootstrap og selvfølgelig jQuery. Det jeg forfølger er at opbygge hele brugergrænsefladen fra statiske ressourcer. Ingen af brugergrænsefladen vil stole på, at serveren genererer noget dynamisk brugergrænsefladeindhold. Det skal arbejde i en almindelig Apache-webserver; ingen PHP, ingen Perl, intet.
Hvad angår servicelaget har GFS en enorm Java-arv. Og for det meste er det faktisk ret godt. GFS har forfulgt en serviceorienteret arkitektur i årevis ved hjælp af Spring POJO'er. Tjenester er kernen i SOFEA. JSON er den valgte datatransport i disse dage, og Spring MVC gør det let at udsætte disse POJO'er via JSON. Så SOFEA er faktisk en rigtig god pasform til GFS.
Den udfordrende del har dog været den vision om at gøre dette web-UI virkelig statisk. At lave en god webapp, der er hurtig, kræver nogle andre værktøjer. Jeg bruger Compass til styring af CSS. Til JavaScript bruger jeg Google Closure-kompilatoren, som har den fantastiske funktion af kildekort. Kast nogle andre krav til cache-afbrydelse og gør det let at udvikle, og pludselig har du brug for en komplet build-løsning til noget, der ender med at blive bare en flok tekstfiler.
Der er et par imponerende værktøjer, der er begyndt at løse disse udfordringer. Jeg har været temmelig imponeret over Grunt og Yeoman, og jeg kom endda til GFS for at opgive Maven for Yeoman; i det mindste til web-UI. Jeg fik indtryk af, at Maven måske var lidt for langt for værktøjer, der endnu ikke er et år gamle. Så jeg begyndte at lave et Maven-plugin for at trække det hele sammen. Der er Maven-plugins til håndtering af kompas og lukning, men de giver ikke en komplet løsning, der endda kan ændre HTML-udviklingen i forhold til produktion og også give live-genindlæsningsfunktionalitet. Dette har faktisk været en vidunderlig oplevelse af at skrive dette Maven-plugin, som selvfølgelig er skrevet i Java.
Måske kan jeg snart overbevise ledelsen om at give mig mulighed for at give dette tilbage til open source-samfundet.
Matt Heusser: Hvor længe har du været arkitekt? Hvad arbejdede du på for et år siden?
Bruce Brouwer: Jeg har været ansøgningsarkitekt i otte år nu. Jeg sprang fra senior programmør til arkitekt, da jeg flyttede til GFS.
Mit tidligere store projekt, som jeg arbejdede på for et år siden, var overgangen til Google Apps. Dette var også en rigtig læringsoplevelse for mig. Jeg havde denne store idé om at synkronisere den ældre kalender med Google Kalender under overgangen. Jeg brugte Google API'erne fra Java sammen med Spring Integration for at få det hele til at ske. I det mindste et stykke tid. Efter et par alvorlige fejl måtte jeg indrømme, at det ikke var risikoen værd. At være både arkitekt og udvikler på det projekt hjalp mig med at holde den virkelige verden i perspektiv.
"Vi har måttet tegne en linje i sandet for, hvad der er og ikke er hensigtsmæssigt at bruge Google til, når vi integrerer med vores eksisterende systemer. Det kan være svært, når du er tvunget til at temperere noget af den begejstring."
Google bringer en helt ny verden af muligheder til GFS. Vi begynder kun at mærke dens indflydelse i den måde, vi designer vores systemer på. Jeg har allerede haft masser af samtaler med folk, der ønsker at bruge Google, fordi det er det skinnende nye legetøj. Vi har måttet tegne en linje i sandet for, hvad der er og ikke er passende at bruge Google til, når vi integrerer med vores eksisterende systemer. Det kan være svært, når du er tvunget til at temperere noget af den begejstring.
Matt Heusser: Som arkitekt er du nået et niveau, som kun en lille procentdel af programmørerne opnår. Har du råd til programmører, der starter i deres karriere?
Bruce Brouwer: Jeg elsker det, når nye programmører kommer med en idé til at udfordre den nuværende status quo. Normalt vil de bruge noget nyt værktøj til at gøre en opgave lettere. Det er når dette sker, at jeg kan hjælpe dem med at se på det større billede. Ofte betyder det at påpege problemerne med at bringe værktøjet ind. At tale gennem problemerne tvinger undertiden den nye programmør til at åbne øjnene for større problemer.
Så mit råd er til en ny programmør at gå videre og udfordre nogle ideer. Find en senior programmør eller arkitekt, som du kan bruge som en mentor, og udtryk din idé. Sandsynligvis går ideen ikke ud, men du lærer meget ved at finde ud af det hvorfor du tager fejl, ikke bare at du tager fejl. Men husk også, at seniorprogrammerere og arkitekter kan lide af nærsynethed, og du kan måske bare finde en idé, der er værd at forfølge.
Matt Heusser: Hvem er din kunde? (Eller at låne en linje fra Bobs i "Office Space": Hvad vil du sige, du laver her?)
Bruce Brouwer: Jeg støtter ikke rigtig direkte nogen kunde i den forstand, at der ville være et direkte forretningsfokus. Jeg er faktisk placeret inden for infrastruktursiden af IS sammen med DBA'er og serveradministratorer. Resten af IS har virkelig fokus på at betjene et bestemt område af virksomheden. Det kan virke underligt at placere en Java-udvikler i infrastruktur, men det giver mig mulighed for at fokusere på emner, der har et større arkitektonisk fokus, end andre måske har. Mens andre prøver at arbejde igennem at definere forretningsprocesser, får jeg mere fokus på den teknologi, der bruges til at løse alles problemer på en genanvendelig måde.
Folk beder mig ofte om at hjælpe andre projekter; nogle gange i længere perioder. Dette hjælper mig med at blive jordforbundet i den virkelige verden. Det hjælper mig også med at sprede nye ideer i resten af udviklingsholdene. Jeg har fundet ud af, at da jeg blev bedt om at spille projektets arkitekt, var min indflydelse begrænset til flere juniorudviklere; Det har faktisk været mere nyttigt for mig at bidrage til andre projekter, der allerede har en arkitekt, fordi jeg kan skubbe mine ideer med dem, der er mere indflydelsesrige i deres del af organisationen.
Matt Heusser: Hvor længe har du programmeret i Java? Hvordan har du set selve sproget og Java-programmeringen ændre sig i disse år?
Bruce Brouwer: Jeg tog ikke rigtig Java alvorligt, før Java 1.3. Så det ville være omkring 13 år. Men selv da blev Java ikke rigtig en glæde at udvikle sig i, før 1.5 kom rundt med generiske lægemidler. Der er så mange gode anvendelser af generiske stoffer, og de fleste mennesker ser ikke ud til at bruge dem ud over rammerne for Java-samlinger.
Da jeg startede med Java, skrev vi næsten alt selv. Over tid har jeg set, hvordan resten af verden har omfavnet Java, især i open source-samfundet. Denne eksplosion af open source er den vigtigste ændring, som jeg har været igennem i løbet af min karriere inden for Java-programmering. Det er noget, der virkelig ikke er blevet matchet af noget andet sprog indtil for nylig.
Matt Heusser: Tal med mig om at bruge JRuby på GFS. Hvad tager du med JVM-sprog; skal vi alle blive Clojure-programmører nu?
Bruce Brouwer: JRuby var virkelig et middel til et mål i Gordons. Kompas er virkelig den premiere, Sass-implementering derude, og det sker tilfældigvis i Ruby. Jeg har også brugt Rhino og Groovy også på JVM. Jeg har set, hvor kraftfuld og dygtig disse andre sprog er, men det er Java også.
Andre sprog som Scala, og du nævnte Clojure, har vundet popularitet for nylig. Mens du kan gøre det samme i Scala med noget som halvdelen af Java-koden, tror jeg, at læsbarhed kan lide hurtigere, end det gør i Java. For et stykke tid tilbage så jeg et antal entreprenører med klistermærker på deres bærbare computer, der sagde "At skrive er ikke flaskehalsen." Jeg er helt enig. At tænke igennem problemet og gøre det klart for den næste fyr er vigtigere end at finde smarte måder at reducere antallet af kodelinjer, du skriver. Gør mig ikke forkert, vedligeholdelse af mindre kode er bedre end mere kode, men det skal være klart, hvad der foregår.
