En Java-utvecklares typiska uppgifter i ett projekt

Vilka är de typiska ansvarsområden för en Java-utvecklare? När allt kommer omkring måste du förstå vad du ger dig in på och vad du kommer att göra, eller hur? Idag skulle jag vilja prata om tio viktiga uppgifter som en Java-utvecklare utför. Men först, låt oss bekanta oss med ett verktyg som heter Jira. Eller fräscha upp ditt minne av det, om du redan är bekant med det. Jiraär ett verktyg för att organisera mänskliga interaktioner, även om det i vissa fall även används för projektledning. Med andra ord är ett projekt uppdelat i små uppgifter som beskrivs i detta verktyg. Dessa uppgifter tilldelas utvecklarna, som ansvarar för genomförandet. En uppgift kan till exempel vara att lägga till någon funktionalitet. När en uppgift utförs lägger utvecklare och andra specialister till kommentarer om vem som gjorde vad och hur mycket tid de spenderade. Detta görs i tidsspårningssyfte - för att veta hur mycket tid som spenderades på vilka uppgifter. Helst görs detta en gång om dagen: Innan du lämnar ditt skrivbord på kvällen anger du hur mycket av dina 8 arbetstimmar du lagt ner på olika uppgifter. Det finns mycket mer i Jiras funktionalitet än vad som beskrivs ovan, men detta kommer att räcka för en första förståelse.

1. Designa nya lösningar

Innan du skapar och implementerar något måste du konceptualisera det, eller hur? Som jag sa tidigare kan detta helt enkelt vara en uppgift i Jira som tilldelas dig, så du arbetar med att designa en ny lösning, registrerar i Jira hur mycket tid du spenderade och på vad. Detta arbete kan också ske under en diskussion om ett teamkonferenssamtal: alla kan uttrycka sin åsikt och föreslå det tillvägagångssätt som de anser är bäst. Och här vill jag notera några punkter. För det första är mjukvaruutveckling ett mycket kreativt yrke, eftersom du behöver använda standardverktyg för att komma på nya sätt att lösa problem. En uppgift kan ofta ha många olika lösningar. Följaktligen beror allt på utvecklarens kreativitet, som är starkt påverkad av deras samlade kunskap och erfarenhet. Du kan visa upp all din kreativitet och geni här, men det viktiga är att inte överdriva det. Om du gör det blir koden för komplex och oläslig. Som ett resultat, efter att du lämnat, kommer ingen att helt förstå vad du kodade och hur det fungerar. Och de kommer att behöva skriva om allt från grunden. Och de kan komma ihåg dig. Mer än en gång. Och det är osannolikt att det kommer att sägas varma, vänliga ord. Behöver du det? För det andra måste en utvecklare behålla psykologisk flexibilitet i den meningen att du inte ska hålla fast vid en enda lösning och bli sluten för andra. Som om man bara måste göra något på ett sätt och det inte finns några andra alternativ. Du kan falla i den här fällan av olika anledningar. Anta till exempel att du vill bevisa att din åsikt är korrekt. Eller så kanske du redan har designat och implementerat din egen bekanta lösning – naturligtvis, du vill inte erkänna att det inte är det bästa. Dessa situationer kan göra dig ganska blind. Faktum är att du måste kunna erkänna dina misstag och alltid vara öppen, även om du måste ta bort funktionalitet som du är stolt över och har kodat i mer än en vecka. Jag minns hur en kollega förgyllde allas dag en gång genom att lämna denna tidsspårningskommentar i Jira: "Jag tog bort mitt dödfödda drag. Och sörjde."

2. Skriva ny funktionalitet

