De typische taken van een Java-ontwikkelaar in een project

Wat zijn de typische verantwoordelijkheden van een Java-ontwikkelaar? Je moet tenslotte begrijpen waar je aan begint en wat je uiteindelijk gaat doen, toch? Vandaag wil ik het hebben over tien essentiële taken die een Java-ontwikkelaar uitvoert. Maar laten we eerst kennis maken met een tool genaamd Jira. Of fris je geheugen ervan op, als je er al bekend mee bent. Jirais een hulpmiddel voor het organiseren van menselijke interacties, hoewel het in sommige gevallen ook wordt gebruikt voor projectbeheer. Met andere woorden, een project wordt opgesplitst in kleine taken die in deze tool worden beschreven. Deze taken zijn toegewezen aan de ontwikkelaars, die verantwoordelijk zijn voor de implementatie ervan. Een taak kan bijvoorbeeld het toevoegen van functionaliteit zijn. Terwijl een taak wordt uitgevoerd, voegen ontwikkelaars en andere specialisten opmerkingen toe over wie wat heeft gedaan en hoeveel tijd ze hebben besteed. Dit wordt gedaan voor tijdregistratiedoeleinden - om te weten hoeveel tijd er aan welke taken is besteed. Idealiter gebeurt dit één keer per dag: voordat u 's avonds uw bureau verlaat, geeft u aan hoeveel u van uw 8 werkuren aan verschillende taken hebt besteed. De functionaliteit van Jira omvat veel meer dan wat hierboven is beschreven, maar dit is voldoende voor een eerste begrip.

1. Ontwerpen van nieuwe oplossingen

Voordat je iets maakt en implementeert, moet je het eerst conceptualiseren, toch? Zoals ik al eerder zei, kan dit gewoon een taak in Jira zijn die aan jou wordt toegewezen, dus werk je aan het ontwerpen van een nieuwe oplossing, waarbij je in Jira vastlegt hoeveel tijd je hebt besteed en waaraan. Dit werk zou ook kunnen gebeuren tijdens een discussie tijdens een teamconferentie: iedereen kan zijn mening geven en de aanpak voorstellen die hij het beste acht. En hier wil ik een paar punten opmerken. Ten eerste is softwareontwikkeling een heel creatief vak, omdat je standaardtools moet gebruiken om nieuwe manieren te bedenken om problemen op te lossen. Eén taak kan vaak veel verschillende oplossingen hebben. Alles hangt dus af van de creativiteit van de ontwikkelaar, die sterk wordt beïnvloed door hun opgebouwde kennis en ervaring. Je kunt hier al je creativiteit en genialiteit laten zien, maar het belangrijkste is om het niet te overdrijven. Doe je dat wel, dan wordt de code te complex en onleesbaar. Als gevolg hiervan zal niemand na uw vertrek volledig begrijpen wat u hebt gecodeerd en hoe het werkt. En ze zullen alles vanaf nul moeten herschrijven. En misschien halen ze herinneringen aan je op. Meerdere keren. En het is onwaarschijnlijk dat er warme, vriendelijke woorden zullen worden gesproken. Heb je dat nodig? Ten tweede moet een ontwikkelaar psychologische flexibiliteit behouden, in die zin dat je je niet aan één enkele oplossing moet vastklampen en je niet blind moet staren op andere. Alsof je iets maar op één manier hoeft te doen en er geen andere opties zijn. U kunt om verschillende redenen in deze val trappen. Stel dat u wilt bewijzen dat uw standpunt juist is. Of misschien heb je al je eigen vertrouwde oplossing ontworpen en geïmplementeerd — natuurlijk, je zou niet willen toegeven dat het niet de beste is. Deze situaties kunnen je behoorlijk blind maken. In feite moet je je fouten kunnen toegeven en altijd ruimdenkend zijn, zelfs als je functionaliteit moet verwijderen waar je trots op bent en al meer dan een week aan het coderen bent. Ik herinner me hoe een collega ooit ieders dag opfleurde door deze tijdregistratie-opmerking achter te laten in Jira: "Ik heb mijn doodgeboren gezicht verwijderd. En gerouwd."

2. Schrijven van nieuwe functionaliteit

