Tugas khas pengembang Java pada sebuah proyek

Apa tanggung jawab khas seorang pengembang Java? Lagi pula, Anda perlu memahami apa yang Anda tuju dan apa yang pada akhirnya akan Anda lakukan, bukan? Hari ini saya ingin berbicara tentang sepuluh tugas utama yang dilakukan pengembang Java. Tapi pertama-tama, mari berkenalan dengan alat seperti Jira. Atau yuk segarkan ingatan kita jika sudah tidak asing lagi bagi Anda. Jira adalah alat interaksi pengguna, meskipun dalam beberapa kasus juga digunakan untuk manajemen proyek. Dengan kata lain, pengembangan proyek dipecah menjadi tugas-tugas kecil yang dijelaskan dalam alat ini. Tugas-tugas ini diberikan (ditugaskan) kepada pengembang, yang akan bertanggung jawab atas pelaksanaannya. Yang kami maksud dengan tugas adalah, misalnya, menambahkan beberapa fungsi. Seiring kemajuan yang dicapai, pengembang dan pakar lainnya menambahkan komentar tentang siapa yang melakukan apa dan berapa banyak waktu yang mereka habiskan—mereka melacak waktu. Hal ini dilakukan untuk melacak waktu yang dihabiskan: berapa banyak yang dihabiskan dan untuk apa. Idealnya, ini dilakukan sekali sehari: di malam hari sebelum berangkat, Anda melacak 8 jam Anda untuk tugas-tugas yang Anda habiskan. Fungsi Jira jauh lebih luas daripada yang dijelaskan di atas, tetapi ini sudah cukup untuk pemahaman awal. Jadi, apa tanggung jawab seorang pengembang Java?

1. Pengembangan solusi baru

Sebelum Anda membuat dan mengimplementasikan sesuatu, Anda perlu memikirkannya, bukan? Seperti yang saya katakan, ini mungkin saja tugas Jira yang akan diberikan kepada Anda, dan Anda akan bekerja untuk mengembangkan solusi baru, mencatat di Jira berapa banyak waktu yang Anda habiskan dan untuk apa. Hal ini juga bisa berupa diskusi dalam panggilan tim kelompok: setiap orang akan dapat mengungkapkan pendapatnya dan mengusulkan pendekatan yang mereka anggap terbaik. Dan di sini saya ingin mencatat beberapa poin. Pertama, profesi pengembang adalah bidang yang sangat kreatif, karena Anda perlu menemukan cara unik untuk memecahkan masalah menggunakan alat standar. Seringkali, satu masalah dapat memiliki banyak solusi berbeda: oleh karena itu, semuanya tergantung pada “semangat kreatif” pengembang, akumulasi basis pengetahuan dan pengalaman. Di sini Anda dapat menunjukkan semua kreativitas dan kejeniusan Anda, tetapi yang utama adalah jangan berlebihan: dalam hal ini, kode akan menjadi terlalu rumit dan tidak dapat dibaca dan akibatnya, setelah Anda keluar, tidak ada yang akan sepenuhnya memahami apa itu dan bagaimana itu bekerja. Dan Anda harus menulis ulang semuanya dari awal. Dan mereka mungkin mengingat Anda. Dan lebih dari sekali. Dan ini bukanlah kata-kata yang hangat dan baik. Apakah Anda membutuhkannya? Kedua, pengembang harus fleksibel dalam arti tidak terjebak pada satu solusi dan menutup diri terhadap solusi lain. Misalnya, Anda hanya perlu melakukan cara ini dan tidak ada yang lain. Hal ini dapat terjadi karena berbagai alasan: misalnya, Anda ingin membuktikan sudut pandang Anda, atau Anda telah mengembangkan dan menerapkan solusi Anda, yang membuat Anda sangat terikat dan, tentu saja, tidak mau mengakui bahwa itu bukan solusinya. terbaik. Ini bisa membutakan Anda. Faktanya, Anda harus bisa mengakui kesalahan Anda dan selalu terbuka terhadap hal-hal baru (“berpikiran terbuka”), bahkan jika Anda harus menghapus fungsionalitas yang telah Anda tulis selama berminggu-minggu dan yang sangat Anda banggakan. Saya ingat bagaimana suasana hati sepanjang hari dibuat oleh pelacak waktu seseorang di Jira dengan komentar: “Saya menghapus fungsi lahir mati saya. Saya menangis"

2. Menulis fungsionalitas baru

Ini adalah langkah logis setelah langkah sebelumnya - implementasi fungsionalitas baru. Semua pekerjaan pada proyek ini dibagi menjadi tugas-tugas dalam jira, yang diterima pengembang saat mereka bekerja. Ada beberapa pendekatan berbeda untuk masalah ini - "metodologi", lebih lanjut tentangnya dapat Anda baca di artikel JavaRush ini . Biasanya, tugas memiliki "Estimasi" - perkiraan waktu yang dibutuhkan untuk menyelesaikannya. Ini ditentukan oleh Anda sendiri saat Anda mengambil tugas, atau oleh pimpinan tim, atau selama perencanaan, pengembang bersama-sama memperkirakannya. Saat ini sangat jarang dapat ditebak secara akurat, karena banyak faktor berbeda yang mempengaruhi perkembangan. Misalnya, apakah pemrogram familiar atau asing dengan teknologi ini, apa pengalaman umumnya, berbagai kendala yang mungkin sudah terlihat selama pengembangan, dll. Oleh karena itu, jika Anda tidak memenuhi tenggat waktu ini saat mengembangkan fungsionalitas, tidak ada hal buruk yang akan terjadi. Ini hanyalah perkiraan umum. Namun sekali lagi, tidak semua proyek memiliki perkiraan tugas dan, bagi saya, jauh lebih mudah untuk hidup tanpanya, terutama ketika PM tidak menyodok Anda beberapa kali sehari dengan pertanyaan “Di mana perkiraannya? ” Oleh karena itu, Anda mengambil tugas, mengembangkan fungsionalitas yang diperlukan, mengunggahnya ke cabang umum di GIT , dan di jira mengubah status tugas menjadi "Siap untuk ditinjau" , yaitu, siap untuk dilihat (diperiksa) dan berdoa agar itu tidak dikembalikan kepada Anda dengan komentar tentang revisi.

3. Menulis tes fungsionalitas

Orang yang memeriksa kode Anda - peninjau - menyukai fungsionalitas yang Anda kembangkan, tetapi dia memiliki pertanyaan: di mana pengujiannya? Dan dia mengembalikan tugas itu kepada Anda untuk direvisi. Pengujian adalah bagian penting dari setiap aplikasi Java. Dengan menjalankannya, Anda dapat segera mengetahui di mana aplikasi tidak berfungsi dengan benar. Misalnya, seorang pengembang membuat beberapa perubahan di satu bagian sistem, yang menyebabkan perubahan perilaku di bagian lain, dan tidak menyadarinya selama pengembangan. Dengan menjalankan pengujian, dia akan dapat melihat pengujian yang gagal (yang tidak berfungsi dengan benar). Ini akan memberitahunya bahwa ada sesuatu yang rusak di bagian lain dari sistem. Oleh karena itu, dia tidak akan mengunggah perubahan yang dapat menyebabkan gangguan ke server, namun akan terus menyempurnakan solusinya. Ya, tentu saja, hanya sedikit pengembang yang menyukai tes, namun tidak dapat disangkal manfaat yang mereka berikan pada aplikasi. Seringkali klien sendiri yang menentukan tingkat cakupan tes yang harus dipatuhi (misalnya, 80%). Oleh karena itu, Anda perlu mengetahui berbagai jenis tes dan mampu menulisnya. Pengembang Java terutama menulis pengujian unit dan pengujian integrasi, sementara AQA (penguji otomasi) menangani pengujian yang lebih ekstensif (end-to-end). Anda dapat membaca lebih lanjut tentang mereka dan perwakilan profesi TI lainnya di ulasan saya .

4. Menemukan dan memperbaiki bug

Ini juga merupakan tugas yang sangat umum dan sering dilakukan oleh pengembang Java. Tugas utama QA dan AQA adalah menangkap bug. Artinya, mereka mencari tempat di mana program berperilaku salah, menimbulkan masalah di Jira, dan menyalahkan seseorang. Misalnya, seorang pemimpin tim, yang pada gilirannya memutuskan pengembang mana yang akan menugaskannya, bergantung pada beban dan pemahaman mereka terhadap bagian sistem ini. Setelah ini, pengembang mencari bug tersebut, menghabiskan waktu berjam-jam di debugger , menggunakan deskripsi masalah oleh spesialis QA untuk mengulangi situasi di mana bug tersebut terjadi. Selanjutnya, pengembang menemukan bug, memperbaikinya, dan mengirimkannya untuk ditinjau. Ya, mungkin saja pengembang tidak dapat mereproduksi bug tersebut, dan dia mengembalikan tugas tersebut ke spesialis QA dengan komentar tentangnya. Sepertinya tidak butuh waktu lama untuk menemukan dan memperbaiki bug tersebut, tetapi ada beberapa perbedaan. Semuanya bergantung terutama pada keakraban pengembang dengan bagian kode ini, pengalaman dan pengetahuan tentang masalah teoritis. Terkadang bug dapat ditemukan dan diperbaiki dalam 20 menit, dan terkadang memerlukan waktu tiga hari. Oleh karena itu, jenis tugas ini sangat sulit untuk dievaluasi terlebih dahulu, kecuali jika pengembang, setelah membaca deskripsinya, segera memahami apa, di mana, dan apa yang salah. Dalam hal ini, dia akan dapat menebak waktu dengan kurang lebih akurat.

5. Tinjauan kode

Seperti disebutkan di atas, segera setelah Anda menyelesaikan suatu tugas, tugas itu perlu dikirim untuk ditinjau, dan jika lolos, itu masuk ke thread umum, jika tidak, itu akan dikembalikan ke pengembang dengan komentar tentang apa yang perlu dilakukan. dikoreksi. Jelas bahwa semua ini diperiksa bukan oleh kekuatan yang lebih tinggi, tetapi oleh pengembang lain. Namun tidak semua developer diperbolehkan menjadi reviewer, melainkan hanya developer yang paling berpengalaman, yang memiliki pengalaman di baliknya dan dapat membedakan kode yang buruk dari yang baik. Peninjauan kode biasanya dilakukan dengan menggunakan alat bantu, misalnya Crucible . Peninjau meninjau kode dan, jika perlu, meninggalkan komentar di bawah beberapa baris. Komentar juga bisa bermacam-macam jenisnya. Misalnya, yang kritis, tanpa koreksi yang mana pengulas tidak akan meneruskan kodenya, dan yang lainnya kemungkinan besar hanya komentar tentang pendekatan yang dipilih, yang dapat didengarkan, dicatat, atau diabaikan oleh pengembang. Tim dapat membuat prosedur dan aturannya sendiri untuk melakukan tinjauan, menyepakati apa yang perlu diperhatikan dan apa yang tidak, dalam jangka waktu berapa tinjauan kode harus dilakukan, dll. Untuk melakukan review, pengalaman saja tidak cukup: Anda masih perlu banyak mengembangkan ke arah teknis, membaca berbagai buku (misalnya, “Clean Code” ). Jika Anda tertarik dengan nuansa melakukan review kode menurut Google, saya menyarankan Anda untuk membaca artikel ini .

6. Analisis kode

Karena proyek ini ditulis secara bersamaan oleh beberapa orang yang mempunyai pemikiran berbeda, kode dan pendekatan mereka akan berbeda. Dan seiring berjalannya waktu, semuanya lambat laun akan berubah menjadi bubur. Untuk meningkatkan kode, terkadang Anda membuat tugas untuk dianalisis, mungkin modul tertentu atau keseluruhan aplikasi, untuk menemukan kekurangan dan menandainya, dan kemudian membuat tugas pemfaktoran ulang berdasarkan komentar ini. Analisis ini juga membantu dalam situasi di mana beberapa jalan pintas yang lebih sederhana tidak terlihat sejak awal pengembangan, namun dapat dilihat sekarang. Misalnya, logika yang sama sering diulang dalam beberapa metode dan, oleh karena itu, logika tersebut dapat dipindahkan ke metode terpisah dan digunakan kembali berkali-kali. Ya, mungkin beberapa kelas menjadi sangat membengkak, atau beberapa kode menjadi sulit dipertahankan atau ketinggalan jaman, atau... Tugas analisis membantu meningkatkan kualitas kode dan aplikasi. Meskipun menurut saya, menganalisis kode dalam jumlah besar bisa menjadi tugas yang membosankan.

7. Pemfaktoran ulang kode

Bagian analisis selanjutnya adalah pemfaktoran ulang kode. Mungkin sudah ketinggalan jaman, tidak diperlukan lagi, tulisannya buruk, sulit dibaca, dan sebagainya. Anda harus selalu mengupayakan kesempurnaan (walaupun tidak ada) dan kode terkini, menghapus semua yang tidak perlu, karena ini hanya membingungkan dan menghalangi Anda untuk melihat esensi fungsinya. Tentu saja Anda tidak mungkin melihat tugas-tugas ini di awal proyek: tugas-tugas ini hanya terjadi pada tahap pengembangan selanjutnya, ketika aplikasi dipoles dan disempurnakan. Di sini, mungkin tepat untuk berkonsultasi dengan rekan kerja tentang bagaimana mereka akan melakukannya dan hambatan apa yang mereka lihat. Inti dari tugas-tugas tersebut mirip dengan pengembangan fungsionalitas baru. Misalnya, Anda menerima tugas untuk mengedit beberapa fungsi tanpa mengubah perilakunya. Untuk melakukan ini, Anda menghapus yang lama, menulis sendiri dan memeriksa tesnya. Jika Anda melakukan semuanya dengan benar, tanpa membuat perubahan pada pengujian, pengujian tersebut akan berfungsi seperti sebelumnya. Setelah semuanya beres di kode, kami mengirimkannya untuk ditinjau dan pergi minum kopi))

8. Penulisan dokumentasi

Bayangkan Anda adalah seorang pengembang baru di suatu proyek yang telah lama dikembangkan. Anda perlu membiasakan diri dengannya atau melakukan tugas tertentu, misalnya menangkap bug. Bagaimana Anda akan menavigasi proyek ini? Tarik anggota tim Anda setiap lima menit? Dan jika mereka sibuk atau di akhir pekan, lalu bagaimana? Inilah sebabnya mengapa ada dokumentasi, sehingga orang yang tidak terbiasa dengan fungsi tersebut dapat masuk, menemukan halaman yang tepat dan dengan cepat memahami apa yang dilakukan bagian aplikasi yang dia minati. Tetapi seseorang juga harus mengisi dokumentasinya ^^ Jika proyek memiliki dokumentasi yang harus didukung oleh pengembang, ketika mengimplementasikan fungsionalitas baru mereka menjelaskannya, dan dengan berbagai perubahan dan pemfaktoran ulang mereka memperbarui dokumentasi tersebut. Situasi juga mungkin terjadi ketika seorang spesialis terpisah, seorang penulis teknis, dipekerjakan untuk menulis, mendukung dan mengendalikan dokumentasi. Jika spesialis seperti itu ada, itu membuat hidup pengembang biasa sedikit lebih mudah.

9. Partisipasi dalam berbagai aksi unjuk rasa

Pengembang menghabiskan banyak waktu pada berbagai pertemuan, negosiasi, dan perencanaan. Contoh paling sederhana adalah “pertemuan harian” (daily meeting), di mana Anda perlu menceritakan apa yang Anda lakukan kemarin dan apa yang akan Anda lakukan hari ini. Selain itu, Anda perlu melakukan panggilan tatap muka, misalnya dengan spesialis QA, sehingga dia dapat menunjukkan/menjelaskan nuansa reproduksi bug, atau mendiskusikan nuansa dan persyaratan dengan analis bisnis, atau organisasi. masalah dengan PM. Oleh karena itu, meskipun seorang developer mungkin adalah seorang introvert yang lebih menyukai kesendirian, dia harus tetap bisa menemukan bahasa yang sama dengan orang lain (setidaknya sedikit). Semakin tinggi peringkat seorang pengembang, semakin banyak waktu yang ia habiskan untuk berkomunikasi dan semakin sedikit waktu untuk menulis kode. Pemimpin tim pengembang bahkan dapat menghabiskan separuh, atau bahkan lebih, waktu kerjanya untuk melakukan percakapan dan rapat serta menulis kode lebih jarang (hal ini dapat menyebabkan kehilangan sedikit kendali). Namun jika Anda juga termasuk orang yang suka berbicara, Anda dapat dengan mudah berkembang dari posisi pemimpin tim ke sisi manajerial dan benar-benar melupakan kode, berkomunikasi sepanjang hari dengan berbagai tim, pelanggan, dan manajer lainnya.

10. Melakukan/lulus wawancara

Jika Anda bekerja untuk perusahaan outsourcing atau outstaffing, Anda harus sering menjalani wawancara eksternal, ketika Anda perlu “dijual” kepada klien (kemudian Anda dapat diwawancarai oleh seseorang dari pihak klien), dan wawancara internal, untuk meningkatkan peringkat Anda dalam perusahaan. Saya akan menyebut ini sebagai faktor yang baik untuk pengembangan, karena karena seringnya wawancara, pengetahuan Anda harus selalu bugar: Anda tidak akan berkarat dan rileks, karena jika Anda bersantai di IT, Anda bisa benar-benar terbang keluar lapangan. Ketika Anda menjadi pengembang yang lebih berpengalaman, Anda akan dapat mengunjungi sisi lain: tidak lewat, tetapi melakukan wawancara. Percayalah, Anda akan sangat terkejut jika melihatnya dari sudut pandang ini, karena melakukan wawancara bisa lebih menakutkan daripada sekedar lewat. Anda harus memiliki strategi wawancara sendiri, daftar pertanyaan, dan punya waktu untuk mengajukan pertanyaan tentang semua topik yang diperlukan dalam satu jam. Dan setelah itu, Anda bertanggung jawab atas umpan balik, karena dengan mengandalkannya, seseorang mungkin menerima atau tidak menerima tawaran atau promosi yang telah lama ditunggu-tunggu. Nah, dan sebaliknya: Anda dapat melewatkan kandidat yang benar-benar lemah untuk posisi yang tidak sesuai dengannya, dan kemudian Anda mungkin ditanya: bagaimana Anda bisa merindukannya dengan tingkat pengetahuan seperti itu? Oleh karena itu, saat menjalani wawancara, perlu diingat bahwa lawan bicara Anda juga sedang mengalami masa-masa sulit, dan mungkin juga sedang mengalami stres. Wawancara apa pun menimbulkan stres bagi kandidat dan pewawancara. Mungkin kita akan berakhir di sini. Terima kasih kepada semua orang yang selesai membaca: suka dan belajar Java ^^