Sarcinile tipice ale unui dezvoltator Java într-un proiect

Care sunt responsabilitățile tipice ale unui dezvoltator Java? La urma urmei, trebuie să înțelegi în ce te bagi și ce vei ajunge să faci, nu? Astăzi aș dori să vorbesc despre zece sarcini vitale pe care le îndeplinește un dezvoltator Java. Dar mai întâi, să facem cunoștință cu un instrument numit Jira. Sau reîmprospătează-ți memoria despre el, dacă ești deja familiarizat cu el. Jiraeste un instrument de organizare a interacțiunilor umane, deși în unele cazuri este folosit și pentru managementul proiectelor. Cu alte cuvinte, un proiect este împărțit în sarcini mici care sunt descrise în acest instrument. Aceste sarcini sunt atribuite dezvoltatorilor, care sunt responsabili pentru implementarea lor. O sarcină ar putea fi, de exemplu, adăugarea unor funcționalități. Pe măsură ce o sarcină este îndeplinită, dezvoltatorii și alți specialiști adaugă comentarii despre cine a făcut ce și cât timp au petrecut. Acest lucru se face în scopuri de urmărire a timpului - pentru a ști cât timp a fost petrecut pe ce sarcini. În mod ideal, acest lucru se face o dată pe zi: înainte de a părăsi biroul seara, indicați cât ați petrecut din cele 8 ore de lucru pe diverse sarcini. Funcționalitatea lui Jira este mult mai mult decât ceea ce este descris mai sus, dar acest lucru va fi suficient pentru o înțelegere inițială.

1. Proiectarea de noi soluții

Înainte de a crea și implementa ceva, trebuie să-l conceptualizezi, nu? După cum am spus mai devreme, aceasta ar putea fi pur și simplu o sarcină în Jira care ți se atribuie, așa că lucrezi pentru a proiecta o nouă soluție, înregistrând în Jira cât timp ai petrecut și pentru ce. Această muncă se poate întâmpla și în timpul unei discuții la o conferință telefonică în echipă: fiecare își poate exprima opinia și propune abordarea pe care o consideră cea mai bună. Și aici aș dori să notez câteva puncte. În primul rând, dezvoltarea de software este o profesie foarte creativă, deoarece trebuie să utilizați instrumente standard pentru a găsi modalități noi de rezolvare a problemelor. O sarcină poate avea adesea multe soluții diferite. În consecință, totul depinde de creativitatea dezvoltatorului, care este puternic influențată de cunoștințele și experiența acumulate. Poți să-ți arăți toată creativitatea și geniul aici, dar important este să nu exagerezi. Dacă o faci, codul va deveni prea complex și imposibil de citit. Drept urmare, după ce pleci, nimeni nu va înțelege pe deplin ce ai codificat și cum funcționează. Și vor trebui să rescrie totul de la zero. Și s-ar putea să-și amintească despre tine. Mai mult de o dată. Și este puțin probabil că vor fi rostite cuvinte calde și amabile. Ai nevoie de asta? În al doilea rând, un dezvoltator trebuie să păstreze flexibilitatea psihologică, în sensul că nu ar trebui să te agăți de o singură soluție și să devii închis la minte față de ceilalți. De parcă ar trebui să faci ceva într-un singur fel și nu ar fi alte opțiuni. S-ar putea să cazi în această capcană din diverse motive. De exemplu, să presupunem că doriți să demonstrați că punctul dvs. de vedere este corect. Sau poate că ați proiectat și implementat deja propria soluție familiară - desigur, nu ai vrea să recunoști că nu este cel mai bun. Aceste situații te pot face destul de orb. De fapt, trebuie să fii capabil să-ți recunoști greșelile și să fii mereu deschis la minte, chiar dacă trebuie să elimini funcționalitățile de care ești mândru și de care ai programat mai mult de o săptămână. Îmi amintesc cum un coleg a înseninat ziua tuturor o dată lăsând acest comentariu de urmărire a timpului în Jira: „Mi-am eliminat trăsătura născută moartă. Și am plâns”.

2. Scrierea de noi funcționalități