Deze stap — het implementeren van nieuwe functionaliteit — volgt logischerwijs op de vorige. Al het werk dat bij een project betrokken is, wordt in Jira verdeeld in taken, die vervolgens worden uitgedeeld aan ontwikkelaars op basis van hun werklast. Er zijn verschillende benaderingen van dit proces, ook wel 'methodologieën' genoemd, waarover u meer in detail kunt lezen in dit artikel over CodeGym . Taken hebben in de regel een schatting, wat de voorspelde tijd is die nodig is om ze te voltooien. Het wordt ingesteld door u, de ontwikkelaar wanneer u de taak ontvangt, of door de teamleider, of tijdens de planning, collectief door het ontwikkelingsteam. Deze tijdsinschatting is zeer zelden nauwkeurig, omdat er zoveel verschillende factoren van invloed zijn op de ontwikkeling van software. Bijvoorbeeld of een programmeur bekend of onbekend is met de relevante technologie, zijn of haar algehele ervaring, verschillende onvoorziene valkuilen, enz. Dus als u niet al uw tijdschattingen haalt bij het coderen, is dit niet het einde van de wereld. Dit zijn slechts algemene schattingen. Dat gezegd hebbende, niet alle projecten vereisen tijdsinschatting. Persoonlijk vind ik het veel gemakkelijker om zonder te leven, vooral als de premier me niet een paar keer per dag lastigvalt met de vraag "waar zijn je geschatte tijd?" Dus je krijgt een taak,Klaar voor beoordeling "in Jira en bid dat uw codewijzigingen niet samen met opmerkingen worden geretourneerd voor revisie.

3. Schrijftoetsen

De reviewer, dat wil zeggen degene die uw code controleert, vindt de functionaliteit die u heeft geïmplementeerd goed, maar heeft een vraag voor u: waar zijn de bijbehorende tests? Dus stuurt ze de taak terug naar jou voor revisie. Tests zijn een essentieel onderdeel van elke Java-toepassing. Door tests uit te voeren, kunt u direct plaatsen identificeren waar de applicatie niet goed werkt. Een ontwikkelaar brengt bijvoorbeeld enkele wijzigingen aan in een deel van het systeem, wat resulteert in gedragsveranderingen in een ander deel, maar hij heeft dit tijdens het coderen niet opgemerkt. Door de tests uit te voeren, kan hij zien dat bepaalde tests zijn mislukt, wat betekent dat ze niet de verwachte resultaten hebben opgeleverd. Dit vertelt hem dat er ergens anders in het systeem iets kapot is. Dit wetende, zal hij de belangrijkste wijzigingen niet doorvoeren op de server, en in plaats daarvan blijven werken aan het debuggen van zijn code. Ja, er zijn maar weinig ontwikkelaars die dol zijn op het schrijven van tests, maar het valt niet te ontkennen welke voordelen ze bieden voor softwareontwikkeling. Opdrachtgevers geven vaak zelf aan welk niveau van testdekking ze willen behouden (bijvoorbeeld 80%). Dat betekent dat je het moet wetende verschillende soorten toetsen kennen en kunnen schrijven. Java-ontwikkelaars schrijven voornamelijk unittests en integratietests, terwijl de meer uitgebreide (end-to-end) tests worden uitgevoerd door experts op het gebied van QA en testautomatisering.

4. Fouten zoeken en oplossen

Dit is ook een veel voorkomende taak voor Java-ontwikkelaars. De belangrijkste taak van QA- en testautomatiseringsexperts is het opsporen van bugs. Met andere woorden, ze zoeken naar plekken waar het programma zich niet goed gedraagt, maken vervolgens taken aan in Jira en wijzen die aan iemand toe. Bijvoorbeeld aan een teamleider, die op zijn beurt beslist aan welke ontwikkelaars ze worden toegewezen, afhankelijk van hun werklast en bekendheid met de relevante onderdelen van het systeem. Daarna gaat de toegewezen ontwikkelaar op zoek naar de oorzaak van de bug en besteedt hij uren aan een debugger, met behulp van de bugbeschrijving van de QA-experts om de omstandigheden te reproduceren waarin de bug optreedt. Zodra de ontwikkelaar de bug vindt en repareert, stuurt hij de fix ter beoordeling. Soms kan de ontwikkelaar de bug niet reproduceren en stuurt hij de taak samen met een verklarend commentaar terug naar de QA-expert. Het lijkt erop dat het niet lang hoeft te duren om een ​​bug te vinden en op te lossen, maar er zijn enkele nuances. Het hangt allemaal vooral af van hoe goed de ontwikkelaar bekend is met dit gedeelte van de code, en van zijn ervaring en theoretische kennis. Soms kan een bug binnen 20 minuten worden gevonden en opgelost, en soms kan het drie dagen duren. Dit betekent dat dit type taak bijzonder moeilijk vooraf in te schatten is, tenzij de ontwikkelaar bij het lezen van de beschrijving meteen begrijpt wat, waar en hoe de bug is. In dit geval,

5. Codebeoordeling

