Tugas biasa pembangun Java pada projek

Apakah tanggungjawab biasa pembangun Java? Lagipun, anda perlu memahami apa yang anda akan lakukan dan apa, pada akhirnya, anda akan lakukan, bukan? Hari ini saya ingin bercakap tentang sepuluh tugas utama yang dilakukan oleh pembangun Java. Tetapi pertama, mari kita berkenalan dengan alat seperti Jira. Atau mari segarkan ingatan kami jika ia sudah biasa kepada anda. Jira ialah alat interaksi pengguna, walaupun dalam beberapa kes ia juga digunakan untuk pengurusan projek. Dengan kata lain, pembangunan projek dipecahkan kepada tugas-tugas kecil yang diterangkan dalam alat ini. Tugas-tugas ini diberikan (ditugaskan) kepada pembangun, yang akan bertanggungjawab untuk pelaksanaannya. Dengan tugas yang kami maksudkan, sebagai contoh, menambah beberapa fungsi. Semasa kemajuan berkembang, pembangun dan pakar lain menambahkan ulasan tentang siapa yang melakukan perkara dan berapa banyak masa yang mereka luangkan—mereka menjejaki masa. Ini dilakukan untuk menjejaki masa yang dibelanjakan: berapa banyak yang dibelanjakan dan untuk apa. Sebaik-baiknya, ini dilakukan sekali sehari: pada waktu petang sebelum bertolak, anda menjejaki 8 jam anda ke tugasan yang anda habiskan. Fungsi Jira adalah lebih luas daripada yang diterangkan di atas, tetapi ini sudah cukup untuk pemahaman awal. Jadi, apakah tanggungjawab pembangun Java?

1. Pembangunan penyelesaian baharu

Sebelum anda mencipta dan melaksanakan sesuatu, anda perlu memikirkannya, bukan? Seperti yang saya katakan, ini mungkin semudah tugas Jira yang akan diberikan kepada anda, dan anda akan berusaha untuk membangunkan penyelesaian baharu, dengan menyatakan dalam Jira berapa banyak masa yang anda luangkan dan untuk apa. Ini juga boleh menjadi perbincangan mengenai panggilan kumpulan kumpulan: semua orang akan dapat menyatakan pendapat mereka dan mencadangkan pendekatan yang mereka anggap terbaik. Dan di sini saya ingin ambil perhatian beberapa perkara. Pertama, profesion pembangun adalah bidang yang sangat kreatif, kerana anda perlu menghasilkan cara unik untuk menyelesaikan masalah menggunakan alat standard. Selalunya, satu masalah boleh mempunyai banyak penyelesaian yang berbeza: oleh itu, semuanya bergantung pada "semangat kreatif" pembangun, pangkalan pengetahuan dan pengalaman terkumpul. Di sini anda boleh menunjukkan semua kreativiti dan genius anda, tetapi perkara utama adalah tidak keterlaluan: dalam kes ini, kod akan menjadi terlalu rumit dan tidak boleh dibaca dan akibatnya, selepas anda pergi, tiada siapa yang akan memahami sepenuhnya apa itu dan bagaimana ia berfungsi. Dan anda perlu menulis semula segala-galanya dari awal. Dan mereka mungkin mengingati anda. Dan lebih daripada sekali. Dan ini tidak mungkin menjadi kata-kata yang hangat dan baik. Adakah anda memerlukannya? Kedua, pembangun mestilah fleksibel dalam erti kata bahawa anda tidak harus terperangkap dalam satu penyelesaian dan menjadi tertutup kepada orang lain. Seperti, anda perlu melakukan hanya dengan cara ini dan tidak ada yang lain. Ini boleh berlaku atas pelbagai sebab: sebagai contoh, anda ingin membuktikan pandangan anda, atau anda telah membangunkan dan melaksanakan penyelesaian anda, yang anda cukup terikat dan, sudah tentu, tidak mahu mengakui bahawa ia bukan terbaik. Ini boleh membutakan mata anda. Malah, anda perlu boleh mengakui kesilapan anda dan sentiasa terbuka kepada perkara baharu (“berfikiran terbuka”), walaupun anda perlu mengalih keluar fungsi yang anda tulis selama beberapa minggu dan yang anda amat banggakan. Saya masih ingat bagaimana suasana sepanjang hari dibuat oleh jejak masa seseorang di Jira dengan komen: "Saya memadamkan fungsi saya yang lahir mati. Saya menangis"

