Mga karaniwang gawain ng isang developer ng Java sa isang proyekto

Ano ang karaniwang mga responsibilidad ng isang developer ng Java? Pagkatapos ng lahat, kailangan mong maunawaan kung ano ang iyong pinapasok at kung ano ang iyong gagawin, tama ba? Ngayon gusto kong pag-usapan ang tungkol sa sampung mahahalagang gawain na ginagawa ng isang developer ng Java. Ngunit una, kilalanin natin ang isang tool na tinatawag na Jira. O i-refresh ang iyong memorya tungkol dito, kung pamilyar ka na dito. Jiraay isang tool para sa pag-aayos ng mga pakikipag-ugnayan ng tao, bagama't sa ilang mga kaso ginagamit din ito para sa pamamahala ng proyekto. Sa madaling salita, ang isang proyekto ay nahahati sa maliliit na gawain na inilalarawan sa tool na ito. Ang mga gawaing ito ay itinalaga sa mga developer, na responsable para sa kanilang pagpapatupad. Ang isang gawain ay maaaring, halimbawa, pagdaragdag ng ilang pag-andar. Habang isinasagawa ang isang gawain, nagdaragdag ang mga developer at iba pang mga espesyalista ng mga komento tungkol sa kung sino ang gumawa at kung gaano katagal ang kanilang ginugol. Ginagawa ito para sa mga layunin ng pagsubaybay sa oras — upang malaman kung gaano karaming oras ang ginugol sa kung anong mga gawain. Sa isip, ito ay ginagawa isang beses sa isang araw: Bago ka umalis sa iyong desk sa gabi, ipahiwatig mo kung gaano karami sa iyong 8 oras ng trabaho ang ginugol mo sa iba't ibang gawain. Marami pa sa functionality ni Jira kaysa sa inilarawan sa itaas, ngunit ito ay sapat na para sa isang paunang pag-unawa.

1. Pagdidisenyo ng mga bagong solusyon

Bago ka lumikha at magpatupad ng isang bagay, kailangan mong i-conceptualize ito, tama ba? Gaya ng sinabi ko dati, ito ay maaaring isang gawain lamang sa Jira na itatalaga sa iyo, kaya magtrabaho ka upang magdisenyo ng isang bagong solusyon, na i-record sa Jira kung gaano katagal ang iyong ginugol at kung ano. Ang gawaing ito ay maaari ding mangyari sa panahon ng isang talakayan sa isang tawag sa kumperensya ng koponan: lahat ay maaaring magpahayag ng kanilang opinyon at magmungkahi ng diskarte na itinuturing nilang pinakamahusay. At dito nais kong tandaan ang ilang mga punto. Una, ang software development ay isang napaka-creative na propesyon, dahil kailangan mong gumamit ng mga karaniwang tool upang makabuo ng mga bagong paraan ng paglutas ng mga problema. Ang isang gawain ay kadalasang maaaring magkaroon ng maraming iba't ibang solusyon. Alinsunod dito, ang lahat ay nakasalalay sa pagkamalikhain ng developer, na labis na naiimpluwensyahan ng kanilang naipon na kaalaman at karanasan. Maaari mong ipakita ang lahat ng iyong pagkamalikhain at galing dito, ngunit ang mahalaga ay huwag lumampas. Kung gagawin mo, ang code ay magiging masyadong kumplikado at hindi nababasa. Bilang resulta, pagkatapos mong umalis, walang ganap na makakaunawa kung ano ang iyong na-code at kung paano ito gumagana. At kailangan nilang muling isulat ang lahat mula sa simula. At baka maalala ka nila. Higit sa isang beses. At malamang na hindi magkakaroon ng mainit, magiliw na mga salita na binibigkas. Kailangan mo ba yun? Pangalawa, dapat panatilihin ng isang developer ang psychological flexibility sa diwa na hindi ka dapat kumapit sa iisang solusyon at maging closedminded sa iba. Na parang kailangan mong gawin ang isang bagay sa isang paraan lamang at walang ibang mga pagpipilian. Maaari kang mahulog sa bitag na ito sa iba't ibang dahilan. Halimbawa, ipagpalagay na gusto mong patunayan na tama ang iyong pananaw. O marahil ay nakadisenyo at nakapagpatupad ka na ng sarili mong pamilyar na solusyon — siyempre, hindi mo nais na aminin na ito ay hindi ang pinakamahusay. Ang mga sitwasyong ito ay maaaring magpabulag sa iyo. Sa katunayan, kailangan mong tanggapin ang iyong mga pagkakamali at maging laging bukas ang isipan, kahit na kailangan mong tanggalin ang functionality na ipinagmamalaki mo at mahigit isang linggo nang nagco-coding. Naaalala ko kung paano pinasaya ng isang katrabaho ang araw ng lahat nang isang beses sa pamamagitan ng pag-iwan ng komentong ito sa pagsubaybay sa oras sa Jira: "Inalis ko ang deadborn feature ko. At nagluksa."

