Programovanie

Celý život v Jave: Čo robí softvérový architekt v skutočnosti celý deň?

Softvéroví architekti to majú ľahké, alebo tak verí toľko programátorov a inžinierov. Zistite, ako v tomto vyzerá skutočný každodenný pracovný život architekta Celý život v prostredí Java rozhovor. Veterán v oblasti programovania v jazyku Java Bruce Brouwer pojednáva o svojom prístupe k upgradovaniu starších webových aplikácií Java na front-endovú architektúru orientovanú na služby, o jeho rýchlo sa rozvíjajúcom nástrojovom súbore webového používateľského rozhrania a o tom, prečo vo všeobecnosti uprednostňuje prácu s obmedzeniami Javy pred voľbou menej prísneho jazyka JVM.

Ako mnoho vývojárov softvéru, aj ja som bol vždy skeptický voči architektom. Zdá sa, že príliš často požadujú, ako bude prebiehať práca kódovania, bez toho, aby museli znášať následky. Som človek, ktorý kedysi napísal článok s názvom „Prečo nie som architekt“, a bolo o mne známe, že vtipkoval „Jeho obľúbeným IDE je MS Outlook.“

Potom som sa stretol s Bruceom Brouwerom, aplikačným architektom v spoločnosti Gordon Food Service (GFS), rodinnom distribútorovi potravín s kanceláriami v Michigane. Keď som stretol Brucea, bol hlboko v obrazovke svojho počítača a díval sa na skutočný kód. Jeho úlohou bolo integrovať kompilátor Compass založený na Ruby od GFS do zostavy aplikácie pomocou JRuby a jeho prístup k dielu sa zdal byť iba abstraktný. Zaujalo ma to.

Bruceovou úlohou v spoločnosti GFS je podľa neho nastaviť víziu budúcich webových aplikácií a demonštrovať svoju víziu pomocou aplikácií na overenie koncepcie. Spravidla pracuje s vývojovými tímami na prvých implementáciách zavedenia. Najvýznamnejšou otázkou, na ktorej Bruce pracoval, bolo to, ako v deň, keď sme sa stretli, presunúť GFS cez tradičné webové aplikácie typu žiadosť / odpoveď do front-endová architektúra zameraná na služby (SOFEA), kde sa celá prezentačná logika spracúva v prehliadači a nie na serveri.

Bruce sa podelil o niektoré zo svojich nápadov na prekonanie klasických architektúr orientovaných na služby (SOA) do paradigiem založených na viacerých správach. Tieto nápady musia fungovať na papieri, ale aby Bruce fungoval, potrebuje buy-in od technických tímov. Ako architekt poskytuje implementačné poradenstvo pre tímy, technológie a dokonca aj staršie systémy. Jeho je fascinujúca perspektíva a o ktorej som si myslel, že sa oplatí zdieľať.

Matt Heusser: Hovorte mi o svojej kariére programátora a architekta. Ako sa vaša rola časom zmenila? Ako ste sa dnes stavali k pozícii juniorského programátora v porovnaní s programátorom v strednej kariére alebo ako architekt?

Bruce Brouwer: Po vysokej škole som sa presťahoval do svojej prvej skutočnej práce. Takmer od samého začiatku som tlačil na hranice. Pri aktualizácii vrstvy prístupu k dátam tejto aplikácie prebehol tento namáhavý proces. Všetci títo noví pracovníci boli podrobení bolesti pri uskutočňovaní tohto procesu. Po prvýkrát som sa rozhodol automatizovať to. Na vedenie to urobilo dojem, a preto ma požiadali, aby som to spustil pre všetky tabuľky v databáze. Trvalo asi týždeň, kým som vyčistil neporiadok z mojej automatizácie, čo sa ukázalo ako pokazený proces.

Keď som pokračoval v kariére, našiel som oveľa viac príležitostí na uľahčenie vývoja vecí. Rýchlo sa ku mne pridružila fráza: „Jeden riadok kódu.“ Stále som tlačil do svojej práce, aby som vývojárom zjednodušoval veci. Nebol som skutočne spokojný s mojou prácou, kým ste nedokázali niečo, čo bolo predtým komplikované, ale teraz to bolo také jednoduché ako jeden riadok kódu.

