Programmering

Få innsiden av J2EE-arkitekt-sertifisering

For mer enn to år siden meldte jeg meg frivillig som betatester for Sun Microsystems Certified Enterprise Architect for J2EE (Java 2 Platform, Enterprise Edition) Technology eksamen. Jeg så på den planlagte læreplanen og så verdien i sertifiseringen, så jeg bestemte meg for å gå for den. Fire måneder og mye hardt arbeid senere mottok jeg sertifikatet og merket i posten, nesten som om jeg hadde blitt med i en veldig utvalgt fanklubb! Var det verdt det? Med et ord, ja. Mitt rette mål var sertifisering, men jeg ble positivt overrasket over at sertifiseringsprosessen åpnet øynene mine for ideer og tilnærminger jeg rett og slett ikke hadde hatt tid til å undersøke i kjas og mas i jobben min. Jeg fortsetter å engasjere meg med Sun om eksamensinnholdet og strukturen og er for tiden en sensor for testen. I denne artikkelen deler jeg mine erfaringer og plukker også hjernen til Mark Cade, hovedutvikler av Suns J2EE arkitekteksamen. Hvis du vil bli en Sun-sertifisert J2EE-arkitekt, kan du lese videre.

Hvorfor bli sertifisert?

Enkelt sagt, enhver sertifisering er bare like god som det tildelende organet. I vårt tilfelle er det utdelende organet Sun, selskapet bak J2EE. Det gjør sertifiseringen av støpejern i boka mi. Mange andre sertifiseringer er tilgjengelige fra forskjellige Java-leverandører, men Sun ønsker å sertifisere og godkjenne arkitekter for J2EE-plattformen, ikke for applikasjonsserveren X, Y eller Z.

Generelt sett diskuteres imidlertid verdien av sertifisering - enten fra et universitet eller et selskap - i vår bransje. Jeg trenger ikke et sertifikat for å bli praktiserende programvareingeniør verken i USA eller i Europa, i motsetning til de fleste andre yrker. Flott, sier noen. Vår unike hackerkultur endrer måten verden fungerer på. Vi lever eller dør av våre kodingsferdigheter, ikke av en eller annen tørket institusjon som mener oss. Boo, sier andre. Fly-by-night-kodere produserer ikke-standardkode og udokumenterte, ufleksible systemer som ofte ikke er robuste nok.

Begge leirene har gyldige argumenter. Men min mening er klar: Jeg ser verdien i bransjesponserte sertifiseringer. Og alt annet likt, vurderer jeg en sertifisert J2EE-arkitekt høyere enn en usertifisert arkitekt. Det er langt flere svake usertifiserte arkitekter enn svake solsertifiserte arkitekter.

Hva eksamen er

La oss være sløve: J2EE-arkitekt sertifiseringseksamen er en veldig god måte å skille ditt CV på. Kandidater som kontinuerlig sørger for at de er oppdatert på den nyeste teknologien og har sentrale sertifiseringer i de valgte teknologiene, er godt motiverte mennesker som tilfører verdi til selskapene, både som enkeltpersoner og som lagspillere. Som Sun's Cade sier, "Sertifisering gjør at du kan få foten inn døren. Hvis for eksempel rekrutterere ser på to kandidater for en arkitektstilling, og den ene har sertifisering og den andre ikke, hvem tror du de skal til vurdere først? "

Det kan faktisk være morsomt å jobbe mot sertifisering. Har du noen gang ønsket å undersøke en bestemt del av Unified Modeling Language (UML) eller Enterprise JavaBeans (EJB) -spesifikasjonen, eller ønsket å oppdatere deg på et designmønster du ikke har brukt på en stund? Jeg brukte sertifiseringstiden for å gjøre meg selv til en bedre arkitekt. Del 2 lot meg for eksempel evaluere UML-modelleringsverktøy jeg hadde kløe for å prøve, mens del 1 ga meg muligheten til å benke meg over bedriftsintegrasjonsaspekter jeg ikke hadde brukt før, som skjermskraping og eldre integrering. J2EE-sertifisering er definitivt ikke lett - det er hardt arbeid. Men hvis du liker å være J2EE-arkitekt, vil du glede deg over sertifiseringsprosessen. Det er en ekte følelse av prestasjon når du bestå eksamen.

Hva eksamen ikke er

Jeg spurte Cade hva sertifiseringen ikke kunne teste. Hans svar i et nøtteskall: "Sertifisering er ikke en erstatning for erfaring." Som Yoda kan si, "en eksamen gjør ikke en arkitekt." Ikke prøv å starte en J2EE-arkitekt-sertifisering hvis du ikke har ferdighetene til å sikkerhetskopiere det. For det første vil du slite med å bestå eksamen, og for det andre er det å være en J2EE-arkitekt en anvendt ferdighet; hvis du ikke har kunnskapen, blir du raskt utsatt.