2. Pagsusulat ng bagong functionality

Ang hakbang na ito — ang pagpapatupad ng bagong functionality — ay lohikal na sumusunod pagkatapos ng nauna. Ang lahat ng gawaing kasangkot sa isang proyekto ay nahahati sa mga gawain sa Jira, na pagkatapos ay ibibigay sa mga developer batay sa kanilang workload. Mayroong iba't ibang mga diskarte sa prosesong ito, na kilala bilang "mga pamamaraan," na maaari mong basahin nang mas detalyado sa artikulong ito sa CodeGym . Bilang isang tuntunin, ang mga gawain ay may pagtatantya, na siyang hinulaang oras na kinakailangan upang makumpleto ang mga ito. Ito ay itinakda mo, ang developer kapag natanggap mo ang gawain, o ng pinuno ng koponan, o sa panahon ng pagpaplano, nang sama-sama ng development team. Ang hula sa oras na ito ay napakabihirang tumpak, dahil napakaraming iba't ibang mga kadahilanan ang nakakaapekto sa pagbuo ng software. Halimbawa, kung ang isang programmer ay pamilyar o hindi pamilyar sa nauugnay na teknolohiya, ang kanyang pangkalahatang karanasan, iba't ibang hindi inaasahang pitfalls, atbp. Kaya, kung hindi mo maabot ang lahat ng iyong pagtatantya ng oras kapag nagko-coding, hindi ito ang katapusan ng mundo. Ito ay mga pangkalahatang pagtatantya lamang. Sabi nga, hindi lahat ng proyekto ay nangangailangan ng pagtatantya ng oras. Sa personal, mas madali akong mabuhay nang wala ito, lalo na kapag hindi ako ginugulo ng PM ng ilang beses sa isang araw na may tanong na "nasaan ang iyong mga pagtatantya sa oras?" Kaya, makakakuha ka ng isang gawain,Handa na para sa pagsusuri " sa Jira at ipanalangin na ang iyong mga pagbabago sa code ay hindi maibalik para sa rebisyon kasama ng mga komento.

3. Pagsusulit sa pagsulat

