Arhitekti programske opreme so to enostavno ali tako verjamejo številni kodirniki in inženirji. Ugotovite, kako je v tem resnično videti vsakdanje delovno življenje arhitekta Celotno življenje Java intervju. Veteren za programiranje Java Bruce Brouwer razpravlja o svojem pristopu k nadgradnji starejših spletnih aplikacij Java na storitveno usmerjeno arhitekturo, o svojem hitro razvijajočem se orodju za spletni uporabniški vmesnik in zakaj na splošno raje dela z omejitvami Jave, kot pa se odloči za manj strog jezik JVM.
Kot mnogi razvijalci programske opreme sem tudi jaz vedno bil skeptičen do arhitektov. Zdi se, da prepogosto zahtevajo, kako bo delo kodiranja opravljeno, ne da bi morali živeti s posledicami. Jaz sem tip, ki je nekoč napisal članek z naslovom "Zakaj nisem arhitekt," in znano mi je bilo, da je rekel "Njegov najljubši IDE je MS Outlook."
Potem sem spoznal Brucea Brouwerja, arhitekta aplikacij pri Gordon Food Service (GFS), družinskem distributerju hrane s pisarnami v Michiganu. Ko sem spoznala Brucea, je globoko zašel v računalniški zaslon in gledal dejansko kodo. Njegova naloga je bila integrirati GFS-jev prevajalnik Compass, ki temelji na Rubyju, v zgradbo aplikacije z uporabo JRubyja in njegov pristop k delu se je zdel vse prej kot abstrakten. Bil sem navdušen.
Bruceovo delo pri GFS je, kot pravi, tako, da določi vizijo za prihodnje spletne aplikacije in svojo vizijo dokaže z dokazovalnimi aplikacijami. Običajno sodeluje z razvojnimi skupinami pri prvih nekaj izvedbah uvajanja. Najnovejše vprašanje, na katerem je Bruce delal, je bil na dan, ko smo se srečali, kako GFS mimo tradicionalnih spletnih aplikacij za zahteve / odzive premakniti v storitveno usmerjena čelna arhitektura (SOFEA), kjer se vsa predstavitvena logika obravnava v brskalniku in ne v strežniku.
Bruce je delil nekaj svojih idej, kako preseči klasične storitveno usmerjene arhitekture (SOA) v bolj paradigme, ki temeljijo na sporočilih. Te ideje morajo delovati na papirju, toda Bruce potrebuje odkup tehničnih skupin, da bi lahko deloval. Kot arhitekt nudi navodila za izvajanje v skupinah, tehnologijah in celo starih sistemih. Njegova perspektiva je fascinantna in se mi zdi vredna delitve.
Matt Heusser: Pogovorite se z mano o svoji karieri programerja in arhitekta. Kako se je vaša vloga skozi čas spreminjala? Kako ste pristopili k svoji vlogi mlajšega programerja kot srednjega programerja ali arhitekta danes?
Bruce Brouwer: Po fakulteti sem se preselil v prvo pravo službo. Skoraj od samega začetka sem pritiskal na meje. Prišlo je do tega dolgočasnega postopka posodabljanja sloja dostopa do podatkov te aplikacije. Vsi novi zaposleni so bili podvrženi bolečini pri delu v tem procesu. Po prvič sem se odločil, da jo avtomatiziram. Uprava je bila navdušena, zato so me prosili, naj jo zaženem za vse tabele v zbirki podatkov. Približno teden dni je bilo treba očistiti nered iz moje avtomatizacije, kar se je izkazalo za pokvarjen postopek.
Ko sem nadaljeval s svojo kariero, sem našel veliko več priložnosti za lažji razvoj. Z mano se je hitro povezal stavek: "Ena vrstica kode." Ves čas sem si prizadeval, da bi razvijalcem poenostavili stvari. S svojim delom nisem bil zares zadovoljen, dokler niste mogli narediti nečesa, kar je bilo prej zapleteno, zdaj pa preprosto kot ena vrstica kode.
Toda tako daleč lahko pridete samo z izdelavo boljših orodij. Moral sem začeti razmišljati v večjem obsegu. Ko začnete igrati v tem večjem svetu, morate spet premakniti meje. Mogoče baza podatkov SQL ni potrebna. Morda čakanje na odgovor te službe ni najboljša izraba časa. Mogoče Java tega ne reže več.
V redu, zadnja točka je nekoliko sporna, toda to vprašanje sem postavil. Toda preprosto postavljanje teh vprašanj ni resnično delo arhitekta. Tudi oblikovanje popolnoma briljantne arhitekture ni dovolj. Korak za korakom morate drugim pokazati, kako priti tja. Arhitekt mora biti utemeljen v resničnem svetu in se sooča s težavami, ki izhajajo iz tega, kar so zasnovali. To zahteva tako tehnične kot družbene napore.
Matt Heusser: S katerimi tehnologijami zdaj delate?
Bruce Brouwer: Nedolgo nazaj sem se odločil, da izpolnim svoj profil v LinkedInu in naštejem vse tehnologije, ki jih dejansko uporabljam. Med tem trudom sem izvedel, da ima LinkedIn mejo. Tega ne rečem, da bi se hvalil, mislim, da je to problem. Preveč stvari morate vedeti, da bi bili dober razvijalec v današnjem svetu. Bolje moramo omejiti seznam orodij, s katerimi opravljamo svoje delo.
V glavnem uporabljam Java in Spring. To, kar sem pred kratkim delal, je oblikovanje prihodnosti razvoja spletnih aplikacij na GFS. GFS razvija spletne aplikacije z uporabo Java EE že od časa, preden so obstajali okviri, kot sta Struts ali JSF. Zdaj obstaja nekaj novih idej, ki izzivajo te spletne okvire na strani strežnika, na primer SOFEA in odziven dizajn. Da, te ideje bi lahko vključili v trenutno infrastrukturo Struts 2, ki jo imamo, vendar je čas, da naredimo pravi odmor med uporabniškim vmesnikom in zadnjim delom. Tako se bomo bolje znali odzvati na hitrost sprememb v sloju spletnega uporabniškega vmesnika, ne da bi morali tako drastično spreminjati nivo storitve.
"Zdaj obstaja nekaj novih idej, ki nasprotujejo strežniškim spletnim ogrodjem, na primer SOFEA in odziven dizajn. Da, te ideje bi lahko vključili v trenutno infrastrukturo Struts 2, vendar je čas, da naredimo resnično prekinitev med uporabniškim vmesnikom in hrbtno stranjo konec. "
Za ta novi spletni uporabniški vmesnik imam skoraj popolnoma novo zbirko orodij: Angular in Twitter Bootstrap ter seveda jQuery. Sledim temu, da bi celoten uporabniški vmesnik zgradil iz statičnih virov. Noben uporabniški vmesnik se ne bo zanašal na strežnik, ki generira kakršno koli dinamično vsebino vmesnika. Delovati mora v navadnem spletnem strežniku Apache; ne PHP, ne Perl, nič.
Kar zadeva plast storitev, ima GFS ogromno zapuščino Java. In večinoma je pravzaprav kar dobro. GFS že leta zasleduje storitveno usmerjeno arhitekturo z uporabo Spring POJO. Storitve so jedro SOFEA-e. JSON je danes najboljši prenos podatkov, Spring MVC pa olajša razkritje teh POJO-jev prek JSON-a. SOFEA je torej resnično primeren za GFS.
Izziven del pa je bila ta vizija, da ta spletni uporabniški vmesnik postane resnično statičen. Če želite narediti dobro spletno aplikacijo, ki je hitra, potrebujete nekatera druga orodja. Za upravljanje CSS uporabljam Compass. Za JavaScript uporabljam prevajalnik Google Closure, ki ima izjemno funkcijo izvornih zemljevidov. Vključite še nekatere druge zahteve po uničevanju predpomnilnika in olajšanju njegovega razvoja in naenkrat potrebujete popolno rešitev za gradnjo za nekaj, kar na koncu postane le kup besedilnih datotek.
Obstaja nekaj impresivnih orodij, ki so začela odgovarjati na te izzive. Bil sem precej navdušen nad Gruntom in Yeomanom in celo predlagal GFS, da sem zapustil Mavena zaradi Yeomana; vsaj za spletni uporabniški vmesnik. Zdelo se mi je, da je Maven morda preveč predaleč za orodja, ki še niso stara niti eno leto. Tako sem začel izdelovati vtičnik Maven, da sem vse to potegnil skupaj. Obstajajo vtičniki Maven za upravljanje s kompasom in zaprtjem, vendar ne ponujajo popolne rešitve, ki bi lahko celo spremenila razvoj HTML-ja v primerjavi s produkcijo in nudila tudi funkcionalnost ponovnega nalaganja v živo. To je bila pravzaprav čudovita izkušnja s pisanjem tega vtičnika Maven, ki je seveda napisan v Javi.
Morda bom kmalu lahko prepričal vodstvo, da mi dovoli, da to vrnem odprtokodni skupnosti.
Matt Heusser: Kako dolgo ste že arhitekt? Na čem ste delali pred letom dni?
Bruce Brouwer: Arhitekt aplikacij sem že osem let. Ko sem se preselil v GFS, sem od starejšega programerja prešel k arhitektu.
Moj prejšnji velik projekt, pri katerem sem delal pred letom dni, je bil prehod na Google Apps. To je bila tudi zame prava učna izkušnja. Med prehodom sem si zamislil sinhronizacijo starega koledarja z Google Koledarjem. Za uresničitev sem uporabil Googlove API-je iz Jave skupaj s Spring Integration. Vsaj za nekaj časa. Po nekaj resnih napakah sem moral priznati, da se ni splačalo tvegati. Tako arhitekt kot razvijalec tega projekta mi je pomagal ohraniti realni svet v perspektivi.
"V pesku smo morali potegniti črto, kaj je in za kaj ni primerno uporabljati Googla pri integraciji z našimi obstoječimi sistemi. Težko je, če ste prisiljeni nekoliko popuščati to navdušenje."
Google prinaša povsem nov svet možnosti za GFS. Njegov vpliv začutimo šele v načinu oblikovanja naših sistemov. Imel sem že veliko pogovorov z ljudmi, ki želijo uporabljati Google, ker je to bleščeča nova igrača. V pesku smo morali narisati črto, kaj je in za kaj ni primerno uporabljati Google pri integraciji z našimi obstoječimi sistemi. Težko je, če ste prisiljeni ublažiti nekaj tega navdušenja.
Matt Heusser: Kot arhitekt ste dosegli raven, ki jo doseže le majhen odstotek programerjev. Ali imate nasvet za programerje, ki začnejo v svoji karieri?
Bruce Brouwer: Všeč mi je, ko novi programerji pripravijo idejo, da bi izzvali trenutno stanje. Običajno želijo za lažjo nalogo uporabiti kakšno novo orodje. Takrat jim lahko pomagam pogledati širšo sliko. Pogosto to pomeni opozarjanje na težave pri vnašanju tega orodja. Pogovor skozi težave včasih prisili novega programerja, da odpre oči za večja vprašanja.
Torej moj nasvet novemu programerju je, da nadaljuje z izzivanjem nekaterih idej. Poiščite starejšega programerja ali arhitekta, ki ga lahko uporabite kot mentorja, in izrazite svojo idejo. Verjetno se ideja ne bo uresničila, a z ugotovitvijo se boste veliko naučili zakaj motiš se, ne samo, da se motiš. Toda ne pozabite tudi, da starejši programerji in arhitekti lahko trpijo zaradi kratkovidnosti in boste morda našli idejo, ki bi jo bilo vredno zasledovati.
Matt Heusser: Kdo je vaša stranka? (Ali pa, če si sposodite vrstico od Bobsa v "Office Space": Kaj bi rekli, da počnete tukaj?)
Bruce Brouwer: V resnici ne podpiram nobene stranke v smislu, da bi bil neposreden poslovni fokus. Pravzaprav sem postavljen znotraj infrastrukturne strani IS, skupaj z upravljavci baz podatkov in skrbniki strežnikov. Preostali del IS se resnično osredotoča na določeno področje poslovanja. Mogoče se zdi nenavadno umestiti razvijalca Jave v infrastrukturo, vendar mi omogoča, da se osredotočim na vprašanja, ki imajo večji arhitekturni poudarek kot drugi. Medtem ko se drugi trudijo, da bi opredelili poslovne procese, se bolj osredotočam na tehnologijo, ki se uporablja za reševanje težav vseh ljudi na večkratno uporabo.
Ljudje me pogosto prosijo za pomoč pri drugih projektih; včasih za daljše časovno obdobje. To mi pomaga ostati v realnem svetu. Pomaga mi tudi pri širjenju novih idej po ostalih razvojnih skupinah. Ugotovil sem, da ko sem bil pozvan, naj igram vlogo arhitekta projekta, je bil moj vpliv omejen na mlajše razvijalce; pravzaprav mi je bilo bolj koristno sodelovati pri drugih projektih, ki že imajo arhitekta, ker lahko svoje ideje potisnem k tistim, ki so bolj vplivni v svojem delu organizacije.
Matt Heusser: Kako dolgo že programirate v Javi? Kako ste videli, kako se v teh letih spreminjata jezik in samo programiranje Java?
Bruce Brouwer: Jave res nisem jemal resno do Java 1.3. Torej, to bi bilo približno 13 let. Toda tudi takrat Java res ni postala veselje za razvoj, dokler 1.5 ni prišel z generičnimi zdravili. Obstaja toliko dobrih uporab generikov in zdi se, da jih večina ljudi ne uporablja zunaj okvira zbirk Java.
Takrat, ko sem začel z Javo, smo skoraj vse napisali sami. Sčasoma sem videl, kako je preostali svet sprejel Javo, zlasti v odprtokodni skupnosti. Ta eksplozija odprtokodne kode je najpomembnejša sprememba, ki sem jo doživel med svojo kariero v programiranju Java. To je nekaj, čemur do nedavnega res ni še noben jezik.
Matt Heusser: Pogovorite se o uporabi JRubyja na GFS. Kakšno je vaše mnenje o jezikih JVM; bi morali zdaj vsi postati programerji Clojure?
Bruce Brouwer: JRuby je bil v Gordonsu res sredstvo za dosego cilja. Compass je resnično premierna izvedba Sass-a in je napisano v Rubyju. Na JVM sem uporabljal tudi Rhino in Groovy. Videl sem, kako močni in sposobni so ti drugi jeziki, toda tudi Java.
Drugi jeziki, kot je Scala, in omenili ste Clojure, so v zadnjem času priljubljeni. Čeprav lahko v Scali naredite isto s približno polovico kode Java, verjamem, da je berljivost lahko hitrejša kot v Javi. Nekaj časa nazaj sem na prenosnem računalniku videl številne izvajalce z nalepkami, na katerih je pisalo: "Tipkanje ni ozko grlo." Popolnoma se strinjam. Razmislek o težavi in pojasnitev naslednjega tipa je pomembnejša od iskanja pametnih načinov za zmanjšanje števila vrstic kode, ki jo napišete. Ne razumite me narobe, vzdrževanje manj kode je boljše kot več kode, vendar mora biti jasno, kaj se dogaja.