Et annet poeng er at arkitekteksamen er subtilt forskjellig fra Suns andre Java-sertifiseringer. "Arkitekteksamen er mer abstrakt, akkurat som arkitektur er. Programmeringseksamenene tester om en person forstår språket. Utviklereksamen tester om en person kan bruke språket for å løse et problem. Og arkitekteksamen tester om en person kan bruke sin kunnskap til å arkitektere en løsning som en utvikler kan implementere, forklarer Cade.

Typisk kandidatprofil

Den typiske vellykkede kandidaten faller inn i to hovedgrupper: sterke senioringeniører som allerede er arkitekter i alt annet enn navn og veletablerte arkitekter, muligens fra andre teknologifag, som bruker arkitekt-sertifiseringen til å krysse tog til J2EE, eller bare pusse opp på deres J2EE-ekspertise.

Java-ferdigheter vil ikke være et tema for en vellykket kandidat. Snarere er utfordringen å vise at du kan utvikle og kommunisere en robust og korrekt J2EE programvaredesign for et gitt problem. Andre viktige ferdigheter inkluderer evnen til å forstå at det ikke alltid er et perfekt svar for hvert gitte problem, og til å forsvare det foreslåtte designet sammenhengende og sammenhengende til en sensor.

Eksamen anatomi

Eksamen er delt inn i tre seksjoner, hver designet for å teste et annet aspekt av ferdighetene dine. Figur 1 illustrerer de nødvendige trinnene for å bli en Sun-sertifisert J2EE-arkitekt.

Del 1

Del 1 består av 48 flervalgsspørsmål som dekker alle aspekter av bedriftsapplikasjonsdesign med sterkt fokus på EJB-spesifikasjonen og arkitekturen. Del 1 tester deg om emner fra designmønstre til EJB-spesifikasjonens kjernegrensesnitt. Du må kjenne EJB innvendig og utvendig - de forskjellige typene, deres livssyklus. Du må forstå EJB-containere og potensielle EJB-fallgruver. Du trenger også en god forståelse av andre J2EE-teknologier som JavaServer Pages (JSP), servlets, Java Database Connectivity (JDBC) og XML-støtte. Lær de viktigste designmønstrene og deres grupperinger; gjenkjenne dem fra deres UML-signaturer. Business-to-business (B2B) arkitekturspørsmål kan også være viktig.

Du må bestå del 1 før du går til del 2.

Del 2

Del 2 er hjertet i eksamen. I denne delen må kandidater sende inn sine J2EE-baserte løsninger for et gitt forretningsscenario. Av åpenbare grunner kan jeg ikke avsløre de faktiske forretningsscenariene som brukes, det er nok å si at de inneholder både B2C (business-to-consumer) og B2B aspekter. Det er ikke mye prep-arbeid som kan gjøres her; du må bare bruke dine praktiske ferdigheter til å utvikle en J2EE-basert løsning. Tydelig kommunikasjon er avgjørende; du må overbevise sensoren om at du vet hva du gjør. Ikke anta noe. Alle leverte diagrammer må være UML-kompatible.

Del 3

I del 3 må kandidatene svare på en serie spørsmål om deres del 2-innleveringer. Disse spørsmålene undersøker din evne til å analysere designet objektivt, og sørger også for at du har inngående kunnskap om det foreslåtte systemets sentrale aspekter, inkludert vedlikeholdsevne, ytelse og skalerbarhet. Svarene dine på disse spørsmålene vil være tilgjengelig for den samme sensoren som korrigerer del 2-innleveringen din, og han vil kryssreferanse leverte svar med den innsendte løsningen for å evaluere dine essaysvar.

Eksamenstips

La oss komme ned til messingstiftene. Hvilke råd kan jeg gi potensielle kandidater? Her er de beste feilene jeg har sett i innleveringer av del 2 og del 3. Jeg fokuserer ikke på del 1, da det er en enkel flervalgsdel; enten vet du de riktige svarene, eller ikke. Figur 2 viser de viktigste aspektene ved både vellykkede og mislykkede eksamensinnleveringer, basert på tilbakemelding fra direkte sensor siden J2EE arkitekteksamen ble lansert.

Topp innsendingsfeil

  1. Mangler helt poenget til eksamen. Eksamen er designet for å teste dine ferdigheter som J2EE-arkitekt. All din innsats bør fokusere på å løse det gitte forretningsproblemet og ikke være fast i muttere og bolter av esoteriske J2EE-problemer. Visst, vær så snill å ta opp disse punktene også, men ikke la forretningsløsningen din lide som et resultat.
  2. Slurvete innleveringer. Sun forventer at folk skal bruke mellom 30 og 40 timer på å jobbe på eksamen. Med den tiden skal ikke innleveringene dine inneholde skrivefeil, uklare UML-diagrammer, ufullstendige argumenter / begrunnelser og manglende leveranser. Vær stolt av løsningen din og sørg for at det er din beste innsats.
  3. Altfor komplekse innleveringer. Noen kandidater går overdrive og gjør et godt inngjerdet enterprise-system til neste Amazon.com. Gå tilbake og sørg for at innleveringen din er så detaljert som mulig, men ikke altfor så. Overflødig innhold forringer den generelle standarden og gjør det vanskeligere for sensoren din å gi karakter.
  4. Ufullstendige / utilstrekkelige svar for del 3. Mange kandidater legger rett og slett ikke nok innsats i del 3 (essayspørsmålene). Sørg for at du gir komplette svar og sikkerhetskopier dem med referanser til bestemte deler av den foreslåtte arkitekturen. Og vær oppmerksom på at det å si at applikasjonen din er flott fordi den er J2EE-basert, ikke utgjør et tilstrekkelig forsvar for standard systemegenskaper, som skalerbarhet, vedlikeholdsevne og ytelse.

