En Java-utviklers typiske oppgaver på et prosjekt

Hva er de typiske ansvarsområdene til en Java-utvikler? Tross alt må du forstå hva du får deg til og hva du vil ende opp med å gjøre, ikke sant? I dag vil jeg snakke om ti viktige oppgaver som en Java-utvikler utfører. Men først, la oss bli kjent med et verktøy som heter Jira. Eller frisk opp minnet om det, hvis du allerede er kjent med det. Jiraer et verktøy for å organisere menneskelig interaksjon, selv om det i noen tilfeller også brukes til prosjektledelse. Et prosjekt er med andre ord brutt ned i små oppgaver som er beskrevet i dette verktøyet. Disse oppgavene er tildelt utviklerne, som er ansvarlige for gjennomføringen av dem. En oppgave kan for eksempel være å legge til noe funksjonalitet. Når en oppgave utføres, legger utviklere og andre spesialister til kommentarer om hvem som gjorde hva og hvor mye tid de brukte. Dette gjøres for tidssporingsformål - for å vite hvor mye tid som ble brukt på hvilke oppgaver. Ideelt sett gjøres dette en gang om dagen: Før du forlater skrivebordet om kvelden, angir du hvor mye av dine 8 arbeidstimer du brukte på ulike oppgaver. Det er mye mer ved Jiras funksjonalitet enn det som er beskrevet ovenfor, men dette vil være nok for en innledende forståelse.

1. Designe nye løsninger

Før du lager og implementerer noe, må du konseptualisere det, ikke sant? Som jeg sa før, kan dette ganske enkelt være en oppgave i Jira som blir tildelt deg, så du jobber med å designe en ny løsning, registrerer i Jira hvor mye tid du brukte og på hva. Dette arbeidet kan også skje under en diskusjon på en teamkonferansesamtale: alle kan si sin mening og foreslå den tilnærmingen de anser best. Og her vil jeg nevne noen få punkter. For det første er programvareutvikling et veldig kreativt yrke, siden du må bruke standardverktøy for å komme opp med nye måter å løse problemer på. En oppgave kan ofte ha mange ulike løsninger. Følgelig avhenger alt av utviklerens kreativitet, som er sterkt påvirket av deres akkumulerte kunnskap og erfaring. Du kan vise frem all din kreativitet og genialitet her, men det viktigste er å ikke overdrive det. Hvis du gjør det, vil koden bli for kompleks og uleselig. Som et resultat, etter at du drar, vil ingen helt forstå hva du kodet og hvordan det fungerer. Og de må skrive om alt fra bunnen av. Og de kan mimre om deg. Mer enn en gang. Og det er usannsynlig at det blir sagt varme, vennlige ord. Trenger du det? For det andre må en utvikler beholde psykologisk fleksibilitet i den forstand at du ikke skal klamre deg til en enkelt løsning og bli lukket for andre. Som om du bare må gjøre noe på én måte og det ikke finnes andre alternativer. Du kan falle i denne fellen av forskjellige grunner. Anta for eksempel at du vil bevise at synspunktet ditt er riktig. Eller kanskje du allerede har designet og implementert din egen kjente løsning – selvfølgelig, du vil ikke innrømme at det ikke er det beste. Disse situasjonene kan gjøre deg ganske blind. Faktisk må du kunne innrømme feilene dine og alltid være åpen, selv om du må fjerne funksjonalitet du er stolt av og har kodet i mer enn en uke. Jeg husker hvordan en kollega lyste opp alles dag en gang ved å legge igjen denne tidsregistreringskommentaren i Jira: "Jeg fjernet mitt dødfødte trekk. Og sørget."

2. Skrive ny funksjonalitet

Dette trinnet – implementering av ny funksjonalitet – følger logisk etter det forrige. Alt arbeid involvert i et prosjekt er delt inn i oppgaver i Jira, som deretter deles ut til utviklere basert på deres arbeidsmengde. Det er forskjellige tilnærminger til denne prosessen, kjent som "metodologier", som du kan lese mer om i denne artikkelen på CodeGym . Som regel har oppgaver et estimat, som er den anslåtte tiden det tar å fullføre dem. Den settes enten av deg, utvikleren når du mottar oppgaven, eller av teamlederen, eller under planleggingen, i fellesskap av utviklingsteamet. Denne gangen er svært sjelden nøyaktig, siden så mange forskjellige faktorer påvirker programvareutvikling. For eksempel, om en programmerer er kjent eller ukjent med den relevante teknologien, hans eller hennes generelle erfaring, ulike uforutsette fallgruver, osv. Så hvis du ikke treffer alle tidsanslagene dine når du koder, er det ikke verdens undergang. Dette er bare generelle anslag. Når det er sagt, ikke alle prosjekter krever tidsestimering. Personlig synes jeg det er mye lettere å leve uten, spesielt når statsministeren ikke plager meg et par ganger om dagen med spørsmålet "hvor er tidsanslagene dine?" Så du får en oppgave,Klar for gjennomgang " i Jira og be om at kodeendringene dine ikke blir returnert for revisjon sammen med kommentarer.

3. Skrive prøver

Anmelderen, altså personen som sjekker koden din, liker funksjonaliteten du implementerte, men hun har et spørsmål til deg: hvor er tilhørende tester? Så hun sender oppgaven tilbake til deg for revisjon. Tester er en viktig del av enhver Java-applikasjon. Ved å kjøre tester kan du umiddelbart identifisere steder hvor applikasjonen ikke fungerer som den skal. For eksempel gjør en utvikler noen endringer i en del av systemet, noe som resulterer i endringer i atferd i en annen del, men han la ikke merke til dette under kodingen. Ved å kjøre testene vil han kunne se at visse tester mislyktes, noe som betyr at de ikke ga de forventede resultatene. Dette forteller ham at noe er ødelagt et annet sted i systemet. Når han vet dette, vil han ikke begå de brytende endringene på serveren, og vil i stedet fortsette å jobbe med å feilsøke koden sin. Ja, ganske få utviklere elsker å skrive tester, men det er ikke å nekte for fordelene de gir til programvareutvikling. Klientene selv angir ofte nivået på testdekningen de ønsker å opprettholde (for eksempel 80 %). Det betyr at du trenger å vitede ulike prøvetypene og kunne skrive dem. Java-utviklere skriver hovedsakelig enhetstester og integrasjonstester, mens de mer omfattende (ende-til-ende) testene håndteres av QA- og testautomatiseringseksperter.

4. Finne og fikse feil

Dette er også en veldig vanlig, hyppig oppgave for Java-utviklere. Hovedoppgaven til QA- og testautomatiseringseksperter er å fange feil. De ser med andre ord etter steder hvor programmet oppfører seg feil, så lager de oppgaver i Jira og tildeler dem til noen. For eksempel til en teamleder, som på sin side bestemmer hvilke utviklere de skal tildeles, avhengig av deres arbeidsmengde og kjennskap til de relevante delene av systemet. Etter det leter den tildelte utvikleren opp årsaken til feilen, og bruker timer i en debugger, ved å bruke feilbeskrivelsen gitt av QA-ekspertene for å gjengi forholdene der feilen oppstår. Når utvikleren finner feilen og fikser den, sender han rettelsen til vurdering. Noen ganger klarer ikke utvikleren å reprodusere feilen, så han sender oppgaven tilbake til QA-eksperten sammen med en forklarende kommentar. Det virker som det ikke bør ta lang tid å finne og fikse en feil, men det er noen nyanser. Det hele avhenger hovedsakelig av hvor godt kjent utvikleren er med denne delen av koden, og på hans erfaring og teoretiske kunnskap. Noen ganger kan en feil bli funnet og fikset på 20 minutter, og noen ganger kan det ta tre dager. Dette betyr at denne typen oppgaver er spesielt vanskelig å estimere på forhånd, med mindre utvikleren, etter å ha lest beskrivelsen, umiddelbart forstår hva, hvor og hvordan av feilen. I dette tilfellet,

5. Kodegjennomgang

Som nevnt ovenfor, så snart du har fullført en oppgave, skal den sendes til vurdering. Hvis den består anmeldelsen, går den inn i hovedgrenen. Hvis ikke, returneres den til utbygger med kommentarer som må tas opp. Selvfølgelig forstår du at koden din blir sjekket av andre utviklere, ikke av noen høy kraft. Når det er sagt, er det ikke alle som har lov til å utføre kodevurderinger - bare de mest erfarne utviklerne herdet av praksis i den virkelige verden, som kan se forskjellen mellom god kode og dårlig kode. Kodegjennomganger utføres vanligvis ved hjelp av et hjelpeverktøy som Crucible. Anmeldere går gjennom koden og legger om nødvendig kommentarer om enkelte linjer. Det kan være ulike typer kommentarer. Noen er for eksempel kritiske. Hvis de ikke blir adressert, vil ikke anmelderen tillate at koden blir begått. Andre kommentarer er for eksempel bare bemerkninger om den valgte tilnærmingen. Disse kan utvikleren lytte til, notere seg eller ignorere. Et team kan lage sine egne regler og prosedyrer for kodegjennomganger, bli enige om hva som er verdt å være oppmerksom på og ikke, hvilken tidsramme som skal tildeles for å fullføre en kodegjennomgang osv. Erfaring alene er ikke nok til å gjennomføre en gjennomgang: du fortsatt trenger å vokse mye i dine tekniske ferdigheter og å lese forskjellige bøker (for eksempel "Ren kode").

6. Kodeanalyse

Siden flere som tenker annerledes skriver kode for prosjektet samtidig, vil koden og tilnærmingene deres være forskjellige. Og over tid blir alt gradvis til et rot. For å forbedre koden opprettes det noen ganger oppgaver for å for eksempel analysere en bestemt modul eller hele applikasjonen, finne og notere mangler, og senere lage en refaktoriseringsoppgave basert på denne analysen. En slik analyse hjelper også i situasjoner der teamet ikke kunne se noen enklere og mer konsise løsninger da utviklingen startet, men de ser dem nå. For eksempel er logikk ofte duplisert i noen metoder. Følgelig kan det trekkes ut i en egen metode, som deretter kan gjenbrukes mange ganger. Eller kanskje en klasse har blitt for oppblåst, eller en eller annen kode har blitt vanskelig å vedlikeholde eller utdatert, eller... Analyseoppgaver bidrar til å forbedre kvaliteten på koden og applikasjonen. Når det er sagt, for meg kan det være kjedelig å analysere en stor mengde kode.

7. Refaktoreringskode

Den neste delen av kodeanalysen er refaktorering. Kode kan være utdatert, foreldet, dårlig skrevet, vanskelig å lese, og så videre. Du bør alltid strebe etter perfeksjon (selv om den ikke eksisterer) og for den oppdaterte koden, fjerne alt overflødig, fordi det overflødige bare fører til forvirring og forstyrrer muligheten til å se hva koden gjør. Det sier seg selv at du neppe vil se disse oppgavene i begynnelsen av et prosjekt: du møter dem på senere stadier av utviklingen når applikasjonen poleres og bringes til perfeksjon. Her kan det være aktuelt å rådføre seg med kollegaer om hva de ville gjort og hvilke fallgruver de ser. I deres hjerte ligner slike oppgaver på å utvikle ny funksjonalitet. Anta for eksempel at du mottar en oppgave for å redigere funksjonalitet uten å endre virkemåten. For å gjøre dette, sletter du den gamle koden, skriver din egen og sjekker testene. Hvis du gjorde alt riktig, så uten å gjøre noen endringer i testene, skulle de alle bestå som før. Etter at alt i koden er som det skal være, sender vi den til gjennomgang, og drar en nipp til en kaffe :)

8. Skrive dokumentasjon

Tenk deg at du er en ny utvikler på et langsiktig programvareutviklingsprosjekt. Du må gjøre deg kjent med kodebasen eller utføre en spesifikk oppgave, for eksempel diagnostisere en feil. Hvordan vil du navigere i prosjektet? Plage lagkameratene dine hvert femte minutt? Og hva om de er opptatt eller det er helg, hva da? Det er nettopp derfor vi har dokumentasjon — slik at en person som ikke er kjent med koden kan komme inn, finne den aktuelle siden og raskt finne ut hva som foregår i den delen av søknaden som interesserer henne. Men noen må lage dokumentasjonen, haha. Hvis et prosjekt har dokumentasjon som utviklere må støtte, så når de implementerer ny funksjonalitet, beskriver de det og oppdaterer dokumentasjonen sammen med eventuelle kodeendringer eller refaktorisering. Du kan også ha situasjoner der en egen ansatt - en teknisk skribent - er ansatt for å skrive, vedlikeholde og føre tilsyn med dokumentasjonen. Hvis en slik spesialist er tilgjengelig, er livet til vanlige utviklere litt lettere.

9. Diverse møter

Mye av utviklernes tid går med til ulike møter, forhandlinger og planlegging. Det enkleste eksemplet er det daglige stand-up-møtet, hvor du skal rapportere hva du gjorde i går og hva du skal gjøre i dag. I tillegg må du ha en-til-en telefonsamtaler, for eksempel med testere, slik at de kan demonstrere/forklare nyansene ved å reprodusere en feil, eller diskutere finesser og krav med en forretningsanalytiker eller snakke om organisatoriske problemer med en PM. Dette betyr at selv om en utvikler kan være en introvert som foretrekker ensomhet, må hun fortsatt være i stand til å finne et felles grunnlag med andre mennesker (vel, i det minste litt). Jo høyere en utviklers rangering, jo mer tid trenger hun å bruke på kommunikasjon og jo mindre tid på å skrive kode. En utviklerlead kan bruke halvparten, eller enda mer, av arbeidsdagen sin på samtaler og møter alene og kan skrive kode sjeldnere (muligens føre til at han mister litt av kodingsevnen). Men hvis du bare elsker å snakke, kan du som teamleder gå over til ledelse og helt glemme å skrive kode, i stedet vil du bruke hele dagen på å kommunisere med ulike team, kunder og andre ledere.

10. Gjennomføre/bestå intervjuer

Hvis du jobber for et outsourcing- eller outstaffingsselskap, vil du ofte måtte gå gjennom eksterne intervjuer, hvor du må "selge" deg selv til klienten (du kan bli intervjuet av noen som jobber for klienten), så vel som interne å klatre i gradene i selskapet. Jeg vil kalle dette en god mulighet for vekst fordi de hyppige intervjuene vil tvinge deg til å holde kunnskapen skarp: du blir ikke rusten og myk. Tross alt, hvis du blir myk i IT, kan du falle helt ut av feltet. Etter hvert som du blir en mer erfaren utvikler, vil du kunne finne deg selv på den andre siden av bordet og gjennomføre intervjuer i stedet for å bestå dem. Tro meg, du vil bli veldig overrasket når du ser på det fra denne stillingen, fordi det å stille intervjuspørsmålene kan være skumlere enn å svare på dem. Du må ha din egen intervjustrategi, en liste med spørsmål og tid til å stille spørsmål om alle nødvendige emner på én time. Og etter det er du ansvarlig for å gi tilbakemeldinger som vil påvirke ansettelsesbeslutningen og om kandidaten får et etterlengtet tilbud eller forfremmelse. Eller du kan la en åpenbart svak kandidat få en stilling som hun ikke kvalifiserer for, og så kan du bli spurt, "hvordan kunne du tillate henne å bli ansatt i det hele tatt med det kunnskapsnivået"? Så når du er i det varme setet under et intervju, husk at personen foran deg også står overfor en utfordring og kan være stresset. du er ansvarlig for å gi tilbakemeldinger som vil påvirke ansettelsesbeslutningen og om kandidaten mottar et etterlengtet tilbud eller forfremmelse. Eller du kan la en åpenbart svak kandidat få en stilling som hun ikke kvalifiserer for, og så kan du bli spurt, "hvordan kunne du tillate henne å bli ansatt i det hele tatt med det kunnskapsnivået"? Så når du er i det varme setet under et intervju, husk at personen foran deg også står overfor en utfordring og kan være stresset. du er ansvarlig for å gi tilbakemeldinger som vil påvirke ansettelsesbeslutningen og om kandidaten mottar et etterlengtet tilbud eller forfremmelse. Eller du kan la en åpenbart svak kandidat få en stilling som hun ikke kvalifiserer for, og så kan du bli spurt, "hvordan kunne du tillate henne å bli ansatt i det hele tatt med det kunnskapsnivået"? Så når du er i det varme setet under et intervju, husk at personen foran deg også står overfor en utfordring og kan være stresset. Ethvert intervju er stressende for både kandidaten og intervjueren. Vi slutter nok her. Takk til alle som leser denne artikkelen. Legg igjen en like og fortsett å lære Java :)