Gusto ng tagasuri, ibig sabihin, ang taong sumusuri sa iyong code, ang pagpapagana na iyong ipinatupad, ngunit may tanong siya sa iyo: saan ang mga nauugnay na pagsubok? Kaya ibinabalik niya ang gawain sa iyo para sa rebisyon. Ang mga pagsubok ay isang mahalagang bahagi ng anumang Java application. Sa pamamagitan ng pagpapatakbo ng mga pagsubok, matutukoy mo kaagad ang mga lugar kung saan hindi gumagana nang tama ang application. Halimbawa, ang isang developer ay gumagawa ng ilang pagbabago sa isang bahagi ng system, na nagreresulta sa mga pagbabago sa gawi sa ibang bahagi, ngunit hindi niya ito napansin habang nagko-coding. Sa pamamagitan ng pagpapatakbo ng mga pagsubok, makikita niyang nabigo ang ilang partikular na pagsubok, ibig sabihin, hindi nila nagawa ang inaasahang resulta. Sinasabi nito sa kanya na may nasira sa ibang lugar sa system. Dahil alam ito, hindi niya gagawin ang mga paglabag na pagbabago sa server, at sa halip ay magpapatuloy sa pag-debug ng kanyang code. Oo, sa halip ilang mga developer ang gustong sumulat ng mga pagsusulit, ngunit hindi maikakaila ang mga benepisyong hatid nila sa pagbuo ng software. Ang mga kliyente mismo ay madalas na nagpapahiwatig ng antas ng saklaw ng pagsubok na gusto nilang panatilihin (halimbawa, 80%). Ibig sabihin, kailangan mong malamanang iba't ibang uri ng pagsusulit at maisulat ang mga ito. Pangunahing sumusulat ang mga developer ng Java ng mga unit test at integration test, habang ang mas malawak (end-to-end) na mga pagsubok ay pinangangasiwaan ng mga eksperto sa QA at test automation.

4. Paghahanap at pag-aayos ng mga bug

Ito rin ay isang pangkaraniwan, madalas na gawain para sa mga developer ng Java. Ang pangunahing trabaho ng mga eksperto sa QA at pagsubok sa automation ay ang manghuli ng mga bug. Sa madaling salita, naghahanap sila ng mga lugar kung saan hindi tama ang pagkilos ng programa, pagkatapos ay gumawa sila ng mga gawain sa Jira at itinalaga ang mga ito sa isang tao. Halimbawa, sa isang team lead, na siya namang magpapasya kung aling mga developer ang magtatalaga sa kanila, depende sa kanilang workload at pamilyar sa mga nauugnay na bahagi ng system. Pagkatapos nito, hinahanap ng nakatalagang developer ang ugat ng bug, na gumugugol ng ilang oras sa isang debugger, gamit ang paglalarawan ng bug na ibinigay ng mga eksperto sa QA upang kopyahin ang mga kundisyon kung saan nangyayari ang bug. Kapag nahanap na ng developer ang bug at naayos ito, ipapadala niya ang pag-aayos para sa pagsusuri. Minsan ang developer ay hindi magawang kopyahin ang bug, kaya ipinadala niya ang gawain pabalik sa QA expert kasama ng isang paliwanag na komento. Mukhang hindi ito dapat magtagal upang mahanap at ayusin ang isang bug, ngunit may ilang mga nuances. Ang lahat ay higit sa lahat ay nakasalalay sa kung gaano kakilala ang developer sa seksyong ito ng code, at sa kanyang karanasan at teoretikal na kaalaman. Minsan ang isang bug ay mahahanap at maayos sa loob ng 20 minuto, at kung minsan ay maaaring tumagal ng tatlong araw. Nangangahulugan ito na ang ganitong uri ng gawain ay lalong mahirap tantiyahin nang maaga, maliban kung ang developer, sa pagbabasa ng paglalarawan, ay agad na nauunawaan kung ano, saan, at paano ang bug. Sa kasong ito,

5. Pagsusuri ng code