Acest pas - implementarea unei noi funcționalități - urmează logic după cel precedent. Toată munca implicată într-un proiect este împărțită în sarcini în Jira, care sunt apoi distribuite dezvoltatorilor în funcție de volumul lor de muncă. Există diferite abordări ale acestui proces, cunoscute sub numele de „metodologii”, despre care puteți citi mai detaliat în acest articol despre CodeGym . De regulă, sarcinile au o estimare, care este timpul estimat necesar pentru a le finaliza. Este stabilit fie de dvs., dezvoltator, atunci când primiți sarcina, fie de liderul echipei, fie în timpul planificării, în mod colectiv de către echipa de dezvoltare. De această dată, estimarea este foarte rar precisă, deoarece atât de mulți factori diferiți afectează dezvoltarea software-ului. De exemplu, dacă un programator este familiarizat sau nu cu tehnologia relevantă, cu experiența sa generală, cu diverse capcane imprevizibile etc. Deci, dacă nu vă atingeți toate estimările de timp la codificare, nu este sfârșitul lumii. Acestea sunt doar estimări generale. Acestea fiind spuse, nu toate proiectele necesită o estimare a timpului. Personal, mi se pare mult mai ușor să trăiesc fără ea, mai ales când PM nu mă deranjează de câteva ori pe zi cu întrebarea „unde sunt estimările tale de timp?” Deci, primești o sarcină,Gata pentru revizuire „ în Jira și rugați-vă ca modificările dvs. de cod să nu fie returnate pentru revizuire împreună cu comentarii.

3. Teste de scriere

Revizorului, adică persoanei care vă verifică codul, îi place funcționalitatea pe care ați implementat-o, dar are o întrebare pentru dvs.: unde sunt testele asociate? Așa că ea îți trimite sarcina înapoi pentru revizuire. Testele sunt o parte esențială a oricărei aplicații Java. Rulând teste, puteți identifica imediat locurile în care aplicația nu funcționează corect. De exemplu, un dezvoltator face unele modificări într-o parte a sistemului, ceea ce are ca rezultat modificări ale comportamentului în altă parte, dar nu a observat acest lucru în timpul codificării. Prin rularea testelor, el va putea vedea că anumite teste au eșuat, adică nu au dat rezultatele așteptate. Acest lucru îi spune că ceva este stricat în altă parte în sistem. Știind acest lucru, el nu va efectua modificările de ultimă oră pe server și, în schimb, va continua să lucreze la depanarea codului său. Da, destul de puțini dezvoltatori iubesc să scrie teste, dar nu se poate nega beneficiile pe care le aduc dezvoltării software. Clienții înșiși indică adesea nivelul de acoperire a testelor pe care doresc să-l mențină (de exemplu, 80%). Asta înseamnă că trebuie să știidiferitele tipuri de teste și să le poată scrie. Dezvoltatorii Java scriu în principal teste unitare și teste de integrare, în timp ce testele mai extinse (end-to-end) sunt gestionate de experți în QA și automatizare a testelor.

4. Găsirea și remedierea erorilor

Aceasta este, de asemenea, o sarcină foarte comună și frecventă pentru dezvoltatorii Java. Principala sarcină a experților în controlul calității și în automatizarea testelor este să detecteze erori. Cu alte cuvinte, ei caută locuri în care programul se comportă incorect, apoi creează sarcini în Jira și le atribuie cuiva. De exemplu, unui lider de echipă, care, la rândul său, decide cărui dezvoltatori să îi atribuie, în funcție de volumul de lucru și de familiaritatea cu părțile relevante ale sistemului. După aceea, dezvoltatorul atribuit urmărește cauza principală a erorii, petrecând ore întregi într-un depanator, folosind descrierea erorii furnizată de experții QA pentru a reproduce condițiile în care apare eroarea. Odată ce dezvoltatorul găsește eroarea și o remediază, el trimite remedierea spre examinare. Uneori, dezvoltatorul nu poate reproduce eroarea, așa că trimite sarcina înapoi expertului QA împreună cu un comentariu explicativ. Se pare că nu ar trebui să dureze foarte mult pentru a găsi și remedia o eroare, dar există câteva nuanțe. Totul depinde în principal de cât de bine cunoaște dezvoltatorul cu această secțiune a codului și de experiența și cunoștințele sale teoretice. Uneori, o eroare poate fi găsită și remediată în 20 de minute, iar uneori poate dura trei zile. Acest lucru înseamnă că acest tip de sarcină este deosebit de dificil de estimat în avans, cu excepția cazului în care dezvoltatorul, la citirea descrierea, înțelege imediat ce, unde și cum despre eroare. În acest caz,

5. Revizuirea codului