2. Menulis fungsi baharu

Ini adalah langkah logik berikutan yang sebelumnya - pelaksanaan fungsi baharu. Semua kerja pada projek itu dibahagikan kepada tugas dalam jira, yang diterima oleh pemaju semasa mereka bekerja. Terdapat pendekatan yang berbeza untuk isu ini - "metodologi", lebih lanjut tentang yang boleh anda baca dalam artikel ini di JavaRush . Sebagai peraturan, tugas mempunyai "Anggaran" - masa yang diramalkan untuk disiapkan. Ia ditetapkan sama ada oleh anda sendiri semasa anda menjalankan tugas itu, atau oleh ketua pasukan, atau semasa merancang pembangun bersama-sama menganggarkannya. Kali ini sangat jarang diteka dengan tepat, kerana banyak faktor berbeza mempengaruhi pembangunan. Sebagai contoh, adakah pengaturcara biasa atau tidak biasa dengan teknologi ini, apakah pengalaman umumnya, pelbagai perangkap yang mungkin sudah kelihatan semasa pembangunan, dsb. Oleh itu, jika anda tidak memenuhi tarikh akhir ini semasa membangunkan fungsi, tiada perkara buruk akan berlaku. Ini hanyalah anggaran umum. Tetapi sekali lagi, tidak semua projek mempunyai anggaran tugas dan, bagi saya, lebih mudah untuk hidup tanpanya, terutamanya apabila PM tidak menyebelahi anda beberapa kali sehari dengan soalan “Di manakah anggaran itu? ” Sehubungan itu, anda mengambil tugas, membangunkan fungsi yang diperlukan, memuat naiknya ke cawangan biasa dalam GIT , dan dalam jira menukar status tugas itu kepada "Sedia untuk semakan" , iaitu, bersedia untuk melihat (menyemak) dan berdoa agar ia tidak dikembalikan kepada anda dengan ulasan mengenai semakan.

3. Menulis ujian untuk kefungsian

Orang yang menyemak kod anda - penyemak - menyukai fungsi yang anda bangunkan, tetapi dia mempunyai soalan: di manakah ujian untuknya? Dan dia mengembalikan tugas itu kepada anda untuk semakan. Ujian adalah bahagian penting dalam mana-mana aplikasi Java. Dengan menjalankannya, anda boleh segera menangkap tempat aplikasi berfungsi dengan tidak betul. Sebagai contoh, pembangun membuat beberapa perubahan dalam satu bahagian sistem, yang membawa kepada perubahan tingkah laku di bahagian lain, dan tidak menyedarinya semasa pembangunan. Dengan menjalankan ujian, dia akan dapat melihat ujian yang gagal (yang tidak berfungsi dengan betul). Ini akan memberitahunya bahawa ada sesuatu yang rosak di bahagian lain sistem. Oleh itu, dia tidak akan memuat naik perubahan pecah ke pelayan, tetapi akan terus memperhalusi penyelesaiannya. Ya, sudah tentu, beberapa pembangun menyukai ujian, tetapi tidak dapat dinafikan faedah yang mereka bawa kepada aplikasi. Selalunya pelanggan sendiri menentukan tahap liputan ujian yang harus dipatuhi (contohnya, 80%). Oleh itu, anda perlu mengetahui pelbagai jenis ujian dan boleh menulisnya. Pembangun Java terutamanya menulis ujian unit dan ujian integrasi, manakala AQA (penguji automasi) berurusan dengan ujian yang lebih meluas (hujung ke hujung). Anda boleh membaca lebih lanjut tentang mereka dan wakil profesion IT yang lain dalam ulasan saya .