Tulad ng nabanggit sa itaas, sa sandaling makumpleto mo ang isang gawain, dapat itong ipadala para sa pagsusuri. Kung pumasa ito sa pagsusuri, pagkatapos ay mapupunta ito sa pangunahing sangay. Kung hindi, ibabalik ito sa developer na may mga komento na kailangang matugunan. Siyempre, naiintindihan mo na ang iyong code ay sinusuri lahat ng mga kapwa developer, hindi ng ilang mataas na kapangyarihan. Sabi nga, hindi lahat ay pinahihintulutan na magsagawa ng mga pagsusuri sa code — tanging ang mga pinaka may karanasang developer na pinatigas ng real-world na kasanayan, na makapagsasabi ng pagkakaiba sa pagitan ng magandang code at masamang code. Ang mga pagsusuri sa code ay karaniwang ginagawa gamit ang isang helper tool tulad ng Crucible. Ang mga tagasuri ay dumaan sa code at, kung kinakailangan, mag-iwan ng mga komento tungkol sa ilang partikular na linya. Maaaring may iba't ibang uri ng komento. Halimbawa, ang ilan ay kritikal. Kung hindi natugunan ang mga ito, hindi papayagan ng reviewer na gawin ang code. Ang iba pang mga komento ay, sabihin nating, mga pangungusap lamang tungkol sa napiling diskarte. Ang mga ito ay maaaring pakinggan ng developer, tandaan, o huwag pansinin. Ang isang koponan ay maaaring lumikha ng sarili nitong mga panuntunan at pamamaraan para sa mga pagsusuri sa code, sumasang-ayon tungkol sa kung ano ang nararapat na bigyang pansin at kung ano ang hindi, kung anong timeframe ang dapat ilaan para sa pagkumpleto ng isang pagsusuri sa code, atbp. Ang karanasan lamang ay hindi sapat upang magsagawa ng pagsusuri: ikaw pa rin kailangang lumago nang husto sa iyong mga teknikal na kasanayan at magbasa ng iba't ibang aklat (halimbawa, "Clean Code").

6. Pagsusuri ng code

Dahil maraming tao na nag-iisip nang iba ang sumulat ng code para sa proyekto nang sabay-sabay, mag-iiba ang kanilang code at approach. At sa paglipas ng panahon, unti-unting nagiging gulo ang lahat. Upang mapabuti ang code, kung minsan ang mga gawain ay nilikha upang, sabihin, pag-aralan ang isang partikular na module o ang buong application, hanapin at tandaan ang mga pagkukulang, at sa ibang pagkakataon ay lumikha ng isang refactoring na gawain batay sa pagsusuring ito. Nakakatulong din ang naturang pagsusuri sa mga sitwasyon kung saan, noong nagsimula ang pag-unlad, ang koponan ay hindi makakita ng ilang mas simple, mas maigsi na solusyon, ngunit nakikita na nila ang mga ito ngayon. Halimbawa, ang lohika ay madalas na nadoble sa ilang mga pamamaraan. Alinsunod dito, maaari itong makuha sa isang hiwalay na paraan, na maaaring magamit muli nang maraming beses. O marahil ang isang klase ay lumaki nang labis, o ang ilang code ay naging mahirap na mapanatili o luma na, o... Ang mga gawain sa pagsusuri ay nakakatulong upang mapabuti ang kalidad ng code at ang application. Iyon ay sinabi, para sa akin, ang pagsusuri ng isang malaking halaga ng code ay maaaring maging boring.

7. Refactoring code

Ang susunod na bahagi ng pagsusuri ng code ay refactoring. Maaaring luma na ang code, lipas na, mahina ang pagkakasulat, mahirap basahin, at iba pa. Dapat mong palaging magsikap para sa pagiging perpekto (bagaman ito ay hindi umiiral) at para sa napapanahon na code, pag-alis ng anumang kalabisan, dahil ang kalabisan ay humahantong lamang sa kalituhan at nakakasagabal sa kakayahang makita kung ano ang ginagawa ng code. Hindi sinasabi na malamang na hindi mo makikita ang mga gawaing ito sa simula ng isang proyekto: makakatagpo mo ang mga ito sa mga susunod na yugto ng pag-unlad kapag ang application ay pinakintab at dinadala sa pagiging perpekto. Dito, maaaring angkop na kumunsulta sa mga katrabaho tungkol sa kung ano ang kanilang gagawin at kung ano ang mga pitfalls na nakikita nila. Sa kanilang puso, ang gayong mga gawain ay katulad ng pagbuo ng bagong pag-andar. Halimbawa, ipagpalagay na nakatanggap ka ng isang gawain upang i-edit ang ilang functionality nang hindi binabago ang pag-uugali nito. Upang gawin ito, tatanggalin mo ang lumang code, isulat ang iyong sarili, at suriin ang mga pagsubok. Kung ginawa mo ang lahat ng tama, kung gayon nang hindi gumagawa ng anumang mga pagbabago sa mga pagsubok, dapat silang lahat ay pumasa tulad ng dati. Matapos ang lahat ng nasa code ay tulad ng nararapat, ipinapadala namin ito para sa isang pagsusuri, at humigop ng kape :)

