Ohjelmointi

Koko Java-elämä: Mitä ohjelmistoarkkitehti todella tekee koko päivän?

Ohjelmistoarkkitehdeillä on helppoa, tai niin monet koodaajat ja insinöörit uskovat. Ota selvää, miltä arkkitehdin jokapäiväinen työelämä todella näyttää tässä Täysi Java-elämä haastatella. Java-ohjelmointiveteraani Bruce Brouwer kertoo lähestymistavastaan ​​vanhojen Java-verkkosovellusten päivittämiseksi palvelukeskeiseksi käyttöliittymäarkkitehtuuriksi, nopeasti kehittyvästä käyttöliittymän työkalupakististaan ​​ja siitä, miksi hän yleensä mieluummin työskentelee Javan rajoitusten kanssa vähemmän tiukan JVM-kielen valitsemisesta.

Kuten monet ohjelmistokehittäjät, olen aina suhtautunut skeptisesti arkkitehteihin. Liian usein he näyttävät asettavan vaatimuksia siitä, miten koodaus tehdään, ilman että heidän täytyy elää seurausten kanssa. Olen kaveri, joka kirjoitti kerran artikkelin nimeltä "Miksi en ole arkkitehti", ja minun on tiedetty tyytyvän "Hänen suosikki IDE on MS Outlook".

Sitten tapasin Bruce Brouwerin, sovellusarkkitehdin Gordon Food Service (GFS): stä, perheomistuksessa olevan elintarvikkeiden jakelijan, jolla on toimistot Michiganissa. Kun tapasin Brucen, hän oli syvällä tietokoneen näytöllä ja katsoi todellista koodia. Hänen tehtävänään oli integroida GFS: n Ruby-pohjainen Compass-kääntäjä JRuby-sovellusta käyttävään sovellusrakenteeseen, ja hänen lähestymistavansa työhön vaikutti vain abstraktilta. Minua kiehtoi.

Hänen mukaansa Brucen tehtävä GFS: ssä on sekä asettaa visio tuleville verkkosovelluksille että demonstroida hänen näkemyksiään konseptisovelluksilla. Hän työskentelee tyypillisesti kehitystiimien kanssa muutaman ensimmäisen käyttöönoton yhteydessä. Edistyksellinen asia, jonka Bruce työskenteli tapaamispäivänä, oli kuinka GFS siirretään perinteisten pyyntö- / vastausverkkosovellusten ohitse palvelukeskeinen etupään arkkitehtuuri (SOFEA), jossa kaikki esityslogiikat käsitellään selaimessa eikä palvelimessa.

Bruce jakoi joitain ideoitaan siirtyä perinteisten palvelukeskeisten arkkitehtuurien (SOA) ulkopuolelle enemmän viestipohjaisiin paradigmoihin. Näiden ideoiden on toimittava paperilla, mutta Bruce tarvitsee sisäänostoja teknisiltä ryhmiltä saadakseen ne toimimaan. Arkkitehtina hän tarjoaa käyttöönotto-ohjeita ryhmille, tekniikoille ja jopa vanhoille järjestelmille. Hänen näkökulmansa on kiehtova, ja ajattelin jakamisen arvoinen.

Matt Heusser: Keskustele minulle ohjelmoijan ja arkkitehdin urastasi. Kuinka roolisi on muuttunut ajan myötä? Kuinka lähestyit rooliasi nuorempana ohjelmoijana keski-uran ohjelmoijana tai arkkitehtina tänään?

Bruce Brouwer: Yliopiston jälkeen muutin ensimmäiseen todelliseen työpaikkaani. Melkein alusta alkaen työnsin rajoja. Oli tämä ikävä prosessi tämän sovelluksen tiedonsiirtokerroksen päivittämiseksi. Kaikki uudet työntekijät kärsivät tuskasta prosessin tekemisessä. Ensimmäisen käyttökerran jälkeen päätin automatisoida sen. Hallinnointi oli vaikuttunut, joten he pyysivät minua suorittamaan sen kaikille tietokannan taulukoille. Kesti noin viikko puhdistaa sotku automatisoidustani, joka osoittautui rikkoutuneeksi prosessiksi.

Kun jatkoin urallani, löysin paljon muita mahdollisuuksia helpottaa asioiden kehitystä. Minuun liittyi nopeasti lause: "Yksi koodirivi." Pysyin työssäni, jotta kehittäjät tekisivät asioita yksinkertaisemmiksi. En ollut todella tyytyväinen työhöni, ennen kuin voit tehdä jotain aiemmin monimutkaista, mutta nyt yksinkertaista kuin yksi koodirivi.