4. Mencari dan membetulkan pepijat

Ini juga merupakan tugas yang sangat biasa dan kerap untuk pembangun Java. Tugas utama QA dan AQA adalah untuk menangkap pepijat. Iaitu, mereka mencari tempat di mana program itu berkelakuan tidak betul, mencipta isu dalam Jira dan menyalahkan seseorang. Sebagai contoh, ketua pasukan, yang seterusnya memutuskan pembangun mana untuk memberikan ini, bergantung pada beban dan kebiasaan mereka dengan bahagian sistem ini. Selepas ini, pembangun mencari pepijat, menghabiskan masa berjam-jam dalam penyahpepijat , menggunakan perihalan masalah oleh pakar QA untuk mengulangi situasi di mana pepijat itu berlaku. Seterusnya, pembangun menemui pepijat, membetulkannya dan menghantarnya untuk semakan. Nah, ada kemungkinan pembangun tidak dapat menghasilkan semula pepijat, dan dia mengembalikan tugas itu kepada pakar QA kembali dengan ulasan mengenainya. Nampaknya ia tidak akan mengambil masa yang lama untuk mencari dan membetulkan pepijat, tetapi terdapat beberapa nuansa. Segala-galanya bergantung terutamanya pada kebiasaan pembangun dengan bahagian kod ini, pengalaman dan pengetahuan tentang isu teori. Kadangkala pepijat boleh ditemui dan diperbaiki dalam masa 20 minit, dan kadangkala ia boleh mengambil masa tiga hari. Oleh itu, tugas jenis ini amat sukar untuk dinilai terlebih dahulu, melainkan pemaju, selepas membaca penerangan, segera memahami apa, di mana dan dengan apa yang berlaku. Dalam kes ini, dia akan dapat meneka masa dengan lebih kurang tepat.

5. Semakan kod

Seperti yang dinyatakan di atas, sebaik sahaja anda menyelesaikan tugasan, ia perlu dihantar untuk semakan, dan jika ia lulus, ia akan masuk ke urutan umum, jika tidak, ia akan dikembalikan kepada pembangun dengan ulasan tentang perkara yang perlu diperbetulkan. Adalah jelas bahawa semua ini tidak diperiksa oleh beberapa kuasa yang lebih tinggi, tetapi oleh pemaju lain. Tetapi tidak semua pembangun dibenarkan menjadi penyemak, tetapi hanya mereka yang paling berpengalaman, yang mempunyai amalan di belakang mereka dan boleh membezakan kod buruk daripada yang baik. Semakan kod biasanya dilakukan menggunakan alat bantu, contohnya, Crucible . Pengulas menyemak kod dan, jika perlu, tinggalkan komen di bawah beberapa baris. Komen juga boleh terdiri daripada pelbagai jenis. Contohnya, yang kritikal, tanpa pembetulan yang mana penyemak tidak akan lulus kod, dan yang lain lebih berkemungkinan hanya mengulas tentang pendekatan yang dipilih, yang boleh didengari, diambil perhatian atau diabaikan oleh pembangun. Pasukan boleh mencipta prosedur dan peraturannya sendiri untuk menjalankan semakan, bersetuju tentang perkara yang patut diberi perhatian dan apa yang tidak, dalam tempoh masa semakan kod harus dijalankan, dsb. Untuk menjalankan semakan, pengalaman sahaja tidak mencukupi: anda masih perlu membangunkan banyak ke arah teknikal, membaca pelbagai buku (contohnya, "Kod Bersih" ). Jika anda berminat dengan nuansa menjalankan semakan kod mengikut Google, saya menasihati anda untuk membaca artikel ini .