8. Pagsusulat ng dokumentasyon

Isipin na ikaw ay isang bagong developer sa ilang pangmatagalang software development project. Kailangan mong maging pamilyar sa base ng code o magsagawa ng ilang partikular na gawain, halimbawa, mag-diagnose ng bug. Paano mo i-navigate ang proyekto? Istorbohin ang iyong mga kasamahan sa koponan tuwing limang minuto? At paano kung abala sila o weekend, ano naman? Ito ang eksaktong dahilan kung bakit mayroon kaming dokumentasyon — upang ang isang taong hindi pamilyar sa code ay maaaring pumasok, mahanap ang nauugnay na pahina, at mabilis na malaman kung ano ang nangyayari sa bahagi ng application na interesado sa kanya. Pero kailangan may gumawa ng documentation, haha. Kung ang isang proyekto ay may dokumentasyon na dapat suportahan ng mga developer, kapag nagpatupad sila ng bagong functionality, inilalarawan nila ito at ina-update ang dokumentasyon kasama ng anumang mga pagbabago sa code o refactoring. Maaari ka ring magkaroon ng mga sitwasyon kung saan ang isang hiwalay na empleyado — isang teknikal na manunulat — ay kinukuha upang magsulat, magpanatili, at mangasiwa sa dokumentasyon. Kung ang naturang espesyalista ay magagamit, ang buhay ng mga ordinaryong developer ay medyo mas madali.

9. Iba't ibang pagpupulong

Maraming oras ng developer ang ginugugol sa iba't ibang pagpupulong, negosasyon, at pagpaplano. Ang pinakasimpleng halimbawa ay ang pang-araw-araw na stand-up meeting, kung saan kailangan mong iulat kung ano ang iyong ginawa kahapon at kung ano ang iyong gagawin ngayon. Bilang karagdagan, kakailanganin mong magkaroon ng one-on-one na mga tawag sa telepono, halimbawa, kasama ang mga tester, para maipakita/ipaliwanag nila ang mga nuances ng paggawa ng bug, o talakayin ang mga subtlety at kinakailangan sa isang business analyst o pag-usapan ang tungkol sa mga isyu sa organisasyon. may PM. Nangangahulugan ito na kahit na ang isang developer ay maaaring isang introvert na mas gusto ang pag-iisa, kailangan pa rin niyang makahanap ng isang karaniwang batayan sa ibang mga tao (mabuti, kahit kaunti). Kung mas mataas ang ranggo ng developer, mas maraming oras ang kailangan niyang gugulin sa komunikasyon at mas kaunting oras sa pagsulat ng code. Ang isang dev lead ay maaaring gumastos ng kalahati, o higit pa, ng kanyang araw ng trabaho sa mga pag-uusap at pagpupulong nang nag-iisa at maaaring magsulat ng code nang mas madalas (posibleng magdulot sa kanya ng kaunting pagkawala ng kanyang kahusayan sa pag-coding). Ngunit kung mahilig ka lang makipag-usap, maaari kang, bilang pinuno ng koponan, lumipat sa pamamahala at ganap na kalimutan ang tungkol sa pagsusulat ng code, sa halip, gugugol ka ng buong araw sa pakikipag-usap sa iba't ibang mga team, customer, at iba pang mga manager.