Mutta voit mennä niin pitkälle vain tekemällä parempia työkaluja. Minun piti alkaa ajatella laajemmassa mittakaavassa. Kun aloitat pelaamisen tässä suuremmassa maailmassa, sinun on jälleen ylitettävä rajoja. Ehkä SQL-tietokantaa ei tarvita. Ehkä vastauksen odottaminen kyseiseltä palvelulta ei ole paras ajankäyttö. Ehkä Java ei enää leikkaa sitä.

Okei, tämä viimeinen kohta on hieman kiistanalainen, mutta se on kysymys, jonka olen esittänyt. Mutta yksinkertaisesti näiden kysymysten esittäminen ei ole arkkitehdin todellinen tehtävä. Jopa ehdottoman loistavan arkkitehtuurin suunnittelu ei riitä. Sinun on pystyttävä osoittamaan muille, miten päästä sinne, askel askeleelta. Arkkitehdin on oltava maadoitettu todellisessa maailmassa, kokenut ongelmat, jotka tulevat heidän suunnittelemastaan. Tämä vaatii sekä teknistä että sosiaalista työtä.

Matt Heusser: Mitä tekniikoita työskentelet nyt?

Bruce Brouwer: Ei liian kauan sitten päätin täyttää LinkedIn-profiilini ja luetella kaikki tekniikat, joita todella käytän. Tuon työn aikana opin, että LinkedInillä on raja. En sano sitä kehua, mielestäni se on ongelma. On aivan liian monia asioita, jotka sinun on tiedettävä ollaksesi hyvä kehittäjä nykymaailmassa. Meidän on tehtävä paremmin rajoittamalla luetteloa työkaluista, joita käytämme työmme suorittamiseen.

Suurimmaksi osaksi käytän Java ja Spring. Olen viime aikoina työskennellyt suunnitellessani web-sovelluskehityksen tulevaisuuden GFS: ssä. GFS on kehittänyt Java EE: tä käyttäviä verkkosovelluksia siitä lähtien, kun kehyksiä, kuten Struts tai JSF, oli olemassa. Nyt on joitain uusia ideoita, jotka haastavat nämä palvelinpuolen verkkokehykset, kuten SOFEA ja reagoiva suunnittelu. Kyllä, voisimme nostaa nämä ideat nykyiseen Struts 2 -infrastruktuuriin, mutta meillä on aika tehdä todellinen tauko käyttöliittymän ja takapään välillä. Tällä tavalla voimme paremmin vastata web-käyttöliittymäkerroksen muutosvauhtiin tarvitsematta tehdä niin rajuja muutoksia palvelutasossa.

"Nyt on joitain uusia ideoita, jotka haastavat palvelinpuolen verkkokehykset, kuten SOFEA ja reagoiva suunnittelu. Kyllä, voisimme sisällyttää nämä ideat nykyiseen Struts 2 -infrastruktuuriin, mutta on aika tehdä todellinen tauko käyttöliittymän ja takaosan välillä loppuun. "

Tätä uutta käyttöliittymää varten minulla on melkein täysin uusi työkalupaketti: Angular ja Twitter Bootstrap sekä tietysti jQuery. Pyrin rakentamaan koko käyttöliittymän staattisista resursseista. Kukaan käyttöliittymästä ei luota siihen, että palvelin luo dynaamista käyttöliittymäsisältöä. Sen on toimittava tavallisessa Apache-verkkopalvelimessa; ei PHP, ei Perl, ei mitään.

Palvelukerroksen osalta GFS: llä on valtava Java-perintö. Ja suurimmaksi osaksi se on todella hyvä. GFS on vuosien ajan pyrkinyt palvelukeskeiseen arkkitehtuuriin hyödyntämällä kevään POJO: ita. Palvelut ovat SOFEA: n ytimessä. JSON on valittu datansiirto nykyään, ja Spring MVC tekee näiden POJOn paljastamisen helpoksi JSON: n kautta. Joten SOFEA sopii todella hyvin GFS: ään.

Haastava osa on kuitenkin ollut näkemys siitä, että web-käyttöliittymä on todella staattinen. Nopean hyvän verkkosovelluksen tekeminen vaatii joitain muita työkaluja. Käytän Compassia CSS: n hallintaan. JavaScriptiä varten käytän Google Closure-kääntäjää, jolla on lähdekarttojen mahtava ominaisuus. Heitä joitain muita välimuistin rikkoutumisen vaatimuksia ja tee siitä helppoa kehittää, ja yhtäkkiä tarvitset täydellisen rakenneratkaisun jostakin, josta tulee vain joukko tekstitiedostoja.