Til slutt, hvis du ikke bestått eksamen, kan du lære av feilene dine. Hvis du mener at du har den rette profilen og at du mislyktes på grunn av dårlig eksamensteknikk eller forberedelse, må du legge den bak deg og omgruppere. Alle innleveringer får en oversikt over hvor karakterene er tildelt og trukket. Bruk dette til å identifisere innsendingssvakhetene dine. Når du har løst disse svakhetene, sender du den inn på nytt.

La oss se på de vanlige egenskapene til vellykkede innleveringer på baksiden.

Vellykkede innsendingsegenskaper

  1. Riktig forberedelse og tilstrekkelig tid brukt på innleveringer. Vellykkede kandidater forstår hva de blir bedt om å gi, og gjør det deretter. Det er så enkelt. En god teknikk for del 2 er å kontinuerlig spørre deg selv om du jobber med det du burde være. Fortsett disiplinert. Forstå spørsmålene og hold deg på sporet.
  2. Tydelige, kortfattede innleveringer. Vellykkede innsendinger kan variere i lengde, men innholdet avgjør om du består eller ikke bestått. Et nyttig tips er å spille djevelens advokat med hver del av innsendingen din. Hvor er svake punkter? Hvis du ikke hadde skrevet det, ville du forstå det? Be en kollega om å vurdere løsningen før du sender den inn. Det er utrolig hva et par andre øyne kan fange.

Når det gjelder del 2, ikke la deg henge på hvilket modelleringsverktøy du bruker for å generere de angitte UML-resultatene. Klarhet og korrekthet bør være hovedmålene dine. Ethvert verktøy du velger, er greit så lenge du holder deg til de angitte resultatene (for eksempel å oppgi en hovedindeks.html-side).

Fremtidige eksamener

Som reflekterer fremdriften J2EE og dens teknologier fortsetter å gjøre, er arkitekteksamen selv under revisjon. Den oppdaterte eksamenen vil dekke J2EE 1.4, J2EE designmønstre, Java Connector Architecture (JCA) og designmetoder som Rational Unified Process (RUP) og ekstrem programmering (XP). Andre planlagte utvidelser av det nåværende formatet inkluderer en tilbakemeldingsmekanisme som gjør det mulig for eksaminatorer å spørre kandidater om spesifikke punkter i arkitekturen.

Den fornyede eksamen vil ikke innebære ansikt til ansikt-intervjuer med potensielle kandidater. Som Cade sier, "Mye av å være arkitekt er å kunne kommunisere ideene dine skrevet og muntlig. Vi kan fange den skriftlige delen av kommunikasjonen, men vi kan ikke vurdere kandidater på deres verbale evner. Dette er grunnen til at arbeidsgivere må ha et grundig intervju prosess."

Et interessant fenomen er at løsningene som ble sendt inn for del 2 det siste året har endret seg selv om selve eksamen ikke har gjort det. Fremveksten av webtjenester og et skritt mot en mer modulær, tjenestedrevet tilnærming til arkitektur generelt gjenspeiler seg i den type løsninger kandidater sender inn. Det representerer for meg en av arkitekteksamenens virkelige verdier. Det fortsetter å forbli relevant selv om de foretrukne teknikkene og underliggende teknologiene forandrer seg og modnes.

Si din mening

Forhåpentligvis har du nå en klarere følelse av Suns J2EE-arkitekt-sertifisering og forstår hvorfor jeg tror det er vel verdt å forfølge. Det er hardt arbeid, men belønningen er at etter vellykket gjennomføring blir du en bedre arkitekt. Arkitekteksamen revideres for øyeblikket for å holde tritt med J2EE-plattformen, og Sun ønsker dine innspill til eksamenens innhold og struktur velkommen.

Hvis du har noen ideer om hvordan du kan forbedre eksamen, vil jeg gjerne høre dem. Bruke JavaWorld tilbakemeldingsskjema (se Ressurser) for å sende oss dine tanker. Det er en fin måte å bidra til å påvirke neste fase av arkitekt-sertifiseringsprosessen.

Ressursdelen nedenfor inneholder nyttige lenker for å komme i gang. Eksamen er ingen erstatning for praktisk arkitektonisk erfaring, men det er et flott supplement til den opplevelsen, spesielt hvis du omfavner sertifiseringsarbeidet som en mulighet til å fylle hull i kunnskapen din. Hvis du for tiden jobber mot eksamen, lykke til! Hvis ikke, hvorfor ikke?

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