Apa tanggung jawab khas pangembang Jawa? Sawise kabeh, sampeyan kudu ngerti apa sing sampeyan lakoni lan apa sing bakal sampeyan lakoni, ta? Dina iki aku arep ngomong babagan sepuluh tugas penting sing ditindakake pangembang Jawa.
Nanging dhisik, ayo padha kenalan karo piranti sing diarani Jira. Utawa refresh memori saka iku, yen sampeyan wis menowo karo. Jiraminangka alat kanggo ngatur interaksi manungsa, sanajan ing sawetara kasus uga digunakake kanggo manajemen proyek. Ing tembung liyane, proyek dipérang dadi tugas cilik sing diterangake ing alat iki. Tugas kasebut ditugasake kanggo pangembang, sing tanggung jawab kanggo implementasine. Tugas bisa uga, contone, nambah sawetara fungsi. Nalika tugas dileksanakake, pangembang lan spesialis liyane nambah komentar babagan sapa sing nindakake apa lan suwene wektu sing ditindakake. Iki ditindakake kanggo tujuan nelusuri wektu - kanggo ngerti sepira wektu sing ditindakake kanggo tugas apa. Saenipun, iki rampung sapisan dina: Sadurunge ninggalake meja ing wayah sore, sampeyan kudu nemtokake jumlah jam kerja 8 sing sampeyan gunakake kanggo macem-macem tugas. Ana luwih akeh fungsi Jira tinimbang sing kasebut ing ndhuwur, nanging iki bakal cukup kanggo pemahaman awal.
Sing luwih dhuwur pangkat pangembang, luwih akeh wektu dheweke kudu nggunakake komunikasi lan luwih sithik wektu nulis kode. Pimpinan dev bisa nglampahi setengah, utawa malah luwih, dina kerjane ing obrolan lan rapat-rapat lan bisa uga nulis kode luwih jarang (bisa uga nyebabake dheweke kelangan sethithik saka keahliane coding). Nanging yen sampeyan seneng ngomong, sampeyan bisa, minangka pimpinan tim, transisi menyang manajemen lan lali babagan nulis kode, tinimbang, sampeyan bakal nglampahi sedina muput karo macem-macem tim, pelanggan, lan manajer liyane.

