Yli kaksi vuotta sitten olen vapaaehtoinen beetatestaajana Sun Microsystems Certified Enterprise Architect for J2EE (Java 2 Platform, Enterprise Edition) -tutkintoon. Katsoin suunniteltua opetussuunnitelmaa ja näin arvon sertifikaatissa, joten päätin mennä siihen. Neljä kuukautta ja paljon kovaa työtä myöhemmin sain todistuksen ja tunnuksen postitse, melkein kuin olisin liittynyt hyvin valikoituun faniklubiin! Oliko se sen arvoista? Sanalla sanoen kyllä. Minun suoraviivainen tavoitteeni oli sertifiointi, mutta olin iloisesti yllättynyt siitä, että sertifiointiprosessi avasi silmäni ideoille ja lähestymistavoille, joita en yksinkertaisesti ollut ehtinyt tutkia päivätyöni hälinästä. Jatkan Sunin kanssa kokeen sisältöä ja rakennetta ja olen tällä hetkellä kokeen tutkija. Tässä artikkelissa jaan kokemukseni ja valitsen myös Sun C2: n J2EE-arkkitehtikokeen johtavan kehittäjän Mark Caden aivot. Jos haluat tulla Sun-sertifioiduksi J2EE-arkkitehdiksi, lue eteenpäin.
Miksi saada sertifikaatti?
Yksinkertaisesti sanottuna mikä tahansa sertifikaatti on vain yhtä hyvä kuin myöntävä elin. Meidän tapauksessamme myöntävä elin on Sun, J2EE: n takana oleva yritys. Se tekee sertifioinnista valurautaa kirjassani. Monia muita sertifikaatteja on saatavana useilta Java-toimittajilta, mutta Sun haluaa sertifioida ja hyväksyä arkkitehdit J2EE-alustalle, ei sovelluspalvelimelle X, Y tai Z.
Yleensä toimialallamme kuitenkin keskustellaan usein yliopiston tai yrityksen myöntämän sertifikaatin arvosta. En tarvitse todistusta tullakseni harjoittelevaksi ohjelmistosuunnittelijaksi Yhdysvalloissa tai Euroopassa, toisin kuin useimmat muut ammatit. Hienoa, sanokaa jotkut. Ainutlaatuinen hakkeri-kulttuurimme muuttaa maailmaa. Elämme tai kuolemme koodaustaitojemme perusteella, ei jonkin kuivuneen laitoksen mielipiteen perusteella meistä. Boo, sano muut. Fly-by-night -koodaajat tuottavat epätyypillisiä koodeja ja dokumentoimattomia, joustamattomia järjestelmiä, jotka eivät usein ole riittävän vankkoja.
Molemmilla leireillä on päteviä argumentteja. Mutta mielipiteeni on selkeä: näen arvon alan tukemissa sertifikaateissa. Ja kun kaikki muut asiat ovat tasa-arvoisia, arvostan sertifioitua J2EE-arkkitehtiä enemmän kuin sertifioimattoman arkkitehdin. Heikkoja sertifioimattomia arkkitehteja on paljon enemmän kuin heikkoja Sun-sertifioituja arkkitehteja.
Mikä tentti on
Olkaamme tylsät: J2EE-arkkitehdin sertifiointikokeet ovat erittäin hyvä tapa erottaa ansioluettelosi. Ehdokkaat, jotka varmistavat jatkuvasti, että heillä on vauhtia uusimpaan tekniikkaan ja joilla on keskeiset sertifikaatit valitsemastaan tekniikasta, ovat hyvin motivoituneita ihmisiä, jotka lisäävät arvoa yrityksilleen sekä yksilöinä että tiimipelaajina. Kuten Sunin Cade sanoo: "Sertifikaatin avulla voit saada jalkasi oveen. Esimerkiksi, jos rekrytoijat katsovat kahta ehdokasta arkkitehdiksi, ja toisella on sertifikaatti ja toisella ei, kenen luulet menevän harkita ensin? "
Todellisuudessa voi olla hauskaa työskennellä kohti sertifiointia. Oletko koskaan halunnut tutkia tietyn osan Unified Modeling Language (UML) - tai Enterprise JavaBeans (EJB) -määrityksistä tai halunnut päivittää suunnittelumalliin, jota et ole käyttänyt vähään aikaan? Käytin sertifikaatin tarkistamisaikaani tehdäkseni paremman arkkitehdin. Esimerkiksi osassa 2 annoin minun arvioida UML-mallinnustyökaluja, joita minulla oli ollut kutinaa kokeilla, kun taas osa 1 antoi minulle mahdollisuuden lujittaa yrityksen integraation näkökohtia, joita en ollut aiemmin käyttänyt, kuten näytön kaapiminen ja perintöintegrointi. J2EE-sertifikaatti ei todellakaan ole helppoa - se on kovaa työtä. Mutta jos haluat olla J2EE-arkkitehti, nautit sertifiointiprosessista. Todellinen saavutustunne on, kun läpäiset kokeen.
Mikä tentti ei ole
Kysyin Cadelta, mitä sertifikaatti ei voinut testata. Hänen vastauksensa pähkinänkuoressa: "Sertifikaatti ei korvaa kokemusta." Kuten Yoda saattaa sanoa, "yhtä tenttiä ei tehdä arkkitehti". Älä yritä käynnistää itseäsi J2EE-arkkitehdin sertifikaatiksi, jos sinulla ei ole taitoa asettaa sitä varmuuskopioimaan. Ensinnäkin kamppailet läpäisemään kokeen, ja toiseksi J2EE-arkkitehdiksi tuleminen on soveltava taito; jos sinulla ei ole taitotietoa, sinut paljastetaan nopeasti.
Toinen asia on, että arkkitehti tentti eroaa hienovaraisesti Sunin muista Java-sertifikaateista. "Arkkitehdin tentti on abstraktimpi, aivan kuten arkkitehtuuri onkin. Ohjelmoija testaa, ymmärtääkö henkilö kielen. Kehittäjän tentti testaa, voiko henkilö soveltaa kieltä ongelman ratkaisemiseen. Ja arkkitehti tentti testaa, voiko henkilö käyttää hänen tietonsa arkkitehdille ratkaisun, jonka kehittäjä voisi toteuttaa ", Cade selittää.
Tyypillinen ehdokasprofiili
Tyypillinen menestyvä ehdokas jakautuu kahteen pääryhmään: vahvat vanhemmat insinöörit, jotka ovat jo kaikkien nimien arkkitehteja, ja vakiintuneet arkkitehdit, mahdollisesti muilta tekniikan aloilta, jotka käyttävät arkkitehdin sertifikaattia J2EE: n ristikoulutukseen tai yksinkertaistavat heidän J2EE-asiantuntemuksensa.
Java-taidot eivät ole ongelma onnistuneelle ehdokkaalle. Pikemminkin haasteena on näyttää, että voit suunnitella ja kommunikoida vankan ja oikean J2EE-ohjelmiston suunnittelun tietylle ongelmalle. Muita tärkeitä taitoja ovat kyky ymmärtää, että jokaiseen ongelmaan ei ole aina täydellinen vastaus, ja puolustaa ehdotettua suunnittelua johdonmukaisesti ja vakuuttavasti tutkijalle.
Tentin anatomia
Tentti on jaettu kolmeen osaan, joista jokainen on suunniteltu testaamaan taitojesi eri näkökohtia. Kuva 1 havainnollistaa tarvittavia vaiheita Sun-sertifioidun J2EE-arkkitehdin saamiseksi.
Osa 1
Osa 1 koostuu 48 monivalintakysymyksestä, jotka kattavat kaikki yrityssovellusten suunnittelun näkökohdat keskittyen voimakkaasti EJB-määrityksiin ja arkkitehtuuriin. Osa 1 testaa aiheita suunnittelumalleista EJB-spesifikaation ydinrajapintoihin. Sinun on tunnettava EJB sisältä ja ulkoa - erilaiset, niiden elinkaaret. Sinun on ymmärrettävä EJB-kontit ja mahdolliset EJB-karikot. Tarvitset myös vahvan käsityksen muista J2EE-tekniikoista, kuten JavaServer Pages (JSP), servletit, Java Database Connectivity (JDBC) ja XML-tuki. Opi tärkeimmät suunnittelumallit ja niiden ryhmittelyt; tunnistaa ne UML-allekirjoituksistaan. Yritysten välinen (B2B) -arkkitehtuurikysymys saattaa myös näkyä näkyvästi.
Sinun on läpäistävä osa 1 ennen siirtymistä osaan 2.
Osa 2
Osa 2 on kokeen sydän. Tässä osassa hakijoiden on toimitettava J2EE-pohjaiset ratkaisunsa tietylle liiketoimintaskenaarialle. Ilmeisistä syistä en voi paljastaa käytettyjä liiketoiminnan skenaarioita, riittää, kun sanon, että ne sisältävät sekä B2C (business-to-consumer) että B2B-näkökohdat. Täällä ei ole paljon valmistelutyötä; sinun on käytettävä vain käytännön taitojasi suunnitellaksesi J2EE-pohjainen ratkaisu. Selkeä viestintä on ratkaisevan tärkeää; sinun on vakuutettava tutkija, että tiedät mitä olet tekemässä. Älä oleta mitään. Kaikkien toimitettujen kaavioiden on oltava UML-yhteensopivia.
Osa 3
Osan 3 ehdokkaiden on vastattava sarjaan kysymyksiä, jotka koskevat osan 2 jättämistä. Nämä kysymykset tutkivat kykyäsi analysoida suunnittelua objektiivisesti ja varmistaa myös, että sinulla on perusteelliset tiedot ehdotetun järjestelmän avainkysymyksistä, mukaan lukien ylläpidettävyys, suorituskyky ja skaalautuvuus. Vastauksesi näihin kysymyksiin ovat saman tutkinnon vastaanottajan käytettävissä, joka korjaa osan 2 palautuksen, ja hän viittaa toimitetut vastaukset lähetettyyn ratkaisuun arvioidaksesi esseesi vastauksia.
Tentti vinkkejä
Mennään alas messinkipeleihin. Mitä neuvoja voin tarjota mahdollisille ehdokkaille? Tässä ovat tärkeimmät virheet, jotka olen nähnyt osien 2 ja 3 palautuksissa. En keskity osaan 1, koska se on yksinkertainen monivalintakohta; joko tiedät oikeat vastaukset tai et. Kuvassa 2 on esitetty sekä onnistuneiden että epäonnistuneiden tenttien lähetykset, jotka perustuvat tutkinnon suoraan palautteeseen J2EE-arkkitehtikokeen alusta lähtien.
Suosituimmat lähetysvirheet
- Kokeen kohta puuttuu kokonaan. Tentti on suunniteltu testaamaan taitojasi J2EE-arkkitehdinä. Kaikkien ponnisteluidesi tulee keskittyä tietyn liiketoimintaongelman ratkaisemiseen, eikä sinun tarvitse jäädä esoteeristen J2EE-ongelmien muttereihin. Toki, ota yhteyttä myös näihin kohtiin, mutta älä anna yrityksesi ratkaisun kärsiä tästä.
- Huolimaton lähetys. Sun odottaa ihmisten käyttävän 30-40 tuntia kokeen parissa. Tämän ajan kuluessa lähetyksesi eivät saa sisältää kirjoitusvirheitä, epäselviä UML-kaavioita, epätäydellisiä argumentteja / perusteluja ja puuttuvia suoritteita. Ole ylpeä ratkaisustasi ja varmista, että se on paras ponnistuksesi.
- Liian monimutkainen huomautus. Jotkut ehdokkaat menevät ylikuormitukseen ja muuttavat hyvin aidatun yritysjärjestelmän seuraavaksi Amazon.comiksi. Astu taaksepäin ja varmista, että lähetys on mahdollisimman yksityiskohtainen, mutta ei liian. Tarpeeton sisältö heikentää yleistä standardia ja vaikeuttaa tutkinnon suorittaneiden pisteiden antamista.
- Puutteelliset / puutteelliset vastaukset osaan 3. Monet ehdokkaat eivät yksinkertaisesti vaivaa tarpeeksi osaa 3 (esseekysymykset). Varmista, että annat täydelliset vastaukset ja varmuuskopioi ne viitteillä ehdotetun arkkitehtuurin tiettyihin osiin. Huomaa, että sovelluksesi ilmoittaminen on hienoa, koska se on J2EE-pohjainen, ei muodosta riittävää puolustusta järjestelmän vakio-ominaisuuksille, kuten skaalautuvuudelle, ylläpidettävyydelle ja suorituskyvylle.
Lopuksi, jos epäonnistut tentissä, opi virheistäsi. Jos uskot, että sinulla on oikea profiili ja epäonnistut huonon tenttitekniikan tai valmistautumisen takia, laita se taakse ja ryhmittele uudelleen. Kaikille palautuksille annetaan erittely siitä, mihin pistemäärät on annettu ja vähennetty. Käytä tätä tunnistaaksesi lähetyksesi heikkoudet. Kun olet korjannut nämä heikkoudet, lähetä se uudelleen.
Tarkastellaan kääntöpuolella onnistuneiden lähetysten yhteisiä piirteitä.
Onnistuneet lähetysominaisuudet
- Oikea valmistelu ja riittävä aika lähetyksiin. Menestyneet ehdokkaat ymmärtävät, mitä heitä pyydetään toimittamaan, ja tekevät sen sitten. Se on niin yksinkertaista. Hyvä tekniikka osalle 2 on kysyä jatkuvasti itseltäsi, työskenteletkö sinun pitäisi olla. Pysy kurinalaisena. Ymmärrä kysymykset ja pysy tiellä.
- Selkeät, ytimekkäät huomautukset. Onnistuneiden lähetysten pituus voi vaihdella, mutta sisältö riippuu siitä, läpäisetkö vai epäonnistutko. Hyödyllinen vinkki on pelata paholaisen puolestapuhujaa jokaisessa lähetysosastossasi. Missä heikot kohdat ovat? Jos et olisi kirjoittanut sitä, ymmärrätkö sen? Pyydä kollegaa tarkistamaan ratkaisusi ennen sen lähettämistä. On hämmästyttävää, mitä toinen silmäpari voi saada kiinni.
Mitä tulee osaan 2, älä pidä kiinni siitä, mitä mallinnustyökalua käytät määritettyjen UML-suoritteiden luomiseen. Selkeyden ja oikeellisuuden tulisi olla päätavoitteitasi. Kaikki valitsemasi työkalut ovat kunnossa, kunhan noudatat määritettyjä suoritteita (esim. Tarjoat pääsivun index.html).
Tulevat tentit
Kun otetaan huomioon J2EE: n ja sen sisältämien tekniikoiden edistyminen, myös itse arkkitehtikokeet on tarkistuksessa. Päivitetty tentti kattaa J2EE 1.4, J2EE-suunnittelumallit, Java Connector Architecture (JCA) ja suunnittelumenetelmät, kuten Rational Unified Process (RUP) ja extreme-ohjelmoinnin (XP). Muut suunnitellut laajennukset nykyiseen muotoon sisältävät palautemekanismin, jonka avulla tutkijat voivat kysyä ehdokkailta arkkitehtuurinsa tiettyjä kohtia.
Uudistettu koe ei sisällä henkilökohtaisia haastatteluja mahdollisten ehdokkaiden kanssa. Kuten Cade sanoo: "Suuri osa arkkitehdistä on mahdollisuus kommunikoida ideasi kirjallisesti ja suullisesti. Voimme kaapata viestinnän kirjallisen osan, mutta emme voi arvioida ehdokkaita heidän sanallisista kyvyistään. Siksi työnantajilla on oltava perusteellinen haastattelu prosessi."
Mielenkiintoinen ilmiö on, että osaan 2 viime vuoden aikana toimitetut ratkaisut ovat muuttuneet, vaikka tentti itsessään ei ole. Verkkopalvelujen tulo ja siirtyminen kohti modulaarisempaa, palveluihin perustuvaa lähestymistapaa arkkitehtuuriin yleensä heijastuu ehdokkaiden esittämiin ratkaisutyyppeihin. Se edustaa minulle yhtä arkkitehtikokeen todellisista arvoista. Se pysyy edelleen merkityksellisenä, vaikka suositut tekniikat ja taustalla olevat tekniikat muuttuvat ja kypsyvät.
Ota kantaa
Toivottavasti sinulla on nyt selkeämpi käsitys Sunin J2EE-arkkitehtien sertifioinnista ja ymmärrät, miksi mielestäni kannattaa jatkaa. Se on kovaa työtä, mutta palkinto on, että onnistuneen valmistumisen jälkeen sinusta tulee parempi arkkitehti. Arkkitehtikoketta tarkistetaan parhaillaan, jotta se pysyisi J2EE-alustan mukana, ja Sun on tyytyväinen panokseesi kokeen sisältöön ja rakenteeseen.
Jos sinulla on ideoita kokeen parantamisesta, haluaisin kuulla ne. Käytä JavaWorld palautelomake (katso Resurssit) lähettääksesi meille ajatuksiasi. Se on hieno tapa vaikuttaa arkkitehtien sertifiointiprosessin seuraavaan vaiheeseen.
Seuraavassa Resurssit-osiossa on hyödyllisiä linkkejä pääsyn aloittamiseen. Tentti ei korvaa käytännön arkkitehtuurikokemusta, mutta se on erinomainen täydennys tälle kokemukselle, varsinkin jos hyväksyt sertifiointityön mahdollisuutena täyttää aukkosi tietämyksessäsi. Jos työskentelet parhaillaan kohti tenttiä, onnea! Jos et ole, miksi et?
