Пълният живот на Java: Какво всъщност прави софтуерният архитект през целия ден?

Софтуерните архитекти го правят лесно или поне толкова програмисти и инженери вярват. Разберете как наистина изглежда ежедневният трудов живот на архитекта в това пълно интервю за живота на Java . Ветеранът по програмиране на Java Брус Брауър обсъжда подхода си за надграждане на наследените уеб приложения на Java до ориентирана към услуги архитектура отпред, бързият му еволюиращ набор от инструменти за потребителски интерфейс и защо предпочита да работи с ограниченията на Java, отколкото да избере по-малко строг JVM език.

Както много разработчици на софтуер, и аз винаги съм бил скептичен към архитектите. Изглежда твърде често те отправят искания за това как ще се извърши работата по кодиране, без да се налага да живеят с последствията. Аз съм човекът, който веднъж е написал статия, озаглавена „Защо не съм архитект“, и съм известен с това, че капри „Любимата му IDE е MS Outlook“.

След това срещнах Брус Брауър, архитект на приложения в Gordon Food Service (GFS), семеен дистрибутор на храни с офиси в Мичиган. Когато срещнах Брус, той беше дълбоко в екрана на компютъра си и гледаше действителния код. Неговата задача беше да интегрира базиран на Ruby компилатор Compass на GFS в компилация на приложения с помощта на JRuby и подходът му към работата изглеждаше всичко друго, но не и абстрактно. Бях заинтригуван.

Работата на Брус в GFS, както казва той, е както да зададе визията за бъдещите уеб приложения, така и да демонстрира визията си с доказателствени концепции. Обикновено работи с екипите за разработка на първите няколко внедрения на въвеждането. Актуалният въпрос, по който Брус работи, в деня, в който се срещнахме, беше как да преместим GFS от традиционните уеб приложения за заявки / отговори в ориентирана към услугата архитектура на предния край (SOFEA), където цялата логика на презентацията се обработва в браузъра а не на сървъра.

Брус сподели някои от идеите си за прокарване отвъд класическите ориентирани към услуги архитектури (SOA) в по-базирани на съобщения парадигми. Тези идеи трябва да работят на хартия, но Брус се нуждае от изкупуване от техническите екипи, за да ги накара да работят. Като архитект той предоставя насоки за изпълнение на екипи, технологии и дори наследени системи. Неговата е очарователна перспектива и мислех, че си струва да я споделя.

Мат Хойсер : Говорете ми за вашата кариера като програмист и архитект. Как се е променила ролята ви с течение на времето? Как подходихте към ролята си на младши програмист спрямо програмист в средата на кариерата или като архитект днес?

Брус Брауър : След колежа се преместих в първата си истинска работа. Почти от самото начало се придвижвах по границите. Имаше този досаден процес на актуализиране на слоя за достъп до данни на това приложение. Всички нови наети бяха подложени на болката от работата в този процес. След първия си път реших да го автоматизирам. Управлението беше впечатлено, затова ме помолиха да го стартирам за всички таблици в базата данни. Отне около седмица да изчистя бъркотията от автоматизирането ми, което се оказа нарушен процес.

Докато продължавах в кариерата си, открих много повече възможности за улесняване на развитието. С мен бързо се свърза фраза: „Един ред код“. Продължавах да настоявам за работата си, за да улесня нещата за разработчиците. Не бях истински доволен от работата си, докато не можете да направите нещо, което преди беше сложно, но сега беше толкова просто, колкото един ред код.

Но можете да стигнете толкова далеч, като направите по-добри инструменти. Трябваше да започна да мисля в по-голям мащаб. Когато започнете да играете в този по-голям свят, отново трябва да изместите границите. Може би SQL база данни не е необходима. Може би чакането на отговор от тази услуга не е най-доброто използване на времето. Може би Java вече не го отрязва.

Добре, последната точка е малко спорна, но това е въпрос, който аз зададох. Но просто задаването на тези въпроси не е истинската работа на архитекта. Дори проектирането на абсолютно брилянтна архитектура не е достатъчно. Трябва да можете да покажете на другите как да стигнат там, стъпка по стъпка. Архитектът трябва да бъде основан на реалния свят, изпитвайки проблемите, произтичащи от това, което са проектирали. Това изисква както технически, така и социални усилия.

Мат Хойсер : С какви технологии работите сега?