6. Analisis kod

Memandangkan projek itu ditulis secara serentak oleh beberapa orang yang berfikir secara berbeza, kod dan pendekatan mereka akan berbeza. Dan dari masa ke masa, semuanya akan beransur-ansur berubah menjadi bubur. Untuk menambah baik kod, kadangkala anda membuat tugasan untuk menganalisis, mungkin modul tertentu atau keseluruhan aplikasi, untuk mencari kelemahan dan membenderakannya, dan kemudian membuat tugas pemfaktoran semula berdasarkan ulasan ini. Analisis juga membantu dalam situasi di mana beberapa pintasan yang lebih mudah tidak kelihatan dari awal pembangunan, tetapi ia boleh dilihat sekarang. Sebagai contoh, logik yang sama sering diulang dalam beberapa kaedah dan, dengan itu, ia boleh dialihkan ke kaedah yang berasingan dan digunakan semula berkali-kali. Baiklah, sama ada sesetengah kelas telah menjadi sangat kembung, atau sesetengah kod menjadi sukar untuk dikekalkan atau ketinggalan zaman, atau... Tugasan analisis membantu meningkatkan kualiti kod dan aplikasi. Walaupun, pada pendapat saya, menganalisis sejumlah besar kod boleh menjadi tugas yang membosankan.

7. Pemfaktoran semula kod

Bahagian analisis seterusnya ialah pemfaktoran semula kod. Ia mungkin sudah lapuk, tidak diperlukan lagi, tulisan yang buruk, sukar dibaca, dan sebagainya. Anda harus sentiasa berusaha untuk kesempurnaan (walaupun ia tidak wujud) dan untuk kod terkini, mengalih keluar semua yang tidak perlu, kerana ini hanya mengelirukan dan menghalang anda daripada melihat intipati fungsi. Tidak perlu dikatakan bahawa anda tidak mungkin melihat tugasan ini pada permulaan projek: ia berlaku hanya pada peringkat pembangunan kemudian, apabila aplikasi digilap dan disempurnakan. Di sini, mungkin sesuai untuk berunding dengan rakan sekerja tentang cara mereka akan melakukannya dan apakah masalah yang mereka lihat. Intipati tugas sedemikian adalah serupa dengan pembangunan fungsi baru. Sebagai contoh, anda menerima tugas untuk mengedit beberapa fungsi tanpa mengubah tingkah lakunya. Untuk melakukan ini, anda memadam yang lama, menulis sendiri dan menyemak ujian. Jika anda melakukan segala-galanya dengan betul, tanpa membuat perubahan pada ujian yang sepatutnya berfungsi seperti sebelum ini. Selepas semuanya diselesaikan dalam kod, kami menghantarnya untuk menyemak dan pergi minum kopi))

8. Menulis dokumentasi

Bayangkan anda adalah pembangun baharu pada beberapa projek yang telah lama dibangunkan. Anda perlu membiasakan diri dengannya atau melakukan beberapa tugas tertentu, contohnya, menangkap pepijat. Bagaimanakah anda akan menavigasi projek? Tarik ahli pasukan anda setiap lima minit? Dan jika mereka sibuk atau pada hujung minggu, bagaimana? Inilah sebabnya mengapa dokumentasi wujud, supaya seseorang yang tidak biasa dengan fungsi itu boleh masuk, mencari halaman yang betul dan memahami dengan cepat perkara yang dilakukan oleh bahagian aplikasi yang menarik minatnya. Tetapi seseorang juga mesti mengisi dokumentasi ^^ Jika projek itu mempunyai dokumentasi yang mesti disokong oleh pembangun, apabila melaksanakan fungsi baharu mereka menerangkannya, dan dengan pelbagai perubahan dan pemfaktoran semula mereka mengemas kini dokumentasi. Situasi juga mungkin berlaku apabila pakar yang berasingan, seorang penulis teknikal, diupah untuk menulis, menyokong dan mengawal dokumentasi. Sekiranya pakar sedemikian wujud, ia menjadikan kehidupan pemaju biasa sedikit lebih mudah.

9. Penyertaan dalam pelbagai perhimpunan

Pembangun menghabiskan banyak masa untuk pelbagai mesyuarat, rundingan dan perancangan. Contoh paling mudah ialah "mesyuarat harian" (mesyuarat harian), di mana anda perlu memberitahu perkara yang anda lakukan semalam dan perkara yang akan anda lakukan hari ini. Di samping itu, anda perlu mengadakan panggilan satu lawan satu, contohnya, dengan pakar QA, supaya dia boleh menunjukkan/menerangkan nuansa penghasilan semula pepijat, atau membincangkan nuansa dan keperluan dengan penganalisis perniagaan atau organisasi masalah dengan PM. Oleh itu, walaupun pembangun mungkin seorang introvert yang lebih suka menyendiri, dia mesti dapat mencari bahasa yang sama dengan orang lain (baik, sekurang-kurangnya sedikit). Lebih tinggi kedudukan pembangun, lebih banyak masa yang dia perlukan untuk berkomunikasi dan kurang masa menulis kod. Ketua pasukan pembangun boleh menghabiskan separuh, atau lebih, masa kerjanya untuk perbualan dan mesyuarat serta menulis kod dengan lebih jarang (ini boleh menyebabkan kehilangan sedikit cengkaman). Tetapi jika anda juga seorang yang suka bercakap, anda boleh berkembang dengan mudah daripada kedudukan ketua pasukan ke bahagian pengurusan dan melupakan sepenuhnya kod, berkomunikasi sepanjang hari dengan pelbagai pasukan, pelanggan dan pengurus lain.

10. Mengendalikan/lulus temu duga

Jika anda bekerja untuk syarikat penyumberan luar atau pekerja luar, anda perlu menjalani temu duga luaran yang kerap, apabila anda perlu "dijual" kepada pelanggan (kemudian anda boleh ditemuduga oleh seseorang dari pihak pelanggan), dan temu duga dalaman, untuk meningkatkan pangkat anda dalam syarikat. Saya akan memanggil ini sebagai faktor yang baik untuk pembangunan, kerana disebabkan temu bual yang kerap, pengetahuan anda harus sentiasa dalam bentuk: anda tidak akan berkarat dan berehat, kerana jika anda berehat dalam IT, anda boleh terbang keluar dari lapangan sepenuhnya. Apabila anda menjadi pembangun yang lebih berpengalaman, anda akan dapat melawat sisi lain: tidak lulus, tetapi menjalankan temu duga. Percayalah, anda akan sangat terkejut jika anda melihatnya dari perspektif ini, kerana menjalankan temu duga boleh menjadi lebih menakutkan daripada lulus. Anda perlu mempunyai strategi wawancara anda sendiri, senarai soalan, dan mempunyai masa untuk bertanya soalan mengenai semua topik yang diperlukan dalam masa sejam. Dan selepas itu, anda bertanggungjawab untuk maklum balas, kerana bergantung padanya, seseorang mungkin atau mungkin tidak menerima tawaran atau promosi yang telah lama ditunggu-tunggu. Nah, dan sebaliknya: anda boleh terlepas calon yang terus terang lemah untuk jawatan yang dia tidak sesuai, dan kemudian anda mungkin ditanya: bagaimana anda merinduinya dengan tahap pengetahuan sedemikian? Oleh itu, apabila melalui temuduga, perlu diingat bahawa orang yang bertentangan dengan anda juga mengalami kesukaran, dan dia juga mungkin mengalami tekanan. Sebarang temu duga memberi tekanan kepada calon dan penemu duga. Mungkin kita akan berakhir di sini. Terima kasih kepada semua yang selesai membaca: suka dan belajar Java ^^