Môžete však ísť iba tak ďaleko, že budete mať k dispozícii lepšie nástroje. Musel som začať uvažovať vo väčšom meradle. Keď začnete hrať v tomto väčšom svete, musíte opäť posúvať hranice. Možno nie je potrebná databáza SQL. Možno čakanie na odpoveď od tejto služby nie je najlepším využitím času. Možno to už Java neprestrihuje.

Dobre, posledný bod je trochu diskutabilný, ale je to otázka, ktorú som položil. Jednoduché kladenie týchto otázok však nie je skutočnou prácou architekta. Nestačí ani návrh absolútne brilantnej architektúry. Musíte byť schopní krok po kroku ukázať ostatným, ako sa tam dostať. Architekt musí byť založený na skutočnom svete a musí sa stretnúť s problémami, ktoré vyplývajú z jeho návrhu. Vyžaduje si to technické aj spoločenské úsilie.

Matt Heusser: S akými technológiami teraz pracujete?

Bruce Brouwer: Nie je to tak dávno, čo som sa rozhodol vyplniť svoj profil na LinkedIn a uviesť zoznam všetkých technológií, ktoré skutočne používam. Počas tohto úsilia som sa dozvedel, že LinkedIn má svoj limit. Nehovorím to preto, aby som sa chválil, myslím si, že to je problém. Existuje iba príliš veľa vecí, ktoré potrebujete vedieť, aby ste boli v dnešnom svete dobrým vývojárom. Musíme lepšie zvládnuť obmedzenie zoznamu nástrojov, ktoré používame na vykonávanie svojej práce.

Väčšinou používam Java a Spring. Na čom som nedávno pracoval, je navrhovanie budúcnosti vývoja webových aplikácií v GFS. GFS vyvíja webové aplikácie pomocou Java EE ešte z čias, keď existovali rámce ako Struts alebo JSF. Teraz sú tu niektoré nové nápady, ktoré napádajú tieto webové rámce na strane servera, napríklad SOFEA a responzívny dizajn. Áno, mohli by sme tieto nápady dotiahnuť do súčasnej infraštruktúry Struts 2, ktorú máme, ale je čas urobiť skutočný zlom medzi UI a zadným koncom. Týmto spôsobom budeme mať lepšiu pozíciu, aby sme mohli reagovať na tempo zmien vo vrstve webového používateľského rozhrania bez toho, aby sme museli robiť také drastické zmeny vo vrstve služieb.

„Teraz sú tu niektoré nové nápady, ktoré napádajú webové rámce na strane servera, ako je SOFEA a responzívny dizajn. Áno, mohli by sme tieto nápady zaviesť do súčasnej infraštruktúry Struts 2, ale je čas urobiť skutočný zlom medzi UI a chrbtom koniec."

Pre toto nové webové používateľské rozhranie mám takmer úplne novú sadu nástrojov: Angular a Twitter Bootstrap a samozrejme jQuery. Snažím sa vybudovať celé UI zo statických zdrojov. Žiadne z používateľských rozhraní sa nebude spoliehať na to, že server generuje akýkoľvek dynamický obsah používateľského rozhrania. Musí pracovať na obyčajnom webovom serveri Apache; žiadne PHP, žiadne Perl, nič.

Pokiaľ ide o vrstvu služieb, GFS má obrovské dedičstvo Java. A väčšinou je to vlastne celkom dobré. Spoločnosť GFS sa už roky usiluje o architektúru zameranú na služby a využíva jarné POJO. Služby sú jadrom SOFEA. JSON je v dnešnej dobe voľbou pre dátový prenos a Spring MVC uľahčuje vystavenie týchto POJO prostredníctvom JSON. Takže SOFEA je skutočne skutočne vhodný pre GFS.