On olemassa muutama vaikuttava työkalu, jotka ovat alkaneet vastata näihin haasteisiin. Olen ollut melko vaikuttunut Gruntista ja Yeomanista ja tein jopa kentän GFS: lle hylkäämään Mavenin Yeomanille; ainakin verkkokäyttöliittymälle. Sain vaikutelman, että Mavenin ojaaminen saattaa olla hieman liian kaukana työkaluille, jotka eivät ole vielä vuoden ikäisiä. Joten aloitin Maven-laajennuksen vetääksesi tämän kaiken yhteen. Kompassin ja sulkemisen käsittelemiseksi on olemassa Maven-laajennuksia, mutta ne eivät tarjoa täydellistä ratkaisua, joka voi jopa muokata HTML-kehitystä tuotantoon verrattuna ja tarjota myös live-reload-toimintoja. Tämä on itse asiassa ollut hieno kokemus tämän Maven-laajennuksen kirjoittamisesta, joka on tietysti kirjoitettu Java-kielellä.

Ehkä pian pystyn vakuuttamaan johdon sallimaan minun palauttaa tämän avoimen lähdekoodin yhteisölle.

Matt Heusser: Kuinka kauan olet ollut arkkitehti? Millä työskentelitte vuosi sitten?

Bruce Brouwer: Olen ollut sovellusarkkitehti jo kahdeksan vuotta. Tein hypyn vanhemmasta ohjelmoijasta arkkitehdiksi, kun muutin GFS: ään.

Aikaisempi iso projekti, jonka parissa työskentelin vuosi sitten, oli siirtyminen Google-sovelluksiin. Tämä oli todellinen oppimiskokemus myös minulle. Minulla oli tämä loistava idea synkronoida vanha kalenteri Google-kalenterin kanssa siirtymisen aikana. Käytin Java: n Google-sovellusliittymiä yhdessä Spring Integrationin kanssa, jotta kaikki tapahtuisi. Ainakin hetkeksi. Muutaman vakavan häiriön jälkeen minun piti myöntää, että se ei ollut riskin arvoinen. Sekä arkkitehti että projektin kehittäjä auttoivat minua pitämään todellisen maailman näköpiirissä.

"Meidän on pitänyt piirtää hiekkaan viiva sille, mikä on ja mikä ei ole tarkoituksenmukaista käyttää Googlea integroituna olemassa oleviin järjestelmiin. Se voi olla vaikeaa, kun sinun on pakotettava hillitsemään innostusta."

Google tuo GFS: ään aivan uuden mahdollisuuksien maailman. Alamme tuntea sen vaikutuksen vain järjestelmiemme suunnittelussa. Olen jo käynyt paljon keskusteluja ihmisten kanssa, jotka haluavat käyttää Googlea, koska se on uusi kiiltävä lelu. Meidän on pitänyt piirtää viiva hiekkaan sille, mikä on ja mikä ei ole asianmukaista käyttää Googlea integroituna olemassa oleviin järjestelmiin. Se voi olla vaikeaa, kun sinut pakotetaan hillitsemään jotakin innostusta.

Matt Heusser: Arkkitehtina olet saavuttanut tason, jonka vain pieni osa ohjelmoijista saavuttaa. Onko sinulla neuvoja ohjelmoijille, jotka aloittavat uransa?

Bruce Brouwer: Rakastan sitä, kun uudet ohjelmoijat keksivät idean haastaa nykyisen tilanteen. Yleensä he haluavat käyttää jotain uutta työkalua tehtävän helpottamiseksi. Kun näin tapahtuu, voin auttaa heitä katsomaan suurempaa kuvaa. Usein se tarkoittaa, että tuodaan esiin ongelmat kyseisen työkalun tuomisessa. Ongelmien puhuminen pakottaa joskus uuden ohjelmoijan avaamaan silmänsä suurempiin ongelmiin.

Joten neuvoni uudelle ohjelmoijalle on mennä eteenpäin ja haastaa joitain ideoita. Etsi vanhempi ohjelmoija tai arkkitehti, jota voit käyttää mentorina ja ilmaista ideasi. Todennäköisesti ajatus ei leviä, mutta opit paljon oppimalla miksi olet väärässä, ei vain, että olet väärässä. Mutta muista myös, että vanhemmat ohjelmoijat ja arkkitehdit voivat kärsiä likinäköisyydestä, ja saatat vain löytää ajatuksen, joka kannattaa jatkaa.