Брус Брауър : Не много отдавна реших да попълня профила си в LinkedIn, изброявайки всички технологии, които всъщност използвам. По време на тези усилия научих, че LinkedIn има лимит. Не казвам това, за да се хваля, мисля, че това е проблем. Има твърде много неща, които трябва да знаете, за да бъдете добър разработчик в днешния свят. Трябва да се справим по-добре в ограничаването на списъка с инструменти, които използваме, за да си вършим работата.

До голяма степен това, което използвам, е Java и Spring. Това, по което наскоро работя, е да проектирам бъдещето на разработването на уеб приложения в GFS. GFS разработва уеб приложения, използващи Java EE от времето, преди да има рамки като Struts или JSF. Сега има някои нови идеи, които предизвикват тези сървърни уеб рамки, като SOFEA и отзивчив дизайн. Да, бихме могли да включим тези идеи в настоящата инфраструктура на Struts 2, която имаме, но е време да направим истинска почивка между потребителския интерфейс и задния край. По този начин ще бъдем в по-добра позиция да реагираме на темпото на промяна в слоя на уеб потребителския интерфейс, без да се налага да правим такива драстични промени в нивото на услугата.

"Сега има някои нови идеи, които предизвикват сървърни уеб рамки, като SOFEA и отзивчив дизайн. Да, бихме могли да включим тези идеи в текущата инфраструктура на Struts 2, но е време да направим истинска почивка между потребителския интерфейс и гърба край."

За този нов уеб потребителски интерфейс имам почти напълно нов набор от инструменти: Angular и Twitter Bootstrap и разбира се jQuery. Това, което преследвам, е да изградя целия потребителски интерфейс от статични ресурси. Никой от потребителския интерфейс няма да разчита на сървъра, генериращ динамично съдържание на потребителския интерфейс. Трябва да работи в обикновен уеб сървър на Apache; не PHP, не Perl, нищо.

Що се отнася до сервизния слой, GFS има огромно наследство на Java. И в по-голямата си част всъщност е доста добър. GFS преследва ориентирана към услуги архитектура в продължение на години, използвайки Spring POJO. Услугите са в основата на SOFEA. JSON е избраният транспорт за данни в наши дни, а Spring MVC улеснява излагането на тези POJO чрез JSON. Така че SOFEA всъщност е наистина подходящ за GFS.

Предизвикателната част обаче беше тази визия за превръщането на този уеб потребителски интерфейс в истински статичен. За да направите добро уеб приложение, което е бързо, са необходими някои други инструменти. Използвам Compass за управление на CSS. За JavaScript използвам компилатора на Google Closure, който има страхотната функция на изходните карти. Включете някои други изисквания за разбиване на кеш паметта и улесняване на разработването и изведнъж се нуждаете от цялостно решение за изграждане на нещо, което в крайна сметка се превръща в един куп текстови файлове.

Има няколко впечатляващи инструмента, които започнаха да отговарят на тези предизвикателства. Бях впечатлен от Grunt и Yeoman и дори направих терена пред GFS, за да напусна Maven заради Yeoman; поне за уеб потребителския интерфейс. Останах с впечатлението, че изхвърлянето на Maven може да е твърде далеч за инструменти, които все още не са навършили една година. Така че започнах да правя плъгин Maven, за да събера всичко това заедно. Има плъгини Maven, които се справят с Compass и Closure, но те не предоставят цялостно решение, което дори може да модифицира разработката на HTML в сравнение с производството и също така предоставя функционалност за презареждане на живо. Това всъщност беше чудесно преживяване при писането на тази приставка Maven, която, разбира се, е написана на Java.

Може би скоро ще успея да убедя ръководството да ми позволи да върна това на общността с отворен код.

Мат Хойсер : От колко време сте архитект? Над какво работихте преди година?

Брус Брауър : Вече осем години съм архитект на приложения. Преминах от старши програмист на архитект, когато се преместих в GFS.

Предишният ми голям проект, по който работех преди година, беше преминаването към Google Apps. Това беше истинско учебно изживяване и за мен. Имах тази велика идея да синхронизирам наследения календар с Google Calendar по време на прехода. Използвах API на Google от Java заедно с Spring Integration, за да направя всичко това. Поне за известно време. След няколко сериозни бъга трябваше да призная, че не си струваше риска. Да бъда едновременно архитект и разработчик на този проект ми помогна да поддържам реалния свят в перспектива.

"Трябваше да очертаем линия в пясъка за това, което е и не е подходящо да използваме Google, когато се интегрираме със съществуващите ни системи. Може да бъде трудно, когато сте принудени да смекчите част от този ентусиазъм."