Najnáročnejšou časťou však bola vízia vytvorenia tohto webového používateľského rozhrania skutočne staticky. Vytvorenie rýchlej dobrej webovej aplikácie si vyžaduje ďalšie nástroje. Na správu CSS používam Compass. Pre JavaScript používam kompilátor Google Closure, ktorý má úžasnú vlastnosť zdrojových máp. Zahoďte nejaké ďalšie požiadavky na vynechanie pamäte cache a uľahčenie jej vývoja. Zrazu potrebujete kompletné riešenie pre zostavenie niečoho, z čoho sa nakoniec stane iba kopa textových súborov.

Existuje niekoľko pôsobivých nástrojov, ktoré začali zodpovedať tieto výzvy. Grunt a Yeoman na mňa dosť zapôsobili a dokonca som urobil ihrisko pre GFS, aby som opustil Mavena pre Yeomana; aspoň pre webové používateľské rozhranie. Mal som dojem, že vykopanie Maven môže byť pre nástroje, ktoré ešte nie sú ani rok staré, príliš ďaleko. Začal som teda vyrábať doplnok Maven, aby som to všetko spojil. Na prácu s programami Compass a Closure existujú doplnky Maven, ktoré však neposkytujú úplné riešenie, ktoré by dokonca mohlo modifikovať vývoj HTML v porovnaní s produkciou, a tiež poskytuje funkciu opätovného načítania. Pri písaní tohto pluginu Maven, ktorý je samozrejme napísaný v jazyku Java, to bola skutočne skvelá skúsenosť.

Možno čoskoro dokážem presvedčiť vedenie, aby mi umožnilo vrátiť to komunite otvorených zdrojov.

Matt Heusser: Ako dlho ste architektom? Na čom ste pracovali pred rokom?

Bruce Brouwer: Som aplikačným architektom už osem rokov. Keď som prešiel na GFS, urobil som skok od vyššieho programátora k architektovi.

Môj predchádzajúci veľký projekt, na ktorom som pracoval pred rokom, bol prechod na Google Apps. Toto bola skutočná vzdelávacia skúsenosť aj pre mňa. Mal som tento skvelý nápad synchronizovať starší kalendár s Kalendárom Google počas prechodu. Na to, aby sa to všetko stalo, som použil Google API z Java spolu s Spring Integration. Aspoň na chvíľu. Po niekoľkých vážnych chybách som musel uznať, že to za to nestálo. Tým, že som architektom a vývojárom tohto projektu, mi pomohlo udržať skutočný svet v perspektíve.

„Museli sme nakresliť čiaru v piesku pre to, čo je a nie je vhodné používať pri integrácii s našimi existujúcimi systémami. Na to môže byť ťažké, keď ste nútení zmierniť niečo z tohto nadšenia.“

Google prináša GFS úplne nový svet možností. Jeho vplyv na spôsob, akým navrhujeme naše systémy, len začíname pociťovať. Už som mal veľa rozhovorov s ľuďmi, ktorí chcú používať Google, pretože je to nová lesklá hračka. Museli sme nakresliť čiaru v piesku pre to, čo je a nie je vhodné používať pri integrácii s našimi existujúcimi systémami. Môže to byť ťažké, keď ste nútení zmierniť niečo z toho nadšenia.

Matt Heusser: Ako architekt ste sa dostali na úroveň, ktorú dosahuje iba malé percento programátorov. Máte rady pre programátorov, ktorí začínajú svoju kariéru?

Bruce Brouwer: Som rád, keď noví programátori prichádzajú s nápadom spochybniť súčasný stav. Zvyčajne chcú na uľahčenie úlohy použiť nejaký nový nástroj. Keď sa to stane, môžem im pomôcť pozrieť sa na širší obraz. Často to znamená poukázať na problémy so zavedením tohto nástroja. Rozprávanie o problémoch niekedy nového programátora prinúti otvoriť oči pred väčšími problémami.

Moja rada pre nového programátora je teda ísť ďalej a napadnúť nejaké nápady. Nájdite seniorného programátora alebo architekta, ktorého môžete použiť ako mentora, a vyjadrite svoj nápad. Pravdepodobne tento nápad nevyjde, ale zistením sa dozviete veľa prečo mýliš sa, nielen to, že sa mýliš. Pamätajte však tiež na to, že starší programátori a architekti môžu trpieť krátkozrakosťou a možno by ste našli iba nápad, ktorý stojí za to pokračovať.