Detta steg – implementering av ny funktionalitet – följer logiskt efter det föregående. Allt arbete som ingår i ett projekt är uppdelat i uppgifter i Jira, som sedan delas ut till utvecklare utifrån deras arbetsbelastning. Det finns olika tillvägagångssätt för denna process, känd som "metoder", som du kan läsa mer om i den här artikeln på CodeGym . Som regel har uppgifter en uppskattning, vilket är den förväntade tiden som krävs för att slutföra dem. Den ställs antingen av dig, utvecklaren när du får uppdraget, eller av teamledaren, eller under planeringen, gemensamt av utvecklingsteamet. Denna tidsgissning är mycket sällan korrekt, eftersom så många olika faktorer påverkar mjukvaruutvecklingen. Till exempel om en programmerare är bekant eller obekant med den relevanta tekniken, hans eller hennes övergripande erfarenhet, olika oförutsägbara fallgropar, etc. Så om du inte når alla dina tidsuppskattningar när du kodar, är det inte världens undergång. Detta är bara allmänna uppskattningar. Som sagt, inte alla projekt kräver tidsuppskattning. Personligen tycker jag att det är mycket lättare att leva utan det, speciellt när PM inte tjatar på mig ett par gånger om dagen med frågan "var är dina tidsuppskattningar?" Så du får en uppgift,Redo för granskning " i Jira och be att dina kodändringar inte returneras för revision tillsammans med kommentarer.

3. Skriva prov

Granskaren, alltså den som kontrollerar din kod, gillar funktionaliteten du implementerat, men hon har en fråga till dig: var finns tillhörande tester? Så hon skickar tillbaka uppgiften till dig för revision. Tester är en viktig del av alla Java-applikationer. Genom att köra tester kan du omedelbart identifiera platser där applikationen inte fungerar korrekt. Till exempel gör en utvecklare vissa ändringar i en del av systemet, vilket resulterar i beteendeförändringar i en annan del, men han märkte inte detta när han kodade. Genom att köra testerna kommer han att kunna se att vissa tester misslyckades, vilket betyder att de inte gav de förväntade resultaten. Detta berättar för honom att något är trasigt någon annanstans i systemet. När han vet detta kommer han inte att begå de brytande ändringarna på servern, utan kommer istället att fortsätta arbeta med att felsöka sin kod. Ja, ganska få utvecklare älskar att skriva tester, men det går inte att förneka de fördelar de medför för mjukvaruutveckling. Kunderna själva anger ofta vilken nivå av testtäckning de vill behålla (till exempel 80 %). Det betyder att du behöver vetade olika typerna av prov och kunna skriva dem. Java-utvecklare skriver främst enhetstester och integrationstester, medan de mer omfattande (end-to-end) testerna hanteras av QA- och testautomationsexperter.

4. Hitta och åtgärda buggar

Detta är också en mycket vanlig, frekvent uppgift för Java-utvecklare. QA- och testautomationsexperternas huvudsakliga uppgift är att fånga buggar. De letar med andra ord efter platser där programmet beter sig fel, sedan skapar de uppgifter i Jira och tilldelar dem till någon. Till exempel till en teamledare, som i sin tur bestämmer vilka utvecklare de ska tilldelas, beroende på deras arbetsbelastning och förtrogenhet med de relevanta delarna av systemet. Efter det letar den tilldelade utvecklaren upp grundorsaken till felet och spenderar timmar i en debugger, med hjälp av buggbeskrivningen som tillhandahålls av QA-experterna för att återskapa förhållandena där felet inträffar. När utvecklaren hittar felet och fixar det, skickar han korrigeringen för granskning. Ibland kan utvecklaren inte reproducera felet, så han skickar tillbaka uppgiften till kvalitetssäkringsexperten tillsammans med en förklarande kommentar. Det verkar som att det inte borde ta särskilt lång tid att hitta och fixa en bugg, men det finns några nyanser. Allt beror främst på hur väl förtrogen utvecklaren är med denna del av koden, och på hans erfarenhet och teoretiska kunskap. Ibland kan en bugg hittas och åtgärdas på 20 minuter, och ibland kan det ta tre dagar. Detta innebär att denna typ av uppgift är särskilt svår att uppskatta i förväg, om inte utvecklaren, när han läser beskrivningen, omedelbart förstår vad, var och hur av buggen. I detta fall,

5. Kodgranskning