După cum sa menționat mai sus, de îndată ce finalizați o sarcină, aceasta ar trebui trimisă pentru revizuire. Dacă trece revizuirea, atunci intră în ramura principală. Dacă nu, acesta este returnat dezvoltatorului cu comentarii care trebuie abordate. Desigur, înțelegeți că codul dvs. este verificat de colegii dezvoltatori, nu de o putere mare. Acestea fiind spuse, nu toată lumea are voie să efectueze recenzii de cod - doar cei mai experimentați dezvoltatori, întăriți de practica din lumea reală, care pot face diferența dintre codul bun și codul prost. Revizuirile de cod sunt de obicei efectuate folosind un instrument de ajutor, cum ar fi Crucible. Recenziatorii parcurg codul și, dacă este necesar, lasă comentarii despre anumite rânduri. Pot exista diverse tipuri de comentarii. De exemplu, unele sunt critice. Dacă nu sunt abordate, examinatorul nu va permite comiterea codului. Alte comentarii sunt, să zicem, simple observații despre abordarea aleasă. Acestea le poate asculta dezvoltatorul, le poate lua notă sau le poate ignora. O echipă își poate crea propriile reguli și proceduri pentru revizuirea codului, căzând de acord cu privire la ceea ce merită să acordați atenție și ce nu, la ce interval de timp ar trebui alocat pentru finalizarea unei revizuiri a codului etc. Experiența în sine nu este suficientă pentru a efectua o revizuire: încă aveți trebuie să vă dezvoltați foarte mult abilitățile tehnice și să citiți diverse cărți (de exemplu, „Cod curat”).

6. Analiza codului

Deoarece mai multe persoane care gândesc diferit scriu cod pentru proiect simultan, codul și abordările lor vor fi diferite. Și în timp, totul se transformă treptat într-o mizerie. Pentru a îmbunătăți codul, uneori sunt create sarcini pentru, să zicem, să analizeze un anumit modul sau întreaga aplicație, să găsească și să noteze deficiențele, iar ulterior să creeze o sarcină de refactorizare pe baza acestei analize. O astfel de analiză ajută și în situațiile în care, atunci când a început dezvoltarea, echipa nu putea vedea niște soluții mai simple, mai concise, dar le vede acum. De exemplu, logica este adesea duplicată în unele metode. În consecință, poate fi extras într-o metodă separată, care poate fi apoi reutilizată de mai multe ori. Sau poate o clasă a crescut prea mult sau un cod a devenit dificil de întreținut sau depășit, sau... Sarcinile de analiză ajută la îmbunătățirea calității codului și a aplicației. Acestea fiind spuse, pentru mine, analiza unei cantități mari de cod poate fi plictisitoare.

7. Cod de refactorizare

Următoarea parte a analizei codului este refactorizarea. Codul poate fi învechit, învechit, prost scris, greu de citit și așa mai departe. Ar trebui să depuneți întotdeauna eforturi pentru perfecțiune (deși nu există) și pentru codul actualizat, înlăturând orice lucru de prisos, pentru că ceea ce este de prisos duce doar la confuzie și interferează cu capacitatea de a vedea ce face codul. Este de la sine înțeles că este puțin probabil să vedeți aceste sarcini la începutul unui proiect: le întâlniți în etapele ulterioare de dezvoltare, atunci când aplicația este lustruită și adusă la perfecțiune. Aici, poate fi potrivit să vă consultați cu colegii despre ceea ce ar face ei și ce capcane văd. În esenta lor, astfel de sarcini sunt similare cu dezvoltarea de noi funcționalități. De exemplu, să presupunem că primiți o sarcină pentru a edita anumite funcționalități fără a-i schimba comportamentul. Pentru a face acest lucru, ștergeți vechiul cod, scrieți al dvs. și verificați testele. Dacă ați făcut totul bine, atunci fără a face nicio modificare la teste, toate ar trebui să treacă ca înainte. După ce totul din cod este așa cum ar trebui, îl trimitem pentru o revizuire și mergem să bem niște cafea :)

8. Redactarea documentaţiei

Imaginați-vă că sunteți un nou dezvoltator într-un proiect de dezvoltare software pe termen lung. Trebuie să vă familiarizați cu baza de cod sau să efectuați o anumită sarcină, de exemplu, să diagnosticați o eroare. Cum vei naviga prin proiect? Îți deranjează colegii la fiecare cinci minute? Și dacă sunt ocupați sau e weekend, ce atunci? Tocmai de aceea avem documentație – astfel încât o persoană care nu este familiarizată cu codul să poată intra, să găsească pagina relevantă și să-și dea seama rapid ce se întâmplă în partea din aplicație care o interesează. Dar cineva trebuie să creeze documentația, haha. Dacă un proiect are documentație pe care dezvoltatorii trebuie să o susțină, atunci când implementează o nouă funcționalitate, o descriu și actualizează documentația împreună cu orice modificări de cod sau refactorizare. Puteți avea, de asemenea, situații în care un angajat separat - un scriitor tehnic - este angajat pentru a scrie, întreține și supraveghea documentația. Dacă un astfel de specialist este disponibil, viața dezvoltatorilor obișnuiți este puțin mai ușoară.