Matt Heusser: Kto je váš zákazník? (Alebo si požičať linku od Bobov v „Kancelárskych priestoroch“: Čo by ste povedali, že tu robíte?)

Bruce Brouwer: Nepodporujem priamo žiadneho zákazníka v tom zmysle, že by existovalo priame obchodné zameranie. Vlastne som umiestnený na strane infraštruktúry IS, spolu s administrátormi DBA a servermi. Zvyšok IS je skutočne zameraný tak, aby slúžil konkrétnej oblasti podnikania. Môže sa zdať čudné umiestniť vývojára Java do infraštruktúry, ale umožňuje mi to sústrediť sa na problémy, ktoré majú väčšie architektonické zameranie, ako by mohli mať ostatní. Zatiaľ čo sa ostatní snažia prepracovať definovanie obchodných procesov, viac sa sústredím na technológiu, ktorá sa používa na opakované použitie na riešenie problémov všetkých.

Ľudia ma často žiadajú o pomoc pri iných projektoch; niekedy aj na dlhšiu dobu. To mi pomáha zostať pri zemi v skutočnom svete. Pomáha mi tiež rozšíriť nové nápady do ostatných vývojových tímov. Zistil som, že keď ma požiadali o úlohu architekta projektu, môj vplyv bol obmedzený na mladých vývojárov; v skutočnosti bolo pre mňa užitočnejšie prispievať na ďalšie projekty, ktoré už majú architekta, pretože môžem svoje nápady presadiť u tých, ktorí majú vplyv na ich časť organizácie.

Matt Heusser: Ako dlho programuješ v Jave? Ako ste za tie roky videli zmenu jazyka a samotného programovania v Jave?

Bruce Brouwer: S Javou som sa vážne nebral až do Javy 1.3. To by teda bolo asi 13 rokov. Ale ani potom sa Java nestala skutočnou radosťou, kým sa vyvinula, až kým sa okolo 1.5 neobjavila generika. Existuje toľko dobrých využití generík a zdá sa, že väčšina ľudí ich nepoužíva nad rámec zbierok Java.

Keď som začínal s programom Java, písali sme si takmer všetko sami. Postupom času som videl, ako si zvyšok sveta osvojil Javu, najmä v komunite otvorených zdrojov. Explózia otvoreného zdroja je najdôležitejšou zmenou, ktorou som prešiel počas svojej kariéry v programovaní v Jave. Je to niečo, čo sa donedávna skutočne nezhodovalo so žiadnym iným jazykom.

Matt Heusser: Hovorte mi o používaní JRuby v GFS. Aký je váš názor na jazyky JVM; mali by sme sa teraz všetci stať programátormi Clojure?

Bruce Brouwer: JRuby bol v skutočnosti prostriedkom na ukončenie Gordona. Compass je skutočne premiérovou implementáciou systému Sass a je napísaný v Ruby. Na JVM som tiež použil Rhino a Groovy. Videl som, aké výkonné a schopné sú tieto ďalšie jazyky, ale takisto aj Java.

V poslednej dobe si získali obľubu aj iné jazyky, ako napríklad Scala, a spomenuli ste Clojure. Aj keď v Scale môžete robiť to isté s niečím ako polovicou kódu Java, verím, že čitateľnosť môže trpieť rýchlejšie ako v Jave. Pred časom som videl niekoľko dodávateľov s nálepkami na svojom notebooku, na ktorých stálo „Písanie nie je prekážkou.“ Úplne súhlasím. Dôkladné premyslenie problému a objasnenie jeho situácie ďalšiemu človeku je dôležitejšie ako hľadanie šikovných spôsobov, ako znížiť počet riadkov kódu, ktoré napíšete. Nechápte ma zle, udržiavať menej kódu je lepšie ako viac kódu, ale musí byť jasné, o čo ide.

$config[zx-auto] not found$config[zx-overlay] not found