Zoals hierboven vermeld, moet u, zodra u een taak voltooit, deze ter beoordeling opsturen. Als het de beoordeling doorstaat, gaat het naar de hoofdtak. Als dit niet het geval is, wordt het teruggestuurd naar de ontwikkelaar met opmerkingen die moeten worden aangepakt. U begrijpt natuurlijk dat uw code allemaal wordt gecontroleerd door collega-ontwikkelaars, niet door een of andere hoge macht. Dat gezegd hebbende, mag niet iedereen codereviews uitvoeren - alleen de meest ervaren ontwikkelaars die gehard zijn door de praktijk en die het verschil kunnen zien tussen goede code en slechte code. Codebeoordelingen worden meestal uitgevoerd met behulp van een hulptool zoals Crucible. Reviewers nemen de code door en laten, indien nodig, opmerkingen achter over bepaalde regels. Er kunnen verschillende soorten opmerkingen zijn. Sommige zijn bijvoorbeeld kritisch. Als ze niet worden geadresseerd, staat de recensent niet toe dat de code wordt vastgelegd. Andere opmerkingen zijn bijvoorbeeld gewoon opmerkingen over de gekozen aanpak. Deze kan de ontwikkelaar beluisteren, noteren of negeren. Een team kan zijn eigen regels en procedures opstellen voor codereviews, afspraken maken over wat de moeite waard is om aandacht aan te besteden en wat niet, welk tijdsbestek moet worden uitgetrokken voor het voltooien van een codereview, enz. Ervaring alleen is niet voldoende om een ​​review uit te voeren: u veel moet groeien in je technische vaardigheden en verschillende boeken moet lezen (bijvoorbeeld "Clean Code").

6. Code-analyse

Aangezien verschillende mensen die anders denken tegelijkertijd code voor het project schrijven, zullen hun code en benaderingen verschillen. En na verloop van tijd verandert alles geleidelijk in een puinhoop. Om de code te verbeteren, worden soms taken gemaakt om bijvoorbeeld een bepaalde module of de hele applicatie te analyseren, tekortkomingen op te sporen en op te merken, en later een refactoring-taak te maken op basis van deze analyse. Een dergelijke analyse helpt ook in situaties waarin, toen de ontwikkeling begon, het team geen eenvoudigere, beknoptere oplossingen kon zien, maar ze zien ze nu wel. Logica wordt bijvoorbeeld vaak gedupliceerd in sommige methoden. Dienovereenkomstig kan het worden geëxtraheerd in een afzonderlijke methode, die vervolgens vele malen kan worden hergebruikt. Of misschien is een klas te opgeblazen geworden, of is sommige code moeilijk te onderhouden of verouderd, of... Analysetaken helpen om de kwaliteit van de code en de applicatie te verbeteren. Dat gezegd hebbende, voor mij kan het analyseren van een grote hoeveelheid code saai zijn.

7. Herstructureringscode

Het volgende onderdeel van code-analyse is refactoring. Code kan verouderd, achterhaald, slecht geschreven, moeilijk leesbaar, enzovoort zijn. Je moet altijd streven naar perfectie (hoewel die niet bestaat) en naar de up-to-date code, verwijder al het overbodige, want het overbodige leidt alleen maar tot verwarring en verstoort het vermogen om te zien wat de code doet. Het spreekt voor zich dat u deze taken aan het begin van een project waarschijnlijk niet zult zien: u komt ze tegen in latere stadia van ontwikkeling wanneer de applicatie wordt gepolijst en tot perfectie wordt gebracht. Hier kan het gepast zijn om met collega's te overleggen over wat zij zouden doen en welke valkuilen zij zien. In de kern zijn dergelijke taken vergelijkbaar met het ontwikkelen van nieuwe functionaliteit. Stel dat u een taak krijgt om bepaalde functionaliteit te bewerken zonder het gedrag ervan te wijzigen. Om dit te doen, verwijdert u de oude code, schrijft u uw eigen code en controleert u de tests. Als je alles goed hebt gedaan, zouden ze allemaal moeten slagen zoals voorheen, zonder enige wijzigingen in de tests aan te brengen. Nadat alles in de code is zoals het hoort, sturen we het voor een beoordeling en gaan we wat koffie drinken :)

8. Schrijven van documentatie

Stel je voor dat je een nieuwe ontwikkelaar bent van een langlopend softwareontwikkelingsproject. U moet vertrouwd raken met de codebasis of een specifieke taak uitvoeren, bijvoorbeeld een bug diagnosticeren. Hoe ga je door het project navigeren? Je teamgenoten elke vijf minuten lastig vallen? En wat als ze het druk hebben of het weekend is, wat dan? Dit is precies waarom we documentatie hebben — zodat een persoon die niet bekend is met de code kan binnenkomen, de relevante pagina kan vinden en snel kan uitzoeken wat er gebeurt in het deel van de applicatie dat haar interesseert. Maar iemand moet de documentatie maken, haha. Als een project documentatie heeft die ontwikkelaars moeten ondersteunen, beschrijven ze deze wanneer ze nieuwe functionaliteit implementeren en werken ze de documentatie bij, samen met eventuele codewijzigingen of refactoring. U kunt ook situaties hebben waarin een afzonderlijke medewerker - een technisch schrijver - wordt ingehuurd om de documentatie te schrijven, te onderhouden en te controleren. Als zo'n specialist beschikbaar is, is het leven van gewone ontwikkelaars een beetje gemakkelijker.