Google предлага изцяло нов свят от възможности за GFS. Едва започваме да усещаме въздействието му по начина, по който проектираме нашите системи. Вече имах много разговори с хора, които искат да използват Google, защото това е лъскавата нова играчка. Трябваше да очертаем линия в пясъка за това, което е и не е подходящо да използваме Google, когато се интегрираме със съществуващите ни системи. Може да бъде трудно, когато сте принудени да смекчите част от този ентусиазъм.

Мат Хойсер : Като архитект сте достигнали ниво, което постига само малък процент от програмистите. Имате ли съвет за програмисти, които започват своята кариера?

Брус Брауър : Обичам, когато нови програмисти измислят идея да оспорят настоящото статукво. Обикновено те искат да използват някакъв нов инструмент, за да улеснят задачата. Когато това се случи, мога да им помогна да погледнат по-общата картина. Често това означава посочване на проблемите с въвеждането на този инструмент. Разговарянето с проблемите понякога принуждава новия програмист да отвори очите си за по-големи проблеми.

Така че моят съвет е към нов програмист да продължи и да оспори някои идеи. Намерете старши програмист или архитект, който можете да използвате като наставник и да изразите идеята си. Вероятно идеята няма да изпадне, но ще научите много, като разберете защо грешите, а не само че грешите. Но не забравяйте също, че старшите програмисти и архитекти могат да страдат от късогледство и може би просто ще намерите идея, която си струва да преследвате.

Мат Хойсер : Кой е вашият клиент? (Или да заемете ред от Bobs в „Office Space“: Какво бихте казали, че правите тук?)

Брус Брауър : Аз всъщност не подкрепям директно нито един клиент в смисъл, че ще има пряк бизнес фокус. Всъщност съм разположен в инфраструктурната страна на IS, заедно с администраторите на администратори и сървъри. Останалата част от ИС наистина има фокус да обслужва определена област от бизнеса. Може да изглежда странно да се постави разработчик на Java в инфраструктурата, но това ми позволява да се съсредоточа върху въпроси, които имат по-голям архитектурен фокус от други. Докато други се опитват да работят чрез дефиниране на бизнес процеси, аз се фокусирам повече върху технологията, която се използва за решаване на проблемите на всеки по многократна употреба.

Хората често ме молят да подпомагам други проекти; понякога за продължителни периоди от време. Това ми помага да остана приземен в реалния свят. Също така ми помага да разпространявам нови идеи сред останалите екипи за разработка. Открих, че когато бях помолен да играя ролята на архитекта на проекта, моето влияние беше ограничено до по-млади разработчици; всъщност ми беше по-полезно да участвам в други проекти, които вече имат архитект, защото мога да прокарам идеите си с онези, които са по-влиятелни в своята част от организацията.

Мат Хойсер : От колко време програмирате в Java? Как видяхте как езикът и самото програмиране на Java се променят през тези години?

Брус Брауър : Всъщност не приемах Java сериозно до Java 1.3. Това би било около 13 години. Но дори тогава Java наистина не се превърна в радост за развитие, докато 1.5 не се появи с генерични продукти. Има толкова много добри приложения на генеричните лекарства и изглежда, че повечето хора не ги използват извън рамките на колекциите на Java.

Тогава, когато започнах с Java, написахме почти всичко сами. С течение на времето видях как останалият свят е възприел Java, особено в общността с отворен код. Тази експлозия на отворен код е най-важната промяна, която преживях по време на кариерата си в програмирането на Java. Това е нещо, което доскоро наистина не е било съчетано от никой друг език.

Мат Хойсер : Говорете ми за използването на JRuby в GFS. Какво е мнението ви за езиците JVM; трябва ли всички да станем програмисти на Clojure сега?

Брус Брауър : JRuby наистина беше средство за постигане на целта в Gordons. Compass е наистина премиерната реализация на Sass там и се случва да бъде написана на Ruby. Също така използвах Rhino и Groovy, както и на JVM. Виждал съм колко мощни и способни са тези други езици, но също и Java.

Други езици като Scala и споменахте Clojure, придобиха популярност напоследък. Въпреки че можете да направите същото нещо в Scala с нещо като половината код на Java, аз вярвам, че четливостта може да пострада по-бързо, отколкото в Java. Преди известно време видях редица изпълнители със стикери на лаптопа си, на които пишеше: „Въвеждането не е пречка“. Напълно съм съгласен. Размишляването върху проблема и изясняването на следващия човек е по-важно от намирането на интелигентни начини за намаляване на броя на редовете код, който пишете. Не ме разбирайте погрешно, поддържането на по-малко код е по-добре от повече код, но трябва да е ясно какво се случва.