Som nämnts ovan, så snart du har slutfört en uppgift, ska den skickas för granskning. Om den klarar recensionen går den in i huvudgrenen. Om inte, returneras den till utvecklaren med kommentarer som måste åtgärdas. Naturligtvis förstår du att din kod kontrolleras av andra utvecklare, inte av någon hög kraft. Som sagt, alla får inte utföra kodgranskning - bara de mest erfarna utvecklarna härdade av verklig praxis, som kan se skillnaden mellan bra kod och dålig kod. Kodgranskningar utförs vanligtvis med hjälp av ett hjälpverktyg som Crucible. Granskare går igenom koden och lämnar vid behov kommentarer om vissa rader. Det kan finnas olika sorters kommentarer. Vissa är till exempel kritiska. Om de inte åtgärdas kommer granskaren inte att tillåta att koden begås. Andra kommentarer är, låt oss säga, bara kommentarer om det valda tillvägagångssättet. Dessa kan utvecklaren lyssna på, ta del av eller ignorera. Ett team kan skapa sina egna regler och procedurer för kodgranskning, komma överens om vad som är värt att uppmärksamma och inte, vilken tidsram som ska tilldelas för att slutföra en kodgranskning etc. Enbart erfarenhet räcker inte för att genomföra en granskning: du fortfarande behöver växa mycket i dina tekniska färdigheter och att läsa olika böcker (till exempel "Clean Code").

6. Kodanalys

Eftersom flera personer som tycker olika skriver kod för projektet samtidigt, kommer deras kod och tillvägagångssätt att vara olika. Och med tiden förvandlas allt gradvis till en enda röra. För att förbättra koden skapas ibland uppgifter för att till exempel analysera en viss modul eller hela applikationen, hitta och notera brister och senare skapa en refaktoreringsuppgift baserat på denna analys. En sådan analys hjälper också i situationer där, när utvecklingen började, teamet inte kunde se några enklare, mer koncisa lösningar, men de ser dem nu. Till exempel är logik ofta duplicerad i vissa metoder. Följaktligen kan den extraheras till en separat metod, som sedan kan återanvändas många gånger. Eller kanske en klass har blivit för uppsvälld, eller så har någon kod blivit svår att underhålla eller föråldrad, eller... Analysuppgifter hjälper till att förbättra kvaliteten på koden och applikationen. Som sagt, för mig kan det vara tråkigt att analysera en stor mängd kod.

7. Refaktoreringskod

Nästa del av kodanalys är refaktorering. Koden kan vara föråldrad, föråldrad, dåligt skriven, svår att läsa och så vidare. Du bör alltid sträva efter perfektion (även om det inte finns) och efter den uppdaterade koden, att ta bort allt överflödigt, eftersom det överflödiga bara leder till förvirring och stör möjligheten att se vad koden gör. Det säger sig självt att det är osannolikt att du kommer att se dessa uppgifter i början av ett projekt: du möter dem i senare utvecklingsstadier när applikationen poleras och bringas till perfektion. Här kan det vara lämpligt att rådgöra med medarbetare om vad de skulle göra och vilka fallgropar de ser. I deras hjärta liknar sådana uppgifter att utveckla ny funktionalitet. Anta till exempel att du får en uppgift att redigera någon funktionalitet utan att ändra dess beteende. För att göra detta tar du bort den gamla koden, skriver din egen och kontrollerar testerna. Om du gjorde allt rätt, utan att göra några ändringar i testerna, bör de alla klara som tidigare. Efter att allt i koden är som det ska skickar vi den för granskning och går och dricker lite kaffe :)

8. Skriva dokumentation

Föreställ dig att du är en ny utvecklare på något långsiktigt mjukvaruutvecklingsprojekt. Du måste bekanta dig med kodbasen eller utföra någon specifik uppgift, till exempel diagnostisera en bugg. Hur kommer du att navigera i projektet? Plåga dina lagkamrater var femte minut? Och tänk om de är upptagna eller det är helg, vad då? Det är just därför vi har dokumentation — så att en person som inte är bekant med koden kan komma in, hitta den relevanta sidan och snabbt ta reda på vad som händer i den del av applikationen som intresserar henne. Men någon måste skapa dokumentationen, haha. Om ett projekt har dokumentation som utvecklare måste stödja, när de implementerar ny funktionalitet, beskriver de det och uppdaterar dokumentationen tillsammans med eventuella kodändringar eller omfaktorer. Du kan också ha situationer där en separat anställd - en teknisk skribent - anställs för att skriva, underhålla och övervaka dokumentationen. Om en sådan specialist är tillgänglig är livet för vanliga utvecklare lite lättare.

