Softwaroví architekti to mají snadné, nebo tomu věří tolik programátorů a techniků. Zjistěte, jak v tom vypadá každodenní pracovní život architekta Plný život v Javě rozhovor. Veterán programování v jazyce Java Bruce Brouwer pojednává o jeho přístupu k upgradu starších webových aplikací Java na front-endovou architekturu orientovanou na služby, o jeho rychle se rozvíjejícím nástroji webového uživatelského rozhraní a o tom, proč obecně upřednostňuje práci s omezeními Javy před zvolením méně přísného jazyka JVM.
Jako mnoho vývojářů softwaru jsem byl vždy skeptický vůči architektům. Zdá se, že příliš často požadují, jak bude práce s kódováním provedena, aniž by museli žít s důsledky. Jsem člověk, který kdysi napsal článek s názvem „Proč nejsem architekt,“ a bylo mi známo, že vtipkoval „Jeho oblíbeným IDE je MS Outlook.“
Pak jsem potkal Bruce Brouwera, aplikačního architekta ve společnosti Gordon Food Service (GFS), rodinného distributora potravin s kancelářemi v Michiganu. Když jsem potkal Bruce, byl hluboko ve své obrazovce počítače a díval se na skutečný kód. Jeho úkolem bylo integrovat kompilátor Compass založený na Ruby GFS do sestavení aplikace pomocí JRuby a jeho přístup k práci vypadal něco jiného než abstraktního. Zaujalo mě to.
Bruce pracuje v GFS, jak říká, je jak nastavit vizi budoucích webových aplikací, tak předvést svou vizi aplikacemi proof-of-concept. Obvykle pracuje s vývojovými týmy na prvních implementacích zavádění. Špičkovým problémem, na kterém Bruce pracoval, bylo v den, kdy jsme se setkali, jak přesunout GFS přes tradiční webové aplikace typu žádost / odpověď do front-endová architektura orientovaná na služby (SOFEA), kde se veškerá logika prezentace zpracovává spíše v prohlížeči než na serveru.
Bruce sdílel některé ze svých nápadů, jak prosadit klasické architektury orientované na služby (SOA) do více paradigmat založených na zprávách. Tyto nápady musí fungovat na papíře, ale Bruce potřebuje buy-in od technických týmů, aby fungovaly. Jako architekt poskytuje implementační vedení napříč týmy, technologiemi a dokonce i staršími systémy. Jeho je fascinující pohled, o kterém jsem si myslel, že stojí za sdílení.
Matt Heusser: Promluvte si se mnou o vaší kariéře programátora a architekta. Jak se vaše role v průběhu času změnila? Jak jste dnes přistupovali k roli mladšího programátora ve srovnání s programátorem v polovině kariéry nebo jako architekt?
Bruce Brouwer: Po vysoké škole jsem se přestěhoval do své první skutečné práce. Téměř od samého začátku jsem tlačil na hranice. Proběhl tento zdlouhavý proces aktualizace vrstvy přístupu k datům této aplikace. Všichni noví najatí byli vystaveni bolesti při provádění tohoto procesu. Po svém prvním spuštění jsem se rozhodl to zautomatizovat. Vedení na to udělalo dojem, a tak mě požádali, abych jej spustil pro všechny tabulky v databázi. Trvalo asi týden, než jsem vyčistil nepořádek z mé automatizace, což se ukázalo jako nefunkční proces.
Jak jsem pokračoval ve své kariéře, našel jsem mnoho dalších příležitostí, jak usnadnit vývoj věcí. Rychle se ke mně přidružila fráze: „Jeden řádek kódu.“ Stále jsem tlačil do práce, abych vývojářům usnadnil práci. Nebyl jsem opravdu spokojený se svou prací, dokud jste nedokázali něco, co bylo dříve komplikované, ale teď to bylo tak jednoduché jako jeden řádek kódu.
Ale můžete jít pouze tak daleko, že budete mít lepší nástroje. Musel jsem začít přemýšlet ve větším měřítku. Když začnete hrát v tomto větším světě, musíte znovu posunout hranice. Možná není nutná databáze SQL. Možná čekání na odpověď od této služby není nejlepším využitím času. Možná to Java už neřeže.
Dobře, ten poslední bod je trochu sporný, ale je to otázka, kterou jsem položil. Pouhé kladení těchto otázek však není skutečnou prací architekta. Dokonce ani navrhování naprosto brilantní architektury nestačí. Musíte být schopni ukázat ostatním, jak se tam dostat, krok za krokem. Architekt musí být zakotven v reálném světě a musí se setkat s problémy, které vyplývají z toho, co navrhli. To vyžaduje technické i sociální úsilí.
Matt Heusser: S jakými technologiemi nyní pracujete?
Bruce Brouwer: Není to tak dávno, co jsem se rozhodl vyplnit svůj profil na LinkedIn a uvést seznam všech technologií, které vlastně používám. Během tohoto úsilí jsem zjistil, že LinkedIn má limit. Neříkám to, abych se chlubil, myslím, že to je problém. Existuje jen příliš mnoho věcí, které potřebujete vědět, abyste byli v dnešním světě dobrým vývojářem. Musíme udělat lépe omezení seznamu nástrojů, které používáme k provádění své práce.
Většinou používám Java a Spring. Na čem jsem v poslední době pracoval, je navrhování budoucnosti vývoje webových aplikací v GFS. GFS vyvíjí webové aplikace pomocí Java EE od doby, kdy existovaly rámce jako Struts nebo JSF. Nyní existují některé nové nápady, které zpochybňují tyto webové rámce na straně serveru, jako je SOFEA a responzivní design. Ano, mohli bychom tyto myšlenky dotáhnout do současné infrastruktury Struts 2, kterou máme, ale je čas udělat skutečný zlom mezi UI a zadním koncem. Tímto způsobem budeme mít lepší pozici, abychom mohli reagovat na tempo změn ve vrstvě webového uživatelského rozhraní, aniž bychom museli provádět takové drastické změny ve vrstvě služeb.
„Nyní existují některé nové nápady, které zpochybňují webové rámce na straně serveru, jako je SOFEA a responzivní design. Ano, mohli bychom tyto nápady zavést do současné infrastruktury Struts 2, ale je čas udělat skutečný zlom mezi UI a zády konec."
Pro toto nové webové uživatelské rozhraní mám téměř úplně novou sadu nástrojů: Angular a Twitter Bootstrap a samozřejmě jQuery. Snažím se vybudovat celé uživatelské rozhraní ze statických prostředků. Žádné z uživatelských rozhraní se nebude spoléhat na to, že server generuje jakýkoli dynamický obsah uživatelského rozhraní. Musí pracovat na prostém webovém serveru Apache; žádné PHP, žádné Perl, nic.
Pokud jde o servisní vrstvu, GFS má obrovské dědictví Java. A většinou je to celkem dobré. GFS již léta sleduje architekturu orientovanou na služby a využívá Spring POJOs. Služby jsou jádrem SOFEA. JSON je v dnešní době volbou pro přenos dat a Spring MVC usnadňuje vystavení těchto POJO prostřednictvím JSON. Takže SOFEA je ve skutečnosti pro GFS opravdu vhodný.
Nejnáročnější částí však byla vize vytvoření tohoto webového uživatelského rozhraní skutečně statickým. Chcete-li vytvořit rychlou dobrou webovou aplikaci, potřebujete další nástroje. Pro správu CSS používám Compass. Pro JavaScript používám kompilátor Google Closure, který má úžasnou funkci zdrojových map. Vrhněte některé další požadavky na vynechání mezipaměti a usnadněte jeho vývoj a najednou potřebujete kompletní řešení pro sestavení něčeho, co se nakonec stane jen hromadou textových souborů.
Existuje několik působivých nástrojů, které na tyto výzvy začaly reagovat. Grunt a Yeoman na mě docela udělali dojem a dokonce jsem udělal hřiště GFS, abych opustil Mavena pro Yeomana; alespoň pro webové uživatelské rozhraní. Mám dojem, že vykopání Maven může být trochu příliš daleko pro nástroje, které ještě nejsou ani rok staré. Začal jsem tedy vytvářet plugin Maven, abych to všechno spojil. Existují pluginy Maven pro zpracování Compass a Closure, ale neposkytují kompletní řešení, které může dokonce upravit vývoj HTML oproti produkci a také poskytnout funkci živého opětovného načtení. To byl skutečně skvělý zážitek při psaní tohoto pluginu Maven, který je samozřejmě napsán v Javě.
Možná brzy budu schopen přesvědčit vedení, aby mi to umožnilo vrátit komunitě open source.
Matt Heusser: Jak dlouho jste architektem? Na čem jsi pracoval před rokem?
Bruce Brouwer: Jsem aplikačním architektem již osm let. Když jsem přešel na GFS, udělal jsem skok od staršího programátora k architektovi.
Mým předchozím velkým projektem, na kterém jsem pracoval před rokem, byl přechod na Google Apps. I pro mě to byla skutečná zkušenost s učením. Během přechodu jsem měl tento skvělý nápad synchronizovat starší kalendář s Kalendářem Google. Aby se to všechno stalo, použil jsem Google API z Java spolu s Spring Integration. Alespoň na chvíli. Po několika vážných závadách jsem musel uznat, že to za to riziko nestálo. Být architektem a vývojářem tohoto projektu mi pomohlo udržet skutečný svět v perspektivě.
„Museli jsme nakreslit čáru v písku pro to, co je a není vhodné používat pro Google při integraci s našimi stávajícími systémy. Může být obtížné, když jste nuceni trochu z toho nadšení zmírnit.“
Google přináší GFS zcela nový svět možností. Její dopad na způsob, jakým navrhujeme naše systémy, začínáme pociťovat. Už jsem měl spoustu rozhovorů s lidmi, kteří chtějí používat Google, protože je to nová lesklá hračka. Museli jsme nakreslit čáru v písku pro to, co je a není vhodné používat pro Google při integraci s našimi stávajícími systémy. Může být obtížné, když jste nuceni trochu z toho nadšení zmírnit.
Matt Heusser: Jako architekt jste dosáhli úrovně, které dosahuje pouze malé procento programátorů. Máte rady pro programátory začínající v jejich kariéře?
Bruce Brouwer: Miluji, když noví programátoři přijdou s nápadem zpochybnit současný stav. Obvykle chtějí k usnadnění úkolu použít nějaký nový nástroj. Až se to stane, mohu jim pomoci podívat se na širší obraz. Často to znamená poukázat na problémy se zavedením tohoto nástroje. Mluvení o problémech někdy nutí nového programátora, aby otevřel oči větším problémům.
Moje rada tedy pro nového programátora je jít dál a vyzvat některé nápady. Najděte seniorního programátora nebo architekta, kterého můžete použít jako mentora, a vyjádřete svůj nápad. Nápad pravděpodobně nevyprchá, ale zjistíte toho hodně proč mýlíš se, nejen že se mýlíš. Nezapomeňte však také na to, že starší programátoři a architekti mohou trpět krátkozrakostí a můžete najít nápad, který stojí za to sledovat.
Matt Heusser: Kdo je váš zákazník? (Nebo si půjčit linku od Bobů v „Kancelářském prostoru“: Co byste řekli, že tady děláte?)
Bruce Brouwer: Opravdu přímo nepodporuji žádného zákazníka v tom smyslu, že by existovalo přímé obchodní zaměření. Ve skutečnosti jsem umístěn na straně infrastruktury IS, spolu s administrátory DBA a serverů. Zbytek IS se skutečně zaměřuje na obsluhu určité oblasti podnikání. Může se zdát divné umístit vývojáře Java do infrastruktury, ale umožňuje mi to zaměřit se na problémy, které mají větší architektonické zaměření, než by mohli mít ostatní. Zatímco se ostatní pokoušejí propracovat definování obchodních procesů, soustředím se více na technologii, která se používá k opakovanému použití problémů všech.
Lidé mě často žádají o pomoc s jinými projekty; někdy i po delší dobu. To mi pomáhá zůstat na zemi ve skutečném světě. Pomáhá mi to také šířit nové nápady do ostatních vývojových týmů. Zjistil jsem, že když jsem byl požádán, abych hrál roli architekta projektu, můj vliv byl omezen na více mladých vývojářů; ve skutečnosti bylo pro mě užitečnější přispívat na jiné projekty, které již mají architekta, protože mohu své nápady prosazovat u těch, kteří mají v jejich organizační části větší vliv.
Matt Heusser: Jak dlouho programujete v Javě? Jak jste viděli, jak se za ta léta změnilo samotné programování jazyka a Java?
Bruce Brouwer: Skutečně jsem Javu nebral vážně, dokud Java 1.3. To by tedy bylo asi 13 let. Ale i tehdy se Java opravdu nestala radostí se vyvíjet, dokud se neobjevila 1.5 s generikami. Existuje tolik dobrých využití generik a zdá se, že většina lidí je nepoužívá nad rámec rámce Java.
Když jsem začínal s Java, psali jsme téměř všechno sami. Postupem času jsem viděl, jak zbytek světa přijal Javu, zejména v komunitě open source. Tato exploze otevřeného zdroje je nejdůležitější změnou, kterou jsem během své kariéry v programování v Javě prošel. Je to něco, co se donedávna opravdu neshodovalo s žádným jiným jazykem.
Matt Heusser: Promluvte si se mnou o používání JRuby na GFS. Jaký je váš názor na jazyky JVM; měli bychom se nyní všichni stát programátory Clojure?
Bruce Brouwer: JRuby byl ve skutečnosti prostředkem k dosažení cíle u Gordona. Compass je skutečně premiérovou implementací Sass a je napsán v Ruby. Také jsem použil Rhino a Groovy také na JVM. Viděl jsem, jak mocné a schopné jsou tyto další jazyky, ale stejně tak i Java.
V poslední době si popularitu získaly i jiné jazyky, jako je Scala, a zmínil jste se o Clojure. I když ve Scale můžete dělat totéž s něčím jako polovina kódu Java, domnívám se, že čitelnost může trpět rychleji než v Javě. Před nějakou dobou jsem viděl několik dodavatelů s nálepkami na svém notebooku, kteří říkali: „Psaní není překážkou.“ Naprosto souhlasím. Promyšlení problému a jeho objasnění dalšímu člověku je důležitější než hledání chytrých způsobů, jak snížit počet řádků kódu, který napíšete. Nechápejte mě špatně, údržba menšího kódu je lepší než většího kódu, ale musí být jasné, o co jde.
