Apa tanggung jawab khas pangembang Jawa? Sawise kabeh, sampeyan kudu ngerti apa sing arep sampeyan lakoni lan apa, ing pungkasan, sampeyan bakal nindakake, bener? Dina iki aku arep ngomong babagan sepuluh tugas utama sing ditindakake pangembang Jawa. Nanging dhisik, ayo padha kenalan karo piranti kaya Jira. Utawa ayo refresh memori kita yen wis menowo kanggo sampeyan. Jira minangka alat interaksi pangguna, sanajan ing sawetara kasus uga digunakake kanggo manajemen proyek. Ing tembung liya, pangembangan proyek dipérang dadi tugas cilik sing diterangake ing alat iki. Tugas kasebut ditugasake (ditugasake) kanggo pangembang, sing bakal tanggung jawab kanggo implementasine. Miturut tugas kita tegese, contone, nambah sawetara fungsi. Nalika kemajuan maju, pangembang lan spesialis liyane nambahake komentar babagan sapa sing nindakake apa lan suwene wektu sing ditindakake - dheweke nglacak wektu. Iki ditindakake kanggo nglacak wektu sing ditindakake: pira lan apa. Saenipun, iki rampung sapisan dina: ing wayah sore sadurunge mangkat, sampeyan nglacak 8 jam menyang tugas sing sampeyan gunakake. Fungsi Jira luwih jembar tinimbang sing kasebut ing ndhuwur, nanging iki bakal cukup kanggo pemahaman awal. Dadi, apa tanggung jawabe pangembang Jawa?
1. Pangembangan solusi anyar
Sadurunge nggawe lan ngleksanakake, sampeyan kudu nggawe, ta? Kaya sing dakkandhakake, mung bisa dadi tugas Jira sing bakal ditugasake kanggo sampeyan, lan sampeyan bakal bisa ngembangake solusi anyar, nyathet ing Jira pira wektu sampeyan lan apa. Iki uga bisa dadi diskusi babagan panggilan tim klompok: saben wong bakal bisa mratelakake panemume lan ngusulake pendekatan sing dianggep paling apik. Lan ing kene aku pengin nyathet sawetara poin. Kaping pisanan, profesi pangembang minangka lapangan sing kreatif banget, amarga sampeyan kudu nggawe cara unik kanggo ngatasi masalah nggunakake alat standar. Asring, siji masalah bisa duwe macem-macem solusi: kanthi mangkono, kabeh gumantung saka "semangat kreatif" pangembang, basis pengetahuan lan pengalaman sing akumulasi. Ing kene sampeyan bisa nuduhake kabeh kreatifitas lan genius, nanging sing utama ora ngluwihi: ing kasus iki, kode kasebut bakal dadi rumit lan ora bisa diwaca lan minangka asil, sawise sampeyan lunga, ora ana sing ngerti apa iku lan cara kerjane. Lan sampeyan kudu nulis maneh kabeh saka awal. Lan dheweke bisa uga ngelingi sampeyan. Lan luwih saka sepisan. Lan iki ora mungkin dadi tembung sing anget lan apik. Apa sampeyan butuh? Kapindho, pangembang kudu fleksibel amarga sampeyan ora bakal macet ing siji solusi lan ditutup kanggo wong liya. Kaya, sampeyan mung kudu nindakake kanthi cara iki lan ora liya. Iki bisa kedadeyan kanthi macem-macem alasan: umpamane, sampeyan pengin mbuktekake sudut pandang sampeyan, utawa sampeyan wis ngembangake lan ngetrapake solusi sampeyan, sing sampeyan seneng banget lan, mesthi, ora pengin ngakoni yen dudu solusi kasebut. paling apik. Iki bisa cukup wuta sampeyan. Nyatane, sampeyan kudu bisa ngakoni kesalahane lan tansah mbukak perkara anyar ("open-minded"), sanajan sampeyan kudu mbusak fungsi sing wis ditulis pirang-pirang minggu lan sampeyan bangga banget. Aku elinga yen swasana ati sedina muput digawe dening trek wektu wong ing Jira kanthi komentar: "Aku mbusak fungsi matiku. aku nangis”
2. Nulis fungsi anyar
Iki minangka langkah logis sawise sing sadurunge - implementasine fungsi anyar. Kabeh karya ing proyek kasebut dipérang dadi tugas ing jira, sing ditampa para pangembang nalika kerja. Ana macem-macem pendekatan kanggo masalah iki - "metodologi", liyane babagan sing bisa diwaca ing artikel iki ing JavaRush . Minangka aturan, tugas duwe "Estimasi" - wektu sing diprediksi bakal rampung. Iki disetel dening sampeyan dhewe nalika sampeyan nindakake tugas kasebut, utawa dening pimpinan tim, utawa nalika ngrancang para pangembang bebarengan ngira. Wektu iki arang banget ditebak kanthi akurat, amarga akeh faktor sing mengaruhi pangembangan. Contone, iku programmer menowo utawa ora menowo karo teknologi iki, apa pengalaman umum, macem-macem pitfalls sing bisa dadi katon wis sak pembangunan, etc. Mulane, yen sampeyan ora ketemu deadline iki nalika ngembangaken fungsi, ora ana sing ala bakal kelakon. Iki mung perkiraan umum. Nanging maneh, ora kabeh proyek duwe taksiran tugas lan, kanggo aku, luwih gampang urip tanpa, utamane nalika PM ora ngetung sampeyan kaping pindho saben dina kanthi pitakonan "Endi perkiraan? ” Mulane, sampeyan njupuk tugas, ngembangake fungsi sing dibutuhake, upload menyang cabang umum ing GIT , lan ing jira ngganti status tugas dadi "Siap ditinjau" , yaiku, siap kanggo ndeleng (mriksa) lan ndedonga. iku ora bali menyang sampeyan karo komentar ing revisi.
3. Tes nulis kanggo fungsi
Wong sing mriksa kode sampeyan - reviewer - seneng karo fungsi sing dikembangake, nanging dheweke duwe pitakon: ing endi tes kasebut? Lan dheweke bali tugas kanggo revisi. Tes minangka bagean penting saka aplikasi Java. Kanthi mbukak, sampeyan bisa langsung nyekel ing ngendi aplikasi kasebut ora digunakake. Contone, pangembang nggawe sawetara owah-owahan ing siji bagéan saka sistem, kang mimpin kanggo owah-owahan ing prilaku ing liyane, lan ora sok dong mirsani iki sak pembangunan. Kanthi nganakake tes, dheweke bakal bisa ndeleng tes sing gagal (sing ora bisa digunakake kanthi bener). Iki bakal ngandhani yen ana sing rusak ing bagean liya saka sistem kasebut. Mulane, dheweke ora bakal ngunggahake owah-owahan ing server, nanging bakal terus ngrampungake solusi kasebut. Ya, mesthi, sawetara pangembang seneng tes, nanging ora bisa nolak keuntungan sing digawa menyang aplikasi kasebut. Asring klien dhewe nemtokake tingkat jangkoan tes sing kudu ditindakake (contone, 80%). Mula, sampeyan kudu ngerti macem-macem jinis tes lan bisa nulis. Pangembang Java utamane nulis tes unit lan tes integrasi, dene AQA (penguji otomatis) ngatasi tes sing luwih akeh (end-to-end). Sampeyan bisa maca liyane babagan dheweke lan wakil profesi IT liyane ing reviewku .
4. Nemokake lan ndandani bug
Iki uga tugas sing umum banget lan asring kanggo pangembang Java. Tugas utama QA lan AQA yaiku nyekel kewan omo. Yaiku, dheweke nggoleki papan sing ora bener program kasebut, nggawe masalah ing Jira lan nyalahke wong liya. Contone, pimpinan tim, sing banjur mutusake pangembang sing bakal ditugasake, gumantung saka beban lan akrab karo bagean sistem kasebut. Sawise iki, pangembang nggoleki bug kasebut, mbuwang jam ing debugger , nggunakake katrangan masalah dening spesialis QA kanggo mbaleni kahanan sing kedadeyan bug kasebut. Sabanjure, pangembang nemokake bug, ndandani, lan dikirim kanggo ditinjau. Ya, bisa uga pangembang ora bisa ngasilake bug kasebut, lan dheweke bali tugas kasebut menyang spesialis QA kanthi komentar babagan iki. Kayane ora suwe kanggo nemokake lan ndandani bug kasebut, nanging ana sawetara nuansa. Kabeh gumantung utamane marang pangembang sing akrab karo bagean kode iki, pengalaman lan kawruh babagan masalah teoritis. Kadhangkala bug bisa ditemokake lan didandani sajrone 20 menit, lan kadhangkala butuh telung dina. Patut, jinis tugas iki utamané angel kanggo ngevaluasi ing advance, kajaba pangembang, sawise maca gambaran, langsung mangertos apa, ngendi lan apa salah. Ing kasus iki, dheweke bakal bisa ngira wektu kanthi luwih utawa kurang.
5. Kode review
Kaya sing kasebut ing ndhuwur, sanalika sampeyan ngrampungake tugas, kudu dikirim kanggo ditinjau, lan yen lulus, bakal mlebu ing utas umum, yen ora, bakal bali menyang pangembang kanthi komentar babagan apa sing kudu ditindakake. didandani. Cetha yen kabeh iki ora dicenthang dening sawetara kekuwatan sing luwih dhuwur, nanging dening pangembang liyane. Nanging ora kabeh pangembang diijini dadi reviewer, nanging mung sing paling berpengalaman, sing duwe praktik ing mburi lan bisa mbedakake kode ala saka apik. Review kode biasane rampung nggunakake alat bantu, contone, Crucible . Reviewer mriksa kode lan, yen perlu, ninggalake komentar ing sawetara baris. Komentar uga bisa macem-macem jinis. Contone, kritis, tanpa koreksi sing reviewer ora bakal pass kode, lan liyane kamungkinan mung komentar babagan pendekatan milih, kang pangembang bisa ngrungokake, njupuk cathetan, utawa nglirwakake. Tim kasebut bisa nggawe prosedur lan aturan dhewe kanggo nganakake tinjauan, setuju babagan apa sing kudu digatekake lan apa sing ora, sajrone wektu apa review kode kudu ditindakake, lsp. Kanggo nganakake review, pengalaman mung ora cukup: sampeyan isih kudu berkembang akeh ing arah teknis, maca macem-macem buku (contone, "Kode Bersih" ). Yen sampeyan kasengsem ing nuansa nganakake review kode miturut Google, aku menehi saran supaya maca artikel iki .
6. Analisis kode
Amarga proyek kasebut ditulis bebarengan dening sawetara wong sing mikir kanthi beda, kode lan pendekatane bakal beda. Lan liwat wektu, kabeh bakal mboko sithik dadi mush. Kanggo nambah kode, kadhangkala sampeyan nggawe tugas kanggo njelasno, mbok menawa modul tartamtu utawa kabeh aplikasi, kanggo nemokake cacat lan flag wong, lan mengko nggawe tugas refactoring adhedhasar komentar iki. Analisis uga mbantu ing kahanan sing sawetara trabasan sing luwih prasaja ora katon wiwit wiwitan pembangunan, nanging saiki bisa dideleng. Contone, logika sing padha asring diulang ing sawetara cara lan, kanthi mangkono, bisa dipindhah menyang cara sing kapisah lan digunakake maneh kaping pirang-pirang. Inggih, salah siji sawetara kelas wis dadi painfully bloated, utawa sawetara kode wis dadi angel kanggo njaga utawa outdated, utawa ... Tugas analisis mbantu nambah kualitas kode lan aplikasi. Sanajan, miturut pendapatku, nganalisa kode sing akeh banget bisa dadi tugas sing mboseni.
7. Kode refactoring
Bagean analisis sabanjure yaiku refactoring kode. Bisa uga wis lawas, ora perlu maneh, tulisane kurang apik, angel diwaca, lan liya-liyane. Sampeyan kudu tansah ngupayakake kesempurnaan (sanajan ora ana) lan kode sing paling anyar, mbusak kabeh sing ora perlu, amarga iki mung mbingungake lan nyegah sampeyan ndeleng inti saka fungsi kasebut. Ora perlu dikandhakake manawa sampeyan ora bisa ndeleng tugas kasebut ing wiwitan proyek: mung kedadeyan ing tahap pangembangan sabanjure, nalika aplikasi dipoles lan digawa menyang sempurno. Ing kene, bisa uga cocog kanggo takon karo kanca-kanca babagan carane nindakake lan apa sing dideleng. Inti saka tugas kasebut padha karo pangembangan fungsi anyar. Contone, sampeyan nampa tugas kanggo ngowahi sawetara fungsi tanpa ngganti prilaku. Kanggo nindakake iki, mbusak sing lawas, nulis dhewe lan mriksa tes. Yen sampeyan nindakake kabeh kanthi bener, tanpa owah-owahan ing tes sing kudu ditindakake kaya sadurunge. Sawise kabeh wis dirampungake ing kode kasebut, kita kirimake kanggo mriksa lan golek kopi))
8. Nulis dokumentasi
Bayangake sampeyan minangka pangembang anyar ing sawetara proyek sing wis dikembangake suwene suwe. Sampeyan kudu familiarize dhewe karo utawa nindakake sawetara tugas tartamtu, contone, nyekel bug. Carane sampeyan bakal navigasi project? Narik anggota tim saben limang menit? Lan yen lagi sibuk utawa ing akhir minggu, banjur apa? Mulane dokumentasi ana, supaya wong sing ora ngerti fungsi kasebut bisa mlebu, nemokake kaca sing bener lan cepet ngerti apa bagean aplikasi sing disenengi dheweke. Nanging wong uga kudu ngisi dokumentasi ^^ Yen proyek duwe dokumentasi sing pangembang kudu ndhukung, nalika ngleksanakake fungsi anyar padha njlèntrèhaké, lan karo macem-macem owah-owahan lan refactorings nganyari dokumentasi. Kahanan uga bisa ditindakake nalika spesialis sing kapisah, panulis teknis, direkrut kanggo nulis, ndhukung lan ngontrol dokumentasi. Yen spesialis kuwi ana, iku ndadekake urip pangembang biasa sethitik luwih gampang.
9. Partisipasi ing macem-macem rapat umum
Pangembang nglampahi akeh wektu kanggo macem-macem rapat, negosiasi, lan perencanaan. Conto sing paling gampang yaiku "rapat saben dina" (rapat saben dina), ing ngendi sampeyan kudu nyritakake apa sing sampeyan lakoni wingi lan apa sing bakal sampeyan lakoni dina iki. Kajaba iku, sampeyan kudu nelpon siji-siji, contone, karo spesialis QA, supaya bisa nuduhake / nerangake nuansa reproduksi bug, utawa ngrembug nuansa lan syarat karo analis bisnis, utawa organisasi. masalah karo PM. Mulane, sanajan pangembang bisa dadi wong introvert sing luwih seneng kesepian, dheweke kudu bisa nemokake basa sing umum karo wong liya (uga, paling sethithik). Sing luwih dhuwur peringkat pangembang, luwih akeh wektu dheweke kudu nggunakake komunikasi lan kurang wektu nulis kode. Pimpinan tim pangembang malah bisa nglampahi setengah, utawa luwih, wektu kerjane ing obrolan lan rapat-rapat lan nulis kode kurang asring (iki bisa nyebabake kelangan sethithik). Nanging yen sampeyan uga wong sing seneng ngomong, sampeyan bisa kanthi gampang berkembang saka posisi timbal tim menyang sisih managerial lan rampung lali bab kode, sedina muput karo macem-macem tim, pelanggan lan Managers liyane.
10. Nindakake/lulus wawancara
Yen sampeyan kerja ing perusahaan outsourcing utawa outstaffing, sampeyan kudu ngalami wawancara eksternal sing kerep, nalika sampeyan kudu "didol" menyang klien (banjur sampeyan bisa diwawancarai dening wong saka sisih klien), lan wawancara internal, kanggo nambah pangkat ing perusahaan. Aku bakal nyebut iki minangka faktor sing apik kanggo pangembangan, amarga amarga wawancara sing kerep, kawruh sampeyan kudu tansah wujud: sampeyan ora bakal teyeng lan santai, amarga yen sampeyan santai ing IT, sampeyan bisa mabur metu saka lapangan. Yen sampeyan dadi pangembang sing luwih berpengalaman, sampeyan bakal bisa ngunjungi sisih liya: ora lulus, nanging nindakake wawancara. Pracayaa, sampeyan bakal kaget banget yen ndeleng saka perspektif iki, amarga nindakake wawancara bisa luwih medeni tinimbang liwat. Sampeyan kudu duwe strategi wawancara dhewe, dhaptar pitakonan, lan duwe wektu kanggo takon babagan kabeh topik sing dibutuhake sajrone jam. Lan sawise iku, sampeyan tanggung jawab kanggo umpan balik, amarga ngandelake, wong bisa uga ora nampa tawaran utawa promosi sing ditunggu-tunggu. Inggih, lan kosok balene: sampeyan bisa kantun calon sing terus terang banget kanggo posisi sing ora cocog, banjur sampeyan bisa takon: carane sampeyan malah kantun dheweke karo tingkat kawruh? Mula, nalika arep wawancara, elinga yen wong sing ana ing ngarep sampeyan uga nandhang susah, lan bisa uga ngalami stres. Wawancara apa wae dadi stres kanggo calon lan pewawancara. Mbok menawa kita bakal mungkasi kene. Matur nuwun kanggo kabeh sing wis rampung maca: seneng lan sinau basa Jawa ^^
Kapindho, pangembang kudu fleksibel amarga sampeyan ora bakal macet ing siji solusi lan ditutup kanggo wong liya. Kaya, sampeyan mung kudu nindakake kanthi cara iki lan ora liya. Iki bisa kedadeyan kanthi macem-macem alasan: umpamane, sampeyan pengin mbuktekake sudut pandang sampeyan, utawa sampeyan wis ngembangake lan ngetrapake solusi sampeyan, sing sampeyan seneng banget lan, mesthi, ora pengin ngakoni yen dudu solusi kasebut. paling apik. Iki bisa cukup wuta sampeyan. Nyatane, sampeyan kudu bisa ngakoni kesalahane lan tansah mbukak perkara anyar ("open-minded"), sanajan sampeyan kudu mbusak fungsi sing wis ditulis pirang-pirang minggu lan sampeyan bangga banget. Aku elinga yen swasana ati sedina muput digawe dening trek wektu wong ing Jira kanthi komentar: "Aku mbusak fungsi matiku. aku nangis”
Mula, sampeyan kudu ngerti macem-macem jinis tes lan bisa nulis. Pangembang Java utamane nulis tes unit lan tes integrasi, dene AQA (penguji otomatis) ngatasi tes sing luwih akeh (end-to-end). Sampeyan bisa maca liyane babagan dheweke lan wakil profesi IT liyane ing reviewku .
Review kode biasane rampung nggunakake alat bantu, contone, Crucible . Reviewer mriksa kode lan, yen perlu, ninggalake komentar ing sawetara baris. Komentar uga bisa macem-macem jinis. Contone, kritis, tanpa koreksi sing reviewer ora bakal pass kode, lan liyane kamungkinan mung komentar babagan pendekatan milih, kang pangembang bisa ngrungokake, njupuk cathetan, utawa nglirwakake. Tim kasebut bisa nggawe prosedur lan aturan dhewe kanggo nganakake tinjauan, setuju babagan apa sing kudu digatekake lan apa sing ora, sajrone wektu apa review kode kudu ditindakake, lsp. Kanggo nganakake review, pengalaman mung ora cukup: sampeyan isih kudu berkembang akeh ing arah teknis, maca macem-macem buku (contone, "Kode Bersih" ). Yen sampeyan kasengsem ing nuansa nganakake review kode miturut Google, aku menehi saran supaya maca artikel iki .
Ing kene, bisa uga cocog kanggo takon karo kanca-kanca babagan carane nindakake lan apa sing dideleng. Inti saka tugas kasebut padha karo pangembangan fungsi anyar. Contone, sampeyan nampa tugas kanggo ngowahi sawetara fungsi tanpa ngganti prilaku. Kanggo nindakake iki, mbusak sing lawas, nulis dhewe lan mriksa tes. Yen sampeyan nindakake kabeh kanthi bener, tanpa owah-owahan ing tes sing kudu ditindakake kaya sadurunge. Sawise kabeh wis dirampungake ing kode kasebut, kita kirimake kanggo mriksa lan golek kopi))
Sing luwih dhuwur peringkat pangembang, luwih akeh wektu dheweke kudu nggunakake komunikasi lan kurang wektu nulis kode. Pimpinan tim pangembang malah bisa nglampahi setengah, utawa luwih, wektu kerjane ing obrolan lan rapat-rapat lan nulis kode kurang asring (iki bisa nyebabake kelangan sethithik). Nanging yen sampeyan uga wong sing seneng ngomong, sampeyan bisa kanthi gampang berkembang saka posisi timbal tim menyang sisih managerial lan rampung lali bab kode, sedina muput karo macem-macem tim, pelanggan lan Managers liyane.
Mbok menawa kita bakal mungkasi kene. Matur nuwun kanggo kabeh sing wis rampung maca: seneng lan sinau basa Jawa ^^
GO TO FULL VERSION