9. Diverse întâlniri

Mult timp al dezvoltatorilor este petrecut în diferite întâlniri, negocieri și planificare. Cel mai simplu exemplu este întâlnirea zilnică stand-up, în care trebuie să raportezi ce ai făcut ieri și ce vei face astăzi. În plus, va trebui să aveți apeluri telefonice unu-la-unu, de exemplu, cu testeri, astfel încât aceștia să poată demonstra/explica nuanțele reproducerii unui bug sau să discute subtilitățile și cerințele cu un analist de afaceri sau să discute despre probleme organizaționale. cu un PM. Aceasta înseamnă că, deși un dezvoltator poate fi un introvertit care preferă singurătatea, ea trebuie totuși să poată găsi un punct comun cu alți oameni (ei bine, cel puțin puțin). Cu cât un dezvoltator este mai înalt, cu atât are nevoie de mai mult timp pentru comunicare și cu atât mai puțin timp pentru scrierea codului. Un lider de dezvoltare își poate petrece jumătate, sau chiar mai mult, din ziua sa de lucru numai pentru conversații și întâlniri și poate scrie cod mai rar (care îl poate face să-și piardă puțin din priceperea de codare). Dar dacă îți place să vorbești, ai putea, ca lider de echipă, să treci la management și să uiți complet de scris cod, în schimb, ai petrece toată ziua comunicând cu diverse echipe, clienți și alți manageri.

10. Realizarea/procesarea interviurilor

Dacă lucrezi pentru o companie de outsourcing sau de personal, va trebui adesea să treci prin interviuri externe, în care va trebui să te „vinzi” clientului (poate fi intervievat de cineva care lucrează pentru client), precum și interviuri interne. cei care să urce pe rând în cadrul companiei. Aș numi asta o bună oportunitate de creștere, deoarece interviurile dese te vor forța să-ți păstrezi cunoștințele clare: nu vei deveni ruginit și moale. La urma urmei, dacă te moale în IT, poți cădea complet din teren. Pe măsură ce deveniți un dezvoltator mai experimentat, veți putea să vă găsiți de cealaltă parte a mesei, realizând interviuri în loc să le treceți. Crede-mă, vei fi foarte surprins când o vei privi din această poziție, pentru că a pune întrebările interviului poate fi mai înfricoșător decât a le răspunde. Trebuie să aveți propria strategie de interviu, o listă de întrebări și timp pentru a pune întrebări pe toate subiectele necesare într-o oră. Și după aceea, ești responsabil să oferi feedback care va influența decizia de angajare și dacă candidatul primește o ofertă sau o promovare mult așteptată. Sau, ați putea permite unui candidat evident slab să obțină o poziție pentru care nu se califică și apoi ați putea fi întrebat, „cum ați putea permite să fie angajată cu acel nivel de cunoștințe”? Așadar, atunci când sunteți pe locul fierbinte în timpul unui interviu, rețineți că și persoana din fața dvs. se confruntă cu o provocare și poate fi stresată. sunteți responsabil să oferiți feedback care va influența decizia de angajare și dacă candidatul primește o ofertă sau o promovare mult așteptată. Sau, ați putea permite unui candidat evident slab să obțină o poziție pentru care nu se califică și apoi ați putea fi întrebat, „cum ați putea permite să fie angajată cu acel nivel de cunoștințe”? Așadar, atunci când sunteți pe locul fierbinte în timpul unui interviu, rețineți că și persoana din fața dvs. se confruntă cu o provocare și poate fi stresată. sunteți responsabil să oferiți feedback care va influența decizia de angajare și dacă candidatul primește o ofertă sau o promovare mult așteptată. Sau, ați putea permite unui candidat evident slab să obțină o poziție pentru care nu se califică și apoi ați putea fi întrebat, „cum ați putea permite să fie angajată cu acel nivel de cunoștințe”? Așadar, atunci când sunteți pe locul fierbinte în timpul unui interviu, rețineți că și persoana din fața dvs. se confruntă cu o provocare și poate fi stresată. Orice interviu este stresant atât pentru candidat, cât și pentru intervievator. Probabil ne vom încheia chiar aici. Mulțumesc tuturor celor care au citit acest articol. Lăsați un like și continuați să învățați Java :)