9. Diverse bijeenkomsten

Veel tijd van ontwikkelaars wordt besteed aan verschillende vergaderingen, onderhandelingen en planning. Het eenvoudigste voorbeeld is de daily stand-up meeting, waarbij je moet rapporteren wat je gisteren hebt gedaan en wat je vandaag gaat doen. Daarnaast zul je een-op-een telefoongesprekken moeten voeren, bijvoorbeeld met testers, zodat ze de nuances van het reproduceren van een bug kunnen demonstreren/uitleggen, of de subtiliteiten en vereisten kunnen bespreken met een bedrijfsanalist of kunnen praten over organisatorische problemen. met een PB. Dit betekent dat hoewel een ontwikkelaar een introverte persoon kan zijn die de voorkeur geeft aan eenzaamheid, ze toch een gemeenschappelijke basis moet kunnen vinden met andere mensen (nou ja, in ieder geval een beetje). Hoe hoger de rang van een ontwikkelaar, hoe meer tijd hij aan communicatie moet besteden en hoe minder tijd het schrijven van code. Een ontwikkelaar kan de helft of zelfs meer van zijn werkdag alleen aan gesprekken en vergaderingen besteden en schrijft mogelijk minder vaak code (waardoor hij mogelijk een beetje van zijn codeervaardigheid verliest). Maar als je gewoon van praten houdt, kun je als teamleider overstappen naar management en het schrijven van code helemaal vergeten, in plaats daarvan zou je de hele dag communiceren met verschillende teams, klanten en andere managers.

10. Het voeren/doorstaan ​​van sollicitatiegesprekken

Als u voor een outsourcing- of outstaffingbedrijf werkt, zult u vaak externe interviews moeten afleggen, waarbij u uzelf aan de klant moet "verkopen" (u kunt worden geïnterviewd door iemand die voor de klant werkt), evenals interne degenen om de gelederen binnen het bedrijf te beklimmen. Ik zou dit een goede kans om te groeien noemen omdat de frequente interviews je zullen dwingen je kennis scherp te houden: je wordt niet roestig en slap. Immers, als je soft wordt in IT, kun je helemaal uit het veld vallen. Naarmate je een meer ervaren ontwikkelaar wordt, kun je jezelf aan de andere kant van de tafel vinden en interviews afnemen in plaats van ze te passeren. Geloof me, je zult erg verrast zijn als je er vanuit deze positie naar kijkt, want het stellen van de interviewvragen kan enger zijn dan het beantwoorden ervan. U moet uw eigen interviewstrategie hebben, een lijst met vragen en tijd om binnen een uur vragen te stellen over alle noodzakelijke onderwerpen. En daarna ben je verantwoordelijk voor het geven van feedback die van invloed zal zijn op de aanwervingsbeslissing en of de kandidaat een langverwachte aanbieding of promotie krijgt. Of je zou een duidelijk zwakke kandidaat een functie kunnen laten krijgen waarvoor ze niet in aanmerking komt, en dan kan je worden gevraagd: "Hoe kun je haar überhaupt laten aannemen met dat kennisniveau"? Houd er dus rekening mee dat de persoon tegenover u ook voor een uitdaging staat en mogelijk gestrest is als u tijdens een interview in de hot seat zit. het is uw verantwoordelijkheid om feedback te geven die van invloed is op de aanwervingsbeslissing en of de kandidaat een langverwachte aanbieding of promotie krijgt. Of je zou een duidelijk zwakke kandidaat een functie kunnen laten krijgen waarvoor ze niet in aanmerking komt, en dan kan je worden gevraagd: "Hoe kun je haar überhaupt laten aannemen met dat kennisniveau"? Houd er dus rekening mee dat de persoon tegenover u ook voor een uitdaging staat en mogelijk gestrest is als u tijdens een interview in de hot seat zit. het is uw verantwoordelijkheid om feedback te geven die van invloed is op de aanwervingsbeslissing en of de kandidaat een langverwachte aanbieding of promotie krijgt. Of je zou een duidelijk zwakke kandidaat een functie kunnen laten krijgen waarvoor ze niet in aanmerking komt, en dan kan je worden gevraagd: "Hoe kun je haar überhaupt laten aannemen met dat kennisniveau"? Houd er dus rekening mee dat de persoon tegenover u ook voor een uitdaging staat en mogelijk gestrest is als u tijdens een interview in de hot seat zit. Elk interview is stressvol voor zowel de kandidaat als de interviewer. We eindigen waarschijnlijk hier. Dank aan iedereen die dit artikel heeft gelezen. Laat een like achter en blijf Java leren :)