1. Ngrancang solusi anyar
Sadurunge nggawe lan ngleksanakake soko, sampeyan kudu konsep, bener? Kaya sing wis dakkandhakake sadurunge, iki mung bisa dadi tugas ing Jira sing ditugasake kanggo sampeyan, supaya sampeyan bisa ngrancang solusi anyar, ngrekam ing Jira suwene wektu sing sampeyan gunakake lan apa. Karya iki uga bisa kedadeyan sajrone diskusi ing telpon konferensi tim: kabeh wong bisa nyatakake pendapat lan ngusulake pendekatan sing dianggep paling apik. Lan ing kene aku pengin nyathet sawetara poin. Kaping pisanan, pangembangan piranti lunak minangka profesi sing kreatif banget, amarga sampeyan kudu nggunakake alat standar kanggo nggawe cara anyar kanggo ngrampungake masalah. Siji tugas asring duwe macem-macem solusi. Mulane, kabeh gumantung ing kreatifitas pangembang, kang akeh banget dipengaruhi dening akumulasi kawruh lan pengalaman. Sampeyan bisa nuduhake kabeh kreatifitas lan genius ing kene, nanging sing penting ora keluwihan. Yen sampeyan nindakake, kode bakal dadi rumit banget lan ora bisa diwaca. Akibaté, sawise sampeyan lunga, ora ana sing bakal ngerti apa sing sampeyan kode lan cara kerjane. Lan dheweke kudu nulis maneh kabeh saka awal. Lan bisa uga ngelingi sampeyan. Luwih saka sepisan. Lan ora mungkin ana tembung sing apik lan apik sing diucapake. Apa sampeyan butuh kuwi? Kapindho, pangembang kudu njaga keluwesan psikologis kanthi arti sampeyan ora kudu nempel ing solusi siji lan dadi tertutup kanggo wong liya. Kaya-kaya sampeyan kudu nindakake kanthi mung siji cara lan ora ana pilihan liyane. Sampeyan bisa uga tiba ing jebakan iki amarga macem-macem alasan. Contone, umpamane sampeyan pengin mbuktekake manawa sudut pandang sampeyan bener. Utawa mbok menawa sampeyan wis ngrancang lan ngetrapake solusi sing wis dikenal dhewe - mesthi, sampeyan ora pengin ngakoni yen iku dudu sing paling apik. Kahanan kasebut bisa nggawe sampeyan wuta. Nyatane, sampeyan kudu bisa ngakoni kesalahane lan tansah mbukak pikiran, sanajan sampeyan kudu mbusak fungsi sing sampeyan bangga lan wis ngodhe luwih saka seminggu. Aku kelingan carane kanca kerja padhang dina saben wong sapisan dening ninggalake komentar nelusuri wektu iki ing Jira: "Aku mbusak fitur mati sandi. Lan mourned."2. Nulis fungsi anyar
Langkah iki - ngleksanakake fungsi anyar - nderek kanthi logis sawise sing sadurunge. Kabeh karya sing melu proyek dipérang dadi tugas ing Jira, sing banjur disedhiyakake kanggo pangembang adhedhasar beban kerjane. Ana macem-macem pendekatan kanggo proses iki, sing dikenal minangka "metodologi," sing bisa diwaca kanthi luwih rinci ing artikel iki ing CodeGym . Minangka aturan, tugas duwe perkiraan, yaiku wektu sing diprediksi sing dibutuhake kanggo ngrampungake. Iki disetel dening sampeyan, pangembang nalika sampeyan nampa tugas, utawa dening pimpinan tim, utawa nalika ngrancang, kanthi bebarengan dening tim pangembangan. Tebakan wektu iki arang banget akurat, amarga akeh faktor sing mengaruhi pangembangan piranti lunak. Contone, apa programmer wis menowo utawa ora menowo karo teknologi sing cocog, pengalaman sakabèhé, macem-macem pitfalls unforeseeable, etc. Dadi, yen sampeyan ora mencet kabeh prakiraan wektu nalika coding, iku ora mburi donya. Iki mung perkiraan umum. Sing jarene, ora kabeh proyek mbutuhake perkiraan wektu. Secara pribadi, aku luwih gampang urip tanpa, utamane nalika PM ora ngganggu aku kaping pirang-pirang dina kanthi pitakonan "endi perkiraan wektu sampeyan?" Dadi, sampeyan entuk tugas,Siap ditinjau " ing Jira lan ndedonga supaya owah-owahan kode sampeyan ora bali kanggo revisi bebarengan karo komentar.3. Tes nulis
Reviewer, yaiku wong sing mriksa kode sampeyan, seneng karo fungsi sing sampeyan tindakake, nanging dheweke duwe pitakonan kanggo sampeyan: ing ngendi tes sing ana gandhengane? Dadi dheweke ngirim tugas bali menyang sampeyan kanggo revisi. Tes minangka bagean penting saka aplikasi Java. Kanthi nganakake tes, sampeyan bisa langsung ngenali panggonan sing aplikasi ora bisa digunakake kanthi bener. Contone, pangembang nggawe sawetara owah-owahan ing siji bagéan saka sistem, kang nyebabake owah-owahan ing prilaku ing bagean liyane, nanging ora sok dong mirsani iki nalika coding. Kanthi nganakake tes, dheweke bakal bisa ndeleng manawa tes tartamtu gagal, tegese ora ngasilake asil sing dikarepake. Iki ngandhani yen ana sing rusak ing papan liya ing sistem kasebut. Ngerti iki, dheweke ora bakal nindakake owah-owahan ing server, lan bakal terus nggarap debugging kode kasebut. iya, sawetara pangembang seneng nulis tes, nanging ora bisa nolak keuntungan sing digawa kanggo pangembangan piranti lunak. Klien dhewe asring nuduhake tingkat jangkoan tes sing pengin dijaga (contone, 80%). Tegese sampeyan kudu ngertimacem-macem jinis tes lan bisa nulis. Pangembang Java utamane nulis tes unit lan tes integrasi, dene tes sing luwih ekstensif (end-to-end) ditangani dening ahli QA lan tes otomatisasi.4. Nemokake lan ndandani kewan omo
Iki uga tugas sing umum banget kanggo pangembang Java. Tugas utama ahli otomatisasi QA lan uji coba yaiku nyekel kewan omo. Ing tembung liyane, padha golek panggonan ngendi program tumindak salah, banjur padha nggawe tugas ing Jira lan menehi wong. Contone, kanggo pimpinan tim, sing banjur mutusake pangembang sing bakal ditugasake, gumantung saka beban kerja lan akrab karo bagean sistem sing cocog. Sawisé iku, pangembang sing ditugasake mburu panyebab oyod saka bug, mbuwang jam ing debugger, nggunakake katrangan bug sing diwenehake dening ahli QA kanggo ngasilake kahanan ing ngendi bug kasebut kedadeyan. Sawise pangembang nemokake bug lan ndandani, dheweke ngirim perbaikan kanggo ditinjau. Kadhangkala pangembang ora bisa ngasilake bug kasebut, mula dheweke ngirim tugas kasebut menyang pakar QA bebarengan karo komentar panjelasan. Kayane ora butuh wektu suwe kanggo nemokake lan ndandani bug, nanging ana sawetara nuansa. Iku kabeh utamané gumantung carane uga kenalan pangembang karo bagean kode iki, lan pengalaman lan kawruh teori. Kadhangkala bug bisa ditemokake lan didandani sajrone 20 menit, lan kadhangkala butuh telung dina. Iki tegese jinis tugas iki angel banget kanggo ngira luwih dhisik, kajaba pangembang, nalika maca katrangan kasebut, langsung ngerti apa, ing endi, lan kepiye bug kasebut. Ing kasus iki,5. Kode review
Kaya kasebut ing ndhuwur, sanalika sampeyan ngrampungake tugas, kudu dikirim kanggo ditinjau. Yen liwat review, banjur pindhah menyang cabang utama. Yen ora, bali menyang pangembang karo komentar sing kudu ditangani. Mesthi wae, sampeyan ngerti manawa kode sampeyan wis dicenthang kabeh dening para pangembang liyane, dudu kanthi kekuwatan sing dhuwur. Yen ngandika, ora saben wong diijini kanggo nindakake review kode - mung pangembang paling pengalaman hardened dening laku nyata, sing bisa mbedakake antarane kode apik lan kode ala. Tinjauan kode biasane ditindakake nggunakake alat bantu kayata Crucible. Reviewer mbukak kode lan, yen perlu, ninggalake komentar babagan baris tartamtu. Bisa uga ana macem-macem komentar. Contone, sawetara kritis. Yen ora ditangani, panliti ora bakal ngidini kode kasebut ditindakake. Komentar liyane, umpamane, mung komentar babagan pendekatan sing dipilih. Iki pangembang bisa ngrungokake, njupuk cathetan, utawa nglirwakake. Tim bisa nggawe aturan lan tata cara dhewe kanggo review kode, setuju babagan apa sing kudu digatekake lan apa sing ora, wektu apa sing kudu diwenehake kanggo ngrampungake review kode, lsp. Pengalaman mung ora cukup kanggo nindakake review: sampeyan isih kudu tuwuh akeh ing katrampilan teknis lan maca macem-macem buku (contone, "Kode Resik").6. Analisis kode
Amarga sawetara wong sing mikir beda nulis kode kanggo proyek kasebut bebarengan, kode lan pendekatane bakal beda. Lan liwat wektu, kabeh mboko sithik dadi kekacoan. Kanggo nambah kode, kadhangkala tugas digawe kanggo, ngomong, njelasno modul tartamtu utawa kabeh aplikasi, golek lan njupuk cathetan saka shortcomings, lan mengko nggawe tugas refactoring adhedhasar analisis iki. Analisis kasebut uga mbantu ing kahanan nalika pangembangan diwiwiti, tim ora bisa ndeleng sawetara solusi sing luwih gampang lan ringkes, nanging saiki bisa dideleng. Contone, logika asring diduplikasi ing sawetara cara. Mulane, bisa diekstrak menyang cara sing kapisah, sing banjur bisa digunakake maneh. Utawa mbok menawa kelas wis akeh banget, utawa sawetara kode dadi angel kanggo njaga utawa ketinggalan jaman, utawa ... Tugas analisis mbantu nambah kualitas kode lan aplikasi. Sing jarene, kanggo aku, nganalisa kode sing akeh banget bisa mboseni.7. Kode refactoring
Bagian sabanjure analisis kode yaiku refactoring. Kode bisa dadi ketinggalan jaman, lungse, ditulis kanthi apik, angel diwaca, lan liya-liyane. Sampeyan kudu tansah ngupayakake kesempurnaan (sanajan ora ana) lan kanggo kode sing paling anyar, mbusak apa wae sing ora perlu, amarga superfluous mung nyebabake kebingungan lan ngganggu kemampuan kanggo ndeleng apa sing ditindakake kode kasebut. Ora perlu dikandhakake manawa sampeyan ora bisa ndeleng tugas kasebut ing wiwitan proyek: sampeyan nemoni ing tahap pangembangan sabanjure nalika aplikasi dipoles lan digawa menyang sempurno. Ing kene, bisa uga cocog kanggo takon karo kanca kerja babagan apa sing bakal ditindakake lan masalah apa sing dideleng. Ing atine, tugas kasebut padha karo ngembangake fungsi anyar. Contone, umpamane sampeyan nampa tugas kanggo ngowahi sawetara fungsi tanpa ngganti prilaku. Kanggo nindakake iki, mbusak kode lawas, nulis dhewe, lan mriksa tes. Yen sampeyan nindakake kabeh kanthi bener, banjur tanpa owah-owahan ing tes, kabeh kudu lulus kaya sadurunge. Sawise kabeh ing kode kaya sing dikarepake, kita kirimake kanggo ditinjau, lan nyruput kopi :)8. Nulis dokumentasi
Bayangake sampeyan minangka pangembang anyar ing sawetara proyek pangembangan piranti lunak jangka panjang. Sampeyan kudu familiarize dhewe karo basis kode utawa nindakake sawetara tugas tartamtu, contone, diagnosa bug. Carane sampeyan bakal navigasi project? Ngganggu kanca saben limang menit? Lan yen lagi sibuk utawa akhir minggu, banjur apa? Iki sebabe kita duwe dokumentasi - supaya wong sing ora ngerti kode kasebut bisa mlebu, nemokake kaca sing cocog, lan kanthi cepet ngerteni apa sing kedadeyan ing bagean aplikasi sing dadi minat dheweke. Nanging ana sing kudu nggawe dokumentasi, haha. Yen proyek duwe dokumentasi sing kudu didhukung para pangembang, banjur nalika nindakake fungsi anyar, dheweke nggambarake lan nganyari dokumentasi kasebut bebarengan karo owah-owahan kode utawa refactoring. Sampeyan uga bisa duwe kahanan ing ngendi karyawan kapisah - panulis teknis - disewakake kanggo nulis, njaga, lan ngawasi dokumentasi. Yen spesialis kuwi kasedhiya, urip pangembang biasa sethitik luwih gampang.9. Macem-macem rapat
Akeh wektu pangembang digunakake ing macem-macem rapat, negosiasi, lan perencanaan. Conto sing paling gampang yaiku rapat stand-up saben dina, ing ngendi sampeyan kudu nglaporake apa sing sampeyan lakoni wingi lan apa sing bakal ditindakake dina iki. Kajaba iku, sampeyan kudu duwe telpon siji-siji, contone, karo penguji, supaya bisa nduduhake / nerangake nuansa reproduksi bug, utawa ngrembug subtleties lan syarat karo analis bisnis utawa ngomong babagan masalah organisasi. karo PM. Iki tegese sanajan pangembang bisa dadi introvert sing luwih seneng kesepian, dheweke isih kudu bisa nemokake papan sing padha karo wong liya (uga, paling sethithik).
GO TO FULL VERSION