Matt Heusser: Kuka on asiakkaasi? (Tai lainataksesi rivin "Office Space" -obobilta: Mitä sanot tekevän täällä?)

Bruce Brouwer: En todellakaan tue suoraan ketään asiakasta siinä mielessä, että kyseessä olisi suora liiketoiminta. Olen itse asiassa sijoitettu IS: n infrastruktuuripuolelle yhdessä DBA: n ja palvelimen järjestelmänvalvojien kanssa. Loput IS: stä keskittyvät todella palvelemaan tiettyä liiketoiminta-aluetta. Vaikuttaa oudolta sijoittaa Java-kehittäjä infrastruktuuriin, mutta se antaa minun keskittyä asioihin, joilla on suurempi arkkitehtoninen painopiste kuin muilla saattaa olla. Kun muut yrittävät määritellä liiketoimintaprosesseja, saan keskittyä enemmän tekniikkaan, jota käytetään kaikkien ongelmien ratkaisemiseen uudelleenkäytettävällä tavalla.

Ihmiset pyytävät minua usein auttamaan muita hankkeita; joskus pitkäksi aikaa. Tämä auttaa minua pysymään maadoitettuna todellisessa maailmassa. Se auttaa myös levittämään uusia ideoita muille kehitystiimeille. Olen havainnut, että kun minua pyydettiin näyttämään osa projektin arkkitehdistä, vaikutukseni rajoittui useampiin nuorempiin kehittäjiin; Minulle on itse asiassa ollut hyödyllisempää osallistua muihin hankkeisiin, joissa jo on arkkitehti, koska voin viedä ajatuksiani niiden kanssa, jotka ovat vaikutusvaltaisempia organisaationsa osassa.

Matt Heusser: Kuinka kauan olet ohjelmoinut Java-ohjelmassa? Kuinka olet nähnyt itse kielen ja Java-ohjelmoinnin muuttuvan noina vuosina?

Bruce Brouwer: En oikeastaan ​​ottanut Javaa vakavasti vasta Java 1.3: een. Joten se olisi noin 13 vuotta. Mutta silloinkin Javasta ei todellakaan tullut iloa kehittää, ennen kuin 1.5 tuli geneeristen lääkkeiden kanssa. Geneerisiä lääkkeitä on niin paljon, ja useimmat ihmiset eivät näytä käyttävän niitä Java-kokoelmakehyksen ulkopuolella.

Kun aloitin Java-ohjelmalla, kirjoitimme melkein kaiken itse. Ajan myötä olen nähnyt, kuinka muu maailma on omaksunut Java, etenkin avoimen lähdekoodin yhteisössä. Tuo avoimen lähdekoodin räjähdys on tärkein muutos, jonka olen kokenut urani aikana Java-ohjelmoinnissa. Se on jotain, jota ei todellakaan ole sovitettu muulla kielellä vasta äskettäin.

Matt Heusser: Keskustele minulle JRubyn käytöstä GFS: ssä. Mitä mieltä olet JVM-kielistä; Pitäisikö meidän kaikkien tulla nyt Clojure-ohjelmoijiksi?

Bruce Brouwer: JRuby oli todella keino saavuttaa Gordons. Kompassi on todellakin Sassin ensi-ilta, ja se sattuu olemaan kirjoitettu Ruby-muodossa. Olen käyttänyt myös Rhinoa ja Groovyä JVM: ssä. Olen nähnyt kuinka voimakkaita ja kykeneviä nämä muut kielet ovat, mutta niin on myös Java.

Muut kielet, kuten Scala, ja mainitsit Clojuren, ovat saaneet suosiota viime aikoina. Vaikka voit tehdä saman asian Scalassa jollain puolikkaalla Java-koodilla, luulen, että luettavuus voi kärsiä nopeammin kuin Java. Jokin aika sitten näin useita urakoitsijoita, joiden kannettavassa tietokoneessa oli tarroja, joissa luki "Kirjoitus ei ole pullonkaula". Olen täysin samaa mieltä. Ongelman miettiminen ja tekeminen selväksi seuraavalle kaverille on tärkeämpää kuin löytää älykkäitä tapoja vähentää kirjoittamiesi koodirivien määrää. Älä ymmärrä väärin, että vähemmän koodia on parempi kuin enemmän koodia, mutta sen on oltava selvää, mitä tapahtuu.

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