10. Pagsasagawa/pagpasa ng mga panayam

Kung nagtatrabaho ka para sa isang outsourcing o outstaffing na kumpanya, madalas mong kailangang dumaan sa mga panlabas na panayam, kung saan kakailanganin mong "ibenta" ang iyong sarili sa kliyente (maaari kang makapanayam ng isang taong nagtatrabaho para sa kliyente), pati na rin ang panloob para umakyat sa mga ranggo sa loob ng kumpanya. Tatawagin ko itong magandang pagkakataon para sa paglago dahil ang madalas na mga panayam ay pipilitin mong panatilihing matalas ang iyong kaalaman: hindi ka magkakaroon ng kalawang at malambot. Pagkatapos ng lahat, kung ikaw ay naging malambot sa IT, maaari kang ganap na mahulog sa labas ng larangan. Habang ikaw ay naging isang mas may karanasan na developer, makikita mo ang iyong sarili sa kabilang panig ng talahanayan, na nagsasagawa ng mga panayam sa halip na ipasa ang mga ito. Maniwala ka sa akin, magugulat ka kapag tiningnan mo ito mula sa posisyong ito, dahil ang pagtatanong sa mga tanong sa pakikipanayam ay maaaring mas nakakatakot kaysa sa pagtugon sa kanila. Kailangan mong magkaroon ng sarili mong diskarte sa pakikipanayam, listahan ng mga tanong, at oras para magtanong sa lahat ng kinakailangang paksa sa loob ng isang oras. At pagkatapos nito, ikaw ay may pananagutan na magbigay ng feedback na makakaimpluwensya sa pagpapasya sa pag-hire at kung ang kandidato ay makakatanggap ng isang matagal nang inaasahang alok o promosyon. O, maaari mong payagan ang isang malinaw na mahinang kandidato na makakuha ng posisyon na hindi siya kwalipikado, at pagkatapos ay maaari kang tanungin, "paano mo siya papayagan na matanggap sa lahat ng antas ng kaalaman na iyon"? Kaya, kapag nasa hot seat ka sa isang panayam, tandaan na ang kaharap mo ay nahaharap din sa isang hamon at maaaring ma-stress. ikaw ay may pananagutan na magbigay ng feedback na makakaimpluwensya sa pagpapasya sa pagkuha at kung ang kandidato ay makakatanggap ng isang matagal nang inaasahang alok o promosyon. O, maaari mong payagan ang isang malinaw na mahinang kandidato na makakuha ng posisyon na hindi siya kwalipikado, at pagkatapos ay maaari kang tanungin, "paano mo siya papayagan na matanggap sa lahat ng antas ng kaalaman na iyon"? Kaya, kapag nasa hot seat ka sa isang panayam, tandaan na ang kaharap mo ay nahaharap din sa isang hamon at maaaring ma-stress. ikaw ay may pananagutan na magbigay ng feedback na makakaimpluwensya sa pagpapasya sa pagkuha at kung ang kandidato ay makakatanggap ng isang matagal nang inaasahang alok o promosyon. O, maaari mong payagan ang isang malinaw na mahinang kandidato na makakuha ng posisyon na hindi siya kwalipikado, at pagkatapos ay maaari kang tanungin, "paano mo siya papayagan na matanggap sa lahat ng antas ng kaalaman na iyon"? Kaya, kapag nasa hot seat ka sa isang panayam, tandaan na ang kaharap mo ay nahaharap din sa isang hamon at maaaring ma-stress. Ang anumang panayam ay nakaka-stress para sa kandidato at sa tagapanayam. Malamang dito na tayo magtatapos. Salamat sa lahat ng nagbasa ng artikulong ito. Mag-iwan ng like at magpatuloy sa pag-aaral ng Java :)