9. Olika möten

Mycket av utvecklarnas tid går åt till olika möten, förhandlingar och planering. Det enklaste exemplet är det dagliga ståuppmötet, där du behöver rapportera vad du gjorde igår och vad du ska göra idag. Dessutom måste du ha en-till-en telefonsamtal, till exempel med testare, så att de kan demonstrera/förklara nyanserna av att återskapa en bugg, eller diskutera finesser och krav med en affärsanalytiker eller prata om organisatoriska frågor med ett PM. Detta innebär att även om en utvecklare kan vara en introvert som föredrar ensamhet, måste hon fortfarande kunna hitta en gemensam grund med andra människor (nåja, åtminstone lite). Ju högre en utvecklares rang, desto mer tid behöver hon lägga på kommunikation och desto mindre tid på att skriva kod. En dev-lead kan spendera hälften, eller till och med mer, av sin arbetsdag på enbart konversationer och möten och kan skriva kod mer sällan (möjligen få honom att förlora lite av sin kodningsförmåga). Men om du bara älskar att prata kan du som teamledare gå över till ledningen och helt glömma bort att skriva kod, istället skulle du spendera hela dagen på att kommunicera med olika team, kunder och andra chefer.

10. Genomföra/passera intervjuer

Om du arbetar för ett outsourcing- eller outstaffande företag kommer du ofta behöva gå igenom externa intervjuer, där du kommer att behöva "sälja" dig själv till kunden (du kan bli intervjuad av någon som arbetar för kunden), såväl som interna att klättra i graderna inom företaget. Jag skulle kalla detta ett bra tillfälle för tillväxt eftersom de frekventa intervjuerna kommer att tvinga dig att hålla dina kunskaper skarpa: du blir inte rostig och mjuk. Blir man mjuk i IT kan man ju falla helt ur fältet. När du blir en mer erfaren utvecklare kommer du att kunna hitta dig själv på andra sidan bordet och genomföra intervjuer snarare än att passera dem. Tro mig, du kommer att bli mycket förvånad när du tittar på det från den här positionen, för att ställa intervjufrågorna kan vara läskigare än att svara på dem. Du måste ha din egen intervjustrategi, en lista med frågor och tid att ställa frågor om alla nödvändiga ämnen på en timme. Och efter det är du ansvarig för att ge feedback som kommer att påverka anställningsbeslutet och om kandidaten får ett efterlängtat erbjudande eller befordran. Eller så kanske du låter en uppenbart svag kandidat få en position som hon inte kvalificerar sig för, och då kan du bli frågad, "hur kunde du tillåta henne att anställas överhuvudtaget med den kunskapsnivån"? Så när du är i heta stolen under en intervju, kom ihåg att personen framför dig också står inför en utmaning och kan vara stressad. du ansvarar för att ge feedback som kommer att påverka anställningsbeslutet och om kandidaten får ett efterlängtat erbjudande eller befordran. Eller så kanske du låter en uppenbart svag kandidat få en position som hon inte kvalificerar sig för, och då kan du bli frågad, "hur kunde du tillåta henne att anställas överhuvudtaget med den kunskapsnivån"? Så när du är i heta stolen under en intervju, kom ihåg att personen framför dig också står inför en utmaning och kan vara stressad. du ansvarar för att ge feedback som kommer att påverka anställningsbeslutet och om kandidaten får ett efterlängtat erbjudande eller befordran. Eller så kanske du låter en uppenbart svag kandidat få en position som hon inte kvalificerar sig för, och då kan du bli frågad, "hur kunde du tillåta henne att anställas överhuvudtaget med den kunskapsnivån"? Så när du är i heta stolen under en intervju, kom ihåg att personen framför dig också står inför en utmaning och kan vara stressad. Varje intervju är stressande för både kandidaten och intervjuaren. Vi slutar förmodligen här. Tack till alla som läser denna artikel. Lämna en like och fortsätt lära dig Java :)