Tugas khas pengembang Java pada suatu proyek

Apa tanggung jawab khas pengembang Java? Lagi pula, Anda perlu memahami apa yang Anda hadapi dan apa yang akhirnya akan Anda lakukan, bukan? Hari ini saya ingin berbicara tentang sepuluh tugas penting yang dilakukan oleh pengembang Java. Tapi pertama-tama, mari berkenalan dengan alat bernama Jira. Atau segarkan ingatan Anda tentangnya, jika Anda sudah terbiasa dengannya. Jiraadalah alat untuk mengatur interaksi manusia, meskipun dalam beberapa kasus juga digunakan untuk manajemen proyek. Dengan kata lain, sebuah proyek dipecah menjadi tugas-tugas kecil yang dijelaskan dalam alat ini. Tugas-tugas ini diberikan kepada pengembang, yang bertanggung jawab atas implementasinya. Sebuah tugas dapat berupa, misalnya, menambahkan beberapa fungsionalitas. Saat tugas dilakukan, pengembang dan pakar lainnya menambahkan komentar tentang siapa yang melakukan apa dan berapa banyak waktu yang mereka habiskan. Ini dilakukan untuk tujuan pelacakan waktu — untuk mengetahui berapa banyak waktu yang dihabiskan untuk tugas apa. Idealnya, ini dilakukan sekali sehari: Sebelum Anda meninggalkan meja Anda di malam hari, tunjukkan berapa banyak dari 8 jam kerja yang Anda habiskan untuk berbagai tugas. Ada lebih banyak fungsi Jira daripada yang dijelaskan di atas, tetapi ini akan cukup untuk pemahaman awal.

1. Merancang solusi baru

Sebelum Anda membuat dan mengimplementasikan sesuatu, Anda perlu membuat konsep, bukan? Seperti yang saya katakan sebelumnya, ini bisa saja menjadi tugas di Jira yang diberikan kepada Anda, jadi Anda bekerja untuk merancang solusi baru, mencatat di Jira berapa banyak waktu yang Anda habiskan dan untuk apa. Pekerjaan ini juga dapat terjadi selama diskusi pada panggilan konferensi tim: setiap orang dapat mengungkapkan pendapat mereka dan mengusulkan pendekatan yang mereka anggap terbaik. Dan di sini saya ingin mencatat beberapa poin. Pertama, pengembangan perangkat lunak adalah profesi yang sangat kreatif, karena Anda perlu menggunakan alat standar untuk menemukan cara baru dalam memecahkan masalah. Satu tugas seringkali dapat memiliki banyak solusi berbeda. Karenanya, semuanya bergantung pada kreativitas pengembang, yang sangat dipengaruhi oleh akumulasi pengetahuan dan pengalaman mereka. Anda dapat memamerkan semua kreativitas dan kejeniusan Anda di sini, tapi yang penting jangan berlebihan. Jika Anda melakukannya, kode akan menjadi terlalu rumit dan tidak terbaca. Akibatnya, setelah Anda pergi, tidak ada yang akan sepenuhnya memahami apa yang Anda kodekan dan cara kerjanya. Dan mereka harus menulis ulang semuanya dari awal. Dan mereka mungkin mengenang Anda. Lebih dari sekali. Dan kecil kemungkinannya akan ada kata-kata hangat dan baik yang diucapkan. Apakah Anda membutuhkan itu? Kedua, pengembang harus mempertahankan fleksibilitas psikologis dalam arti bahwa Anda tidak boleh bergantung pada satu solusi dan menjadi tertutup bagi orang lain. Seolah-olah Anda harus melakukan sesuatu hanya dengan satu cara dan tidak ada pilihan lain. Anda mungkin jatuh ke dalam perangkap ini karena berbagai alasan. Misalnya, Anda ingin membuktikan bahwa sudut pandang Anda benar. Atau mungkin Anda telah merancang dan mengimplementasikan solusi yang Anda kenal sendiri — tentu saja, Anda tidak ingin mengakui bahwa itu bukan yang terbaik. Situasi ini bisa membuat Anda cukup buta. Nyatanya, Anda harus bisa mengakui kesalahan Anda dan selalu berpikiran terbuka, bahkan jika Anda harus menghapus fungsionalitas yang Anda banggakan dan telah membuat kode selama lebih dari seminggu. Saya ingat bagaimana seorang rekan kerja mencerahkan hari setiap orang dengan meninggalkan komentar pelacakan waktu ini di Jira: "Saya menghapus fitur lahir mati saya. Dan berduka."

2. Menulis fungsionalitas baru

Langkah ini — menerapkan fungsionalitas baru — mengikuti secara logis setelah langkah sebelumnya. Semua pekerjaan yang terlibat dalam sebuah proyek dibagi menjadi tugas-tugas di Jira, yang kemudian diberikan kepada pengembang berdasarkan beban kerja mereka. Ada beberapa pendekatan berbeda untuk proses ini, yang dikenal sebagai "metodologi", yang dapat Anda baca lebih detail di artikel CodeGym ini . Sebagai aturan, tugas memiliki perkiraan, yang merupakan perkiraan waktu yang dibutuhkan untuk menyelesaikannya. Itu diatur baik oleh Anda, pengembang saat Anda menerima tugas, atau oleh pimpinan tim, atau selama perencanaan, secara kolektif oleh tim pengembangan. Tebakan kali ini sangat jarang akurat, karena begitu banyak faktor berbeda yang memengaruhi pengembangan perangkat lunak. Misalnya, apakah seorang programmer akrab atau tidak terbiasa dengan teknologi yang relevan, pengalamannya secara keseluruhan, berbagai jebakan yang tidak terduga, dll. Jadi, jika Anda tidak mencapai semua perkiraan waktu Anda saat membuat kode, itu bukanlah akhir dari dunia. Ini hanya perkiraan umum. Meskipun demikian, tidak semua proyek memerlukan estimasi waktu. Secara pribadi, saya merasa jauh lebih mudah untuk hidup tanpanya, terutama ketika PM tidak mengganggu saya beberapa kali sehari dengan pertanyaan "di mana perkiraan waktu Anda?" Jadi, Anda mendapat tugas,Siap untuk ditinjau " di Jira dan berdoa agar perubahan kode Anda tidak dikembalikan untuk direvisi bersama dengan komentar.

3. Tes tulis

Peninjau, yaitu orang yang memeriksa kode Anda, menyukai fungsionalitas yang Anda terapkan, tetapi dia memiliki pertanyaan untuk Anda: di mana pengujian terkait? Jadi dia mengirimkan tugas itu kembali kepada Anda untuk direvisi. Tes adalah bagian penting dari setiap aplikasi Java. Dengan menjalankan tes, Anda dapat segera mengidentifikasi tempat di mana aplikasi tidak bekerja dengan benar. Misalnya, pengembang membuat beberapa perubahan di satu bagian sistem, yang mengakibatkan perubahan perilaku di bagian lain, tetapi dia tidak menyadarinya saat membuat kode. Dengan menjalankan tes, dia akan dapat melihat bahwa tes tertentu gagal, artinya tes tersebut tidak memberikan hasil yang diharapkan. Ini memberitahunya bahwa ada sesuatu yang rusak di tempat lain dalam sistem. Mengetahui hal ini, dia tidak akan melakukan perubahan yang merusak ke server, dan sebaliknya akan terus bekerja untuk men-debug kodenya. Ya, sedikit pengembang yang suka menulis tes, tetapi tidak dapat disangkal manfaat yang mereka berikan untuk pengembangan perangkat lunak. Klien sendiri sering menunjukkan tingkat cakupan tes yang ingin mereka pertahankan (misalnya, 80%). Itu artinya Anda perlu tahuberbagai jenis tes dan dapat menulisnya. Pengembang Java terutama menulis pengujian unit dan pengujian integrasi, sedangkan pengujian yang lebih ekstensif (end-to-end) ditangani oleh QA dan ahli otomasi pengujian.

4. Menemukan dan memperbaiki bug

Ini juga merupakan tugas yang sangat umum dan sering dilakukan oleh pengembang Java. Tugas utama QA dan pakar otomasi pengujian adalah menangkap bug. Dengan kata lain, mereka mencari tempat di mana program berperilaku salah, lalu membuat tugas di Jira dan menugaskannya kepada seseorang. Misalnya, kepada pimpinan tim, yang, pada gilirannya, memutuskan pengembang mana yang akan ditugaskan kepada mereka, bergantung pada beban kerja dan keakraban mereka dengan bagian sistem yang relevan. Setelah itu, pengembang yang ditugaskan memburu akar penyebab bug, menghabiskan berjam-jam dalam debugger, menggunakan deskripsi bug yang disediakan oleh pakar QA untuk mereproduksi kondisi tempat terjadinya bug. Setelah pengembang menemukan bug dan memperbaikinya, dia mengirimkan perbaikan untuk ditinjau. Terkadang pengembang tidak dapat mereproduksi bug, jadi dia mengirimkan tugas kembali ke pakar QA bersama dengan komentar penjelasan. Sepertinya tidak perlu waktu lama untuk menemukan dan memperbaiki bug, tetapi ada beberapa perbedaan. Itu semua terutama tergantung pada seberapa baik pengembang mengenal bagian kode ini, dan pada pengalaman serta pengetahuan teoretisnya. Terkadang bug dapat ditemukan dan diperbaiki dalam 20 menit, dan terkadang bisa memakan waktu tiga hari. Ini berarti bahwa jenis tugas ini sangat sulit diperkirakan sebelumnya, kecuali pengembang, setelah membaca deskripsi, segera memahami apa, di mana, dan bagaimana bug tersebut. Pada kasus ini,

5. Tinjauan kode

Seperti disebutkan di atas, segera setelah Anda menyelesaikan tugas, itu harus dikirim untuk ditinjau. Jika lolos review, maka masuk ke cabang utama. Jika tidak, dikembalikan ke pengembang dengan komentar yang perlu ditangani. Tentu saja, Anda memahami bahwa semua kode Anda diperiksa oleh sesama pengembang, bukan oleh kekuatan tinggi. Meskipun demikian, tidak semua orang diizinkan untuk melakukan tinjauan kode — hanya pengembang paling berpengalaman yang diperkeras oleh praktik dunia nyata, yang dapat membedakan antara kode yang baik dan kode yang buruk. Ulasan kode biasanya dilakukan dengan menggunakan alat pembantu seperti Crucible. Peninjau memeriksa kode dan, jika perlu, meninggalkan komentar tentang baris tertentu. Komentar bisa bermacam-macam. Misalnya, ada yang kritis. Jika tidak ditangani, maka peninjau tidak akan mengizinkan kode untuk dikomit. Komentar lainnya adalah, katakanlah, hanya komentar tentang pendekatan yang dipilih. Ini pengembang dapat mendengarkan, mencatat, atau mengabaikan. Sebuah tim dapat membuat aturan dan prosedurnya sendiri untuk tinjauan kode, menyepakati tentang apa yang perlu diperhatikan dan apa yang tidak, kerangka waktu apa yang harus dialokasikan untuk menyelesaikan tinjauan kode, dll. Pengalaman saja tidak cukup untuk melakukan tinjauan: Anda masih perlu banyak berkembang dalam keterampilan teknis Anda dan membaca berbagai buku (misalnya, "Kode Bersih").

6. Analisis kode

Karena beberapa orang yang berpikir berbeda menulis kode untuk proyek secara bersamaan, kode dan pendekatan mereka akan berbeda. Dan seiring waktu, semuanya berangsur-angsur berubah menjadi berantakan. Untuk meningkatkan kode, terkadang tugas dibuat untuk, katakanlah, menganalisis modul tertentu atau seluruh aplikasi, menemukan dan mencatat kekurangan, dan kemudian membuat tugas pemfaktoran ulang berdasarkan analisis ini. Analisis semacam itu juga membantu dalam situasi di mana, saat pengembangan dimulai, tim tidak dapat melihat beberapa solusi yang lebih sederhana dan ringkas, tetapi mereka melihatnya sekarang. Misalnya, logika sering digandakan dalam beberapa metode. Dengan demikian, dapat diekstraksi menjadi metode terpisah, yang kemudian dapat digunakan kembali berkali-kali. Atau mungkin sebuah kelas menjadi terlalu membengkak, atau beberapa kode menjadi sulit dipertahankan atau ketinggalan jaman, atau... Tugas analisis membantu meningkatkan kualitas kode dan aplikasi. Meskipun demikian, bagi saya, menganalisis kode dalam jumlah besar bisa jadi membosankan.

7. Memfaktorkan ulang kode

Bagian selanjutnya dari analisis kode adalah refactoring. Kode dapat menjadi usang, usang, ditulis dengan buruk, sulit dibaca, dan sebagainya. Anda harus selalu berusaha untuk kesempurnaan (walaupun itu tidak ada) dan untuk kode terbaru, menghapus apa pun yang berlebihan, karena yang berlebihan hanya menyebabkan kebingungan dan mengganggu kemampuan untuk melihat apa yang dilakukan kode tersebut. Tak perlu dikatakan bahwa Anda tidak mungkin melihat tugas-tugas ini di awal proyek: Anda menemukannya pada tahap pengembangan selanjutnya ketika aplikasi sedang dipoles dan disempurnakan. Di sini, mungkin tepat untuk berkonsultasi dengan rekan kerja tentang apa yang akan mereka lakukan dan kesulitan apa yang mereka lihat. Pada intinya, tugas semacam itu mirip dengan mengembangkan fungsionalitas baru. Misalnya, Anda menerima tugas untuk mengedit beberapa fungsionalitas tanpa mengubah perilakunya. Untuk melakukan ini, Anda menghapus kode lama, menulis sendiri, dan memeriksa tes. Jika Anda melakukan semuanya dengan benar, maka tanpa membuat perubahan apa pun pada tes, semuanya harus lulus seperti sebelumnya. Setelah semua yang ada di kode sudah sebagaimana mestinya, kami mengirimkannya untuk ditinjau, dan minum kopi :)

8. Menulis dokumentasi

Bayangkan Anda adalah pengembang baru di beberapa proyek pengembangan perangkat lunak jangka panjang. Anda perlu membiasakan diri dengan basis kode atau melakukan beberapa tugas tertentu, misalnya, mendiagnosis bug. Bagaimana Anda akan menavigasi proyek? Mengganggu rekan tim Anda setiap lima menit? Dan bagaimana jika mereka sibuk atau akhir pekan, lalu bagaimana? Inilah mengapa kami memiliki dokumentasi — sehingga orang yang tidak terbiasa dengan kode dapat masuk, menemukan halaman yang relevan, dan dengan cepat mengetahui apa yang terjadi di bagian aplikasi yang menarik minatnya. Tapi harus ada yang bikin dokumentasinya, haha. Jika sebuah proyek memiliki dokumentasi yang harus didukung oleh pengembang, maka ketika mereka mengimplementasikan fungsionalitas baru, mereka menjelaskannya dan memperbarui dokumentasi bersama dengan perubahan atau pemfaktoran ulang kode apa pun. Anda juga dapat mengalami situasi di mana karyawan terpisah — seorang penulis teknis — dipekerjakan untuk menulis, memelihara, dan mengawasi dokumentasi. Jika spesialis seperti itu tersedia, kehidupan pengembang biasa akan sedikit lebih mudah.

9. Berbagai pertemuan

Banyak waktu pengembang dihabiskan dalam berbagai pertemuan, negosiasi, dan perencanaan. Contoh paling sederhana adalah daily stand-up meeting, di mana Anda perlu melaporkan apa yang Anda lakukan kemarin dan apa yang akan Anda lakukan hari ini. Selain itu, Anda perlu melakukan panggilan telepon pribadi, misalnya, dengan penguji, sehingga mereka dapat mendemonstrasikan/menjelaskan nuansa mereproduksi bug, atau mendiskusikan seluk-beluk dan persyaratan dengan analis bisnis atau membicarakan masalah organisasi dengan PM. Ini berarti bahwa meskipun seorang pengembang mungkin seorang introvert yang lebih suka menyendiri, dia tetap harus dapat menemukan kesamaan dengan orang lain (yah, setidaknya sedikit). Semakin tinggi peringkat pengembang, semakin banyak waktu yang dia perlukan untuk komunikasi dan semakin sedikit waktu untuk menulis kode. Seorang dev lead dapat menghabiskan setengah, atau bahkan lebih, dari hari kerjanya untuk percakapan dan rapat sendirian dan mungkin lebih jarang menulis kode (mungkin menyebabkan dia kehilangan sedikit kecakapan pengkodeannya). Tetapi jika Anda suka berbicara, sebagai pemimpin tim, Anda dapat beralih ke manajemen dan benar-benar melupakan menulis kode, sebagai gantinya, Anda akan menghabiskan sepanjang hari berkomunikasi dengan berbagai tim, pelanggan, dan manajer lainnya.

10. Melakukan/lulus wawancara

Jika Anda bekerja untuk outsourcing atau outsourcing perusahaan, Anda akan sering harus melalui wawancara eksternal, di mana Anda harus "menjual" diri Anda kepada klien (Anda mungkin diwawancarai oleh seseorang yang bekerja untuk klien), serta internal orang untuk naik pangkat dalam perusahaan. Saya akan menyebut ini sebagai kesempatan yang baik untuk berkembang karena wawancara yang sering akan memaksa Anda untuk menjaga pengetahuan Anda tetap tajam: Anda tidak akan menjadi berkarat dan lembek. Lagi pula, jika Anda menjadi lunak di bidang TI, Anda bisa benar-benar keluar dari lapangan. Saat Anda menjadi pengembang yang lebih berpengalaman, Anda akan dapat menemukan diri Anda berada di sisi lain meja, melakukan wawancara daripada melewatinya. Percayalah, Anda akan sangat terkejut jika melihatnya dari posisi ini, karena mengajukan pertanyaan wawancara bisa lebih menakutkan daripada menjawabnya. Anda harus memiliki strategi wawancara sendiri, daftar pertanyaan, dan waktu untuk mengajukan pertanyaan tentang semua topik yang diperlukan dalam satu jam. Dan setelah itu, Anda bertanggung jawab untuk memberikan umpan balik yang akan memengaruhi keputusan perekrutan dan apakah kandidat menerima tawaran atau promosi yang telah lama dinantikan. Atau, Anda mungkin mengizinkan kandidat yang jelas-jelas lemah untuk mendapatkan posisi yang tidak memenuhi syarat untuknya, dan kemudian Anda mungkin ditanya, "bagaimana Anda bisa mengizinkannya dipekerjakan dengan tingkat pengetahuan seperti itu"? Jadi, saat Anda berada di kursi panas saat wawancara, ingatlah bahwa orang di depan Anda juga sedang menghadapi tantangan dan mungkin sedang stres. Anda bertanggung jawab untuk memberikan umpan balik yang akan memengaruhi keputusan perekrutan dan apakah kandidat menerima tawaran atau promosi yang telah lama dinantikan. Atau, Anda mungkin mengizinkan kandidat yang jelas-jelas lemah untuk mendapatkan posisi yang tidak memenuhi syarat untuknya, dan kemudian Anda mungkin ditanya, "bagaimana Anda bisa mengizinkan dia dipekerjakan dengan tingkat pengetahuan seperti itu"? Jadi, saat Anda berada di kursi panas saat wawancara, ingatlah bahwa orang di depan Anda juga sedang menghadapi tantangan dan mungkin sedang stres. Anda bertanggung jawab untuk memberikan umpan balik yang akan memengaruhi keputusan perekrutan dan apakah kandidat menerima tawaran atau promosi yang telah lama dinantikan. Atau, Anda mungkin mengizinkan kandidat yang jelas-jelas lemah untuk mendapatkan posisi yang tidak memenuhi syarat untuknya, dan kemudian Anda mungkin ditanya, "bagaimana Anda bisa mengizinkannya dipekerjakan dengan tingkat pengetahuan seperti itu"? Jadi, saat Anda berada di kursi panas saat wawancara, ingatlah bahwa orang di depan Anda juga sedang menghadapi tantangan dan mungkin sedang stres. Setiap wawancara membuat stres bagi kandidat dan pewawancara. Kita mungkin akan berakhir di sini. Terima kasih kepada semua orang yang membaca artikel ini. Tinggalkan like dan terus belajar Java :)