En Java-udviklers typiske opgaver på et projekt

Hvad er de typiske ansvarsområder for en Java-udvikler? Når alt kommer til alt, skal du forstå, hvad du går ind til, og hvad du ender med at gøre, ikke? I dag vil jeg gerne tale om ti vitale opgaver, som en Java-udvikler udfører. Men lad os først stifte bekendtskab med et værktøj kaldet Jira. Eller genopfrisk din hukommelse om det, hvis du allerede er bekendt med det. Jiraer et værktøj til at organisere menneskelige interaktioner, selvom det i nogle tilfælde også bruges til projektledelse. Et projekt er med andre ord opdelt i små opgaver, som er beskrevet i dette værktøj. Disse opgaver er tildelt udviklerne, som er ansvarlige for deres implementering. En opgave kunne for eksempel være at tilføje noget funktionalitet. Efterhånden som en opgave udføres, tilføjer udviklere og andre specialister kommentarer om, hvem der gjorde hvad, og hvor meget tid de brugte. Dette gøres med henblik på tidsregistrering - for at vide, hvor meget tid der blev brugt på hvilke opgaver. Ideelt set gøres dette én gang om dagen: Inden du forlader dit skrivebord om aftenen, angiver du, hvor meget af dine 8 arbejdstimer du brugte på forskellige opgaver. Der er meget mere i Jiras funktionalitet end det, der er beskrevet ovenfor, men dette vil være nok til en indledende forståelse.

1. Design af nye løsninger

Før du skaber og implementerer noget, skal du konceptualisere det, ikke? Som jeg sagde før, kan dette simpelthen være en opgave i Jira, der bliver tildelt dig, så du arbejder på at designe en ny løsning, hvor du registrerer i Jira, hvor meget tid du brugte og på hvad. Dette arbejde kunne også ske under en diskussion på et teamkonferenceopkald: alle kan give udtryk for deres mening og foreslå den tilgang, som de anser for bedst. Og her vil jeg gerne bemærke et par punkter. For det første er softwareudvikling et meget kreativt erhverv, da du skal bruge standardværktøjer for at komme med nye måder at løse problemer på. Én opgave kan ofte have mange forskellige løsninger. Derfor afhænger alt af udviklerens kreativitet, som er stærkt påvirket af deres akkumulerede viden og erfaring. Du kan vise al din kreativitet og genialitet her, men det vigtige er ikke at overdrive det. Hvis du gør det, bliver koden for kompleks og ulæselig. Som et resultat, efter du har forladt, vil ingen fuldt ud forstå, hvad du kodede, og hvordan det fungerer. Og de bliver nødt til at omskrive alt fra bunden. Og de kan mindes om dig. Mere end en gang. Og det er usandsynligt, at der bliver sagt varme, venlige ord. Har du brug for det? For det andet skal en udvikler bevare psykologisk fleksibilitet i den forstand, at du ikke skal klamre dig til en enkelt løsning og blive lukket for andre. Som om man kun skal gøre noget på én måde, og der ikke er andre muligheder. Du kan falde i denne fælde af forskellige årsager. Antag for eksempel, at du vil bevise, at dit synspunkt er korrekt. Eller måske har du allerede designet og implementeret din egen velkendte løsning - selvfølgelig, du vil ikke indrømme, at det ikke er det bedste. Disse situationer kan gøre dig ret blind. Faktisk skal du kunne indrømme dine fejl og altid være åben, selvom du skal fjerne funktionalitet, som du er stolt af og har kodet i mere end en uge. Jeg kan huske, hvordan en kollega lysnede alles dag en gang ved at efterlade denne tidsregistrerende kommentar i Jira: "Jeg fjernede mit dødfødte træk. Og sørgede."

2. Skrivning af ny funktionalitet

Dette trin - implementering af ny funktionalitet - følger logisk efter det forrige. Alt arbejde involveret i et projekt er opdelt i opgaver i Jira, som derefter uddeles til udviklere baseret på deres arbejdsbyrde. Der er forskellige tilgange til denne proces, kendt som "metodologier", som du kan læse mere om i denne artikel på CodeGym . Som regel har opgaver et skøn, som er den forudsagte tid, det tager at gennemføre dem. Den indstilles enten af ​​dig, udvikleren, når du modtager opgaven, eller af teamlederen, eller under planlægningen, i fællesskab af udviklingsteamet. Denne gang er gæt meget sjældent præcist, da så mange forskellige faktorer påvirker softwareudvikling. For eksempel om en programmør kender eller ikke kender til den relevante teknologi, hans eller hendes overordnede erfaring, forskellige uforudsigelige faldgruber osv. Så hvis du ikke rammer alle dine tidsestimat ved kodning, er det ikke verdens undergang. Disse er blot generelle skøn. Når det er sagt, kræver ikke alle projekter tidsestimat. Personligt har jeg meget nemmere ved at leve uden det, især når PM ikke plager mig et par gange om dagen med spørgsmålet "hvor er dine tidsvurderinger?" Så får du en opgave,Klar til gennemgang " i Jira og bed til, at dine kodeændringer ikke bliver returneret til revision sammen med kommentarer.

3. Skrivning af prøver

Anmelderen, altså den person, der tjekker din kode, kan lide den funktionalitet, du implementerede, men hun har et spørgsmål til dig: hvor er tilknyttede tests? Så hun sender opgaven tilbage til dig til revision. Tests er en væsentlig del af enhver Java-applikation. Ved at køre test kan du med det samme identificere steder, hvor applikationen ikke fungerer korrekt. For eksempel laver en udvikler nogle ændringer i en del af systemet, hvilket resulterer i ændringer i adfærd i en anden del, men det lagde han ikke mærke til under kodningen. Ved at køre testene vil han være i stand til at se, at visse tests mislykkedes, hvilket betyder, at de ikke gav de forventede resultater. Dette fortæller ham, at noget er i stykker et andet sted i systemet. Når han ved dette, vil han ikke begå de ødelæggende ændringer til serveren, og vil i stedet fortsætte med at arbejde på at fejlfinde sin kode. Ja, ret få udviklere elsker at skrive test, men der er ingen tvivl om de fordele, de bringer til softwareudvikling. Klienter angiver ofte selv det niveau af testdækning, de ønsker at opretholde (f.eks. 80%). Det betyder, at du skal vide detde forskellige typer af tests og kunne skrive dem. Java-udviklere skriver hovedsageligt enhedstests og integrationstests, mens de mere omfattende (end-to-end) tests varetages af QA- og testautomatiseringseksperter.

4. Finde og rette fejl

Dette er også en meget almindelig, hyppig opgave for Java-udviklere. QA- og testautomatiseringseksperters hovedopgave er at fange fejl. Med andre ord leder de efter steder, hvor programmet opfører sig forkert, så laver de opgaver i Jira og tildeler dem til nogen. For eksempel til en teamleder, som på sin side beslutter, hvilke udviklere de skal tildeles, afhængigt af deres arbejdsbyrde og kendskab til de relevante dele af systemet. Derefter jagter den tildelte udvikler årsagen til fejlen og bruger timer i en debugger, ved at bruge fejlbeskrivelsen leveret af QA-eksperterne til at gengive de forhold, hvor fejlen opstår. Når udvikleren har fundet fejlen og rettet den, sender han rettelsen til gennemgang. Nogle gange er udvikleren ikke i stand til at reproducere fejlen, så han sender opgaven tilbage til QA-eksperten sammen med en forklarende kommentar. Det ser ud til, at det ikke skulle tage særlig lang tid at finde og rette en fejl, men der er nogle nuancer. Det hele afhænger hovedsageligt af, hvor godt udvikleren er bekendt med denne del af koden, og på hans erfaring og teoretiske viden. Nogle gange kan en fejl findes og rettes på 20 minutter, og nogle gange kan det tage tre dage. Dette betyder, at denne type opgave er særlig vanskelig at estimere på forhånd, medmindre udvikleren, efter at have læst beskrivelsen, straks forstår hvad, hvor og hvordan af fejlen. I dette tilfælde,

5. Kodegennemgang

Som nævnt ovenfor, så snart du har fuldført en opgave, skal den sendes til gennemgang. Hvis den består anmeldelsen, går den ind i hovedgrenen. Hvis ikke, returneres det til udvikleren med kommentarer, der skal behandles. Selvfølgelig forstår du, at din kode er kontrolleret af andre udviklere, ikke af en eller anden høj effekt. Når det er sagt, er det ikke alle, der har lov til at udføre kodegennemgange - kun de mest erfarne udviklere hærdet af praksis fra den virkelige verden, som kan kende forskel på god kode og dårlig kode. Kodegennemgange udføres normalt ved hjælp af et hjælpeværktøj såsom Crucible. Anmeldere gennemgår koden og efterlader om nødvendigt kommentarer om bestemte linjer. Der kan være forskellige slags kommentarer. For eksempel er nogle kritiske. Hvis de ikke behandles, vil anmelderen ikke tillade, at koden bliver begået. Andre kommentarer er f.eks. blot bemærkninger om den valgte tilgang. Disse kan udvikleren lytte til, notere sig eller ignorere. Et team kan lave sine egne regler og procedurer for kodegennemgange, blive enige om, hvad der er værd at være opmærksom på og hvad ikke, hvilken tidsramme der skal tildeles for at gennemføre en kodegennemgang osv. Erfaring alene er ikke nok til at gennemføre en gennemgang: du stadig har brug for at vokse meget i dine tekniske færdigheder og at læse forskellige bøger (for eksempel "Ren kode").

6. Kodeanalyse

Da flere mennesker, der tænker forskelligt, skriver kode til projektet samtidigt, vil deres kode og tilgange være forskellige. Og med tiden bliver alt gradvist til et rod. For at forbedre koden oprettes der nogle gange opgaver til fx at analysere et bestemt modul eller hele applikationen, finde og notere mangler og senere oprette en refaktoreringsopgave baseret på denne analyse. En sådan analyse hjælper også i situationer, hvor teamet, da udviklingen begyndte, ikke kunne se nogle enklere og mere kortfattede løsninger, men de ser dem nu. For eksempel er logik ofte duplikeret i nogle metoder. Det kan derfor udtrækkes til en separat metode, som derefter kan genbruges mange gange. Eller måske er en klasse blevet for oppustet, eller en eller anden kode er blevet svær at vedligeholde eller forældet, eller... Analyseopgaver er med til at forbedre kvaliteten af ​​koden og applikationen. Når det er sagt, kan det for mig være kedeligt at analysere en stor mængde kode.

7. Refaktoreringskode

Den næste del af kodeanalysen er refaktorering. Koden kan være forældet, forældet, dårligt skrevet, svær at læse og så videre. Du bør altid stræbe efter perfektion (selvom den ikke findes) og efter den opdaterede kode, fjerne alt overflødigt, fordi det overflødige kun fører til forvirring og forstyrrer evnen til at se, hvad koden gør. Det siger sig selv, at du næppe vil se disse opgaver i begyndelsen af ​​et projekt: du støder på dem på senere udviklingsstadier, når applikationen bliver poleret og bragt til perfektion. Her kan det være hensigtsmæssigt at rådføre sig med kollegerne om, hvad de ville gøre, og hvilke faldgruber de ser. I deres hjerte ligner sådanne opgaver at udvikle ny funktionalitet. Antag for eksempel, at du modtager en opgave for at redigere en funktionalitet uden at ændre dens adfærd. For at gøre dette skal du slette den gamle kode, skrive din egen og tjekke testene. Hvis du gjorde alt rigtigt, så skulle de alle bestå som før, uden at foretage ændringer i testene. Når alt i koden er, som det skal være, sender vi den til en gennemgang og tager en kop kaffe :)

8. Skrive dokumentation

Forestil dig, at du er en ny udvikler på et langsigtet softwareudviklingsprojekt. Du skal sætte dig ind i kodebasen eller udføre en bestemt opgave, for eksempel diagnosticere en fejl. Hvordan vil du navigere i projektet? Plage dine holdkammerater hvert femte minut? Og hvad hvis de har travlt, eller det er weekend, hvad så? Det er netop derfor, vi har dokumentation — så en person, der ikke er bekendt med koden, kan komme ind, finde den relevante side og hurtigt finde ud af, hvad der foregår i den del af ansøgningen, der interesserer hende. Men nogen skal lave dokumentationen, haha. Hvis et projekt har dokumentation, som udviklere skal understøtte, så beskriver de, når de implementerer ny funktionalitet, det og opdaterer dokumentationen sammen med eventuelle kodeændringer eller refactoring. Du kan også have situationer, hvor en separat medarbejder - en teknisk skribent - er ansat til at skrive, vedligeholde og føre tilsyn med dokumentationen. Hvis en sådan specialist er tilgængelig, er livet for almindelige udviklere lidt lettere.

9. Diverse møder

Meget af udviklernes tid bruges på forskellige møder, forhandlinger og planlægning. Det enkleste eksempel er det daglige stand-up møde, hvor du skal rapportere, hvad du lavede i går, og hvad du skal i dag. Derudover skal du have en-til-en telefonopkald, for eksempel med testere, så de kan demonstrere/forklare nuancerne ved at gengive en fejl, eller diskutere finesser og krav med en forretningsanalytiker eller tale om organisatoriske problemer med en PM. Det betyder, at selvom en udvikler kan være en introvert, der foretrækker ensomhed, skal hun stadig være i stand til at finde et fælles grundlag med andre mennesker (vel, i det mindste lidt). Jo højere en udvikler rang, jo mere tid skal hun bruge på kommunikation og jo mindre tid på at skrive kode. En dev-lead kan bruge halvdelen eller endda mere af sin arbejdsdag på samtaler og møder alene og kan skrive kode sjældnere (hvilket muligvis får ham til at miste lidt af sin kodningsevne). Men hvis du bare elsker at snakke, kan du som teamleder gå over til ledelse og helt glemme alt om at skrive kode, i stedet ville du bruge hele dagen på at kommunikere med forskellige teams, kunder og andre ledere.

10. Gennemførelse/beståelse af samtaler

Hvis du arbejder for en outsourcing- eller outstaffingvirksomhed, skal du ofte igennem eksterne samtaler, hvor du bliver nødt til at "sælge" dig selv til kunden (du kan blive interviewet af en, der arbejder for kunden), såvel som interne til at klatre op i graderne i virksomheden. Jeg vil kalde dette en god mulighed for vækst, fordi de hyppige interviews vil tvinge dig til at holde din viden skarp: du bliver ikke rusten og blød. Hvis du bliver blød i IT, kan du jo falde helt ud af feltet. Efterhånden som du bliver en mere erfaren udvikler, vil du være i stand til at finde dig selv på den anden side af bordet og gennemføre interviews i stedet for at bestå dem. Tro mig, du vil blive meget overrasket, når du ser på det fra denne stilling, for det kan være mere skræmmende at stille interviewspørgsmålene end at svare på dem. Du skal have din egen interviewstrategi, en liste med spørgsmål og tid til at stille spørgsmål om alle de nødvendige emner på en time. Og derefter er du ansvarlig for at give feedback, der vil påvirke ansættelsesbeslutningen, og om kandidaten modtager et længe ventet tilbud eller forfremmelse. Eller du kan måske tillade en åbenlyst svag kandidat at få en stilling, som hun ikke kvalificerer sig til, og så bliver du måske spurgt, "hvordan kunne du overhovedet tillade hende at blive ansat med det vidensniveau"? Så når du er i den varme stol under et interview, skal du huske på, at personen foran dig også står over for en udfordring og kan være stresset. du er ansvarlig for at give feedback, der vil påvirke ansættelsesbeslutningen, og om kandidaten modtager et længe ventet tilbud eller forfremmelse. Eller du kan måske tillade en åbenlyst svag kandidat at få en stilling, som hun ikke kvalificerer sig til, og så bliver du måske spurgt, "hvordan kunne du overhovedet tillade hende at blive ansat med det vidensniveau"? Så når du er i den varme stol under et interview, skal du huske på, at personen foran dig også står over for en udfordring og kan være stresset. du er ansvarlig for at give feedback, der vil påvirke ansættelsesbeslutningen, og om kandidaten modtager et længe ventet tilbud eller forfremmelse. Eller du kan måske tillade en åbenlyst svag kandidat at få en stilling, som hun ikke kvalificerer sig til, og så bliver du måske spurgt, "hvordan kunne du overhovedet tillade hende at blive ansat med det vidensniveau"? Så når du er i den varme stol under et interview, skal du huske på, at personen foran dig også står over for en udfordring og kan være stresset. Enhver samtale er stressende for både kandidaten og intervieweren. Vi slutter nok lige her. Tak til alle, der læste denne artikel. Giv et like og fortsæt med at lære Java :)