Tugas biasa pembangun Java pada projek

Apakah tanggungjawab biasa pembangun Java? Lagipun, anda perlu memahami apa yang anda hadapi dan apa yang akan anda lakukan, bukan? Hari ini saya ingin bercakap tentang sepuluh tugas penting yang dilakukan oleh pembangun Java. Tetapi pertama, mari kita berkenalan dengan alat yang dipanggil Jira. Atau segarkan ingatan anda tentangnya, jika anda sudah biasa dengannya. Jiraialah alat untuk mengatur interaksi manusia, walaupun dalam beberapa kes ia juga digunakan untuk pengurusan projek. Dalam erti kata lain, projek dipecahkan kepada tugas-tugas kecil yang diterangkan dalam alat ini. Tugas-tugas ini diberikan kepada pembangun, yang bertanggungjawab untuk pelaksanaannya. Tugas boleh, sebagai contoh, menambah beberapa fungsi. Semasa tugasan dijalankan, pembangun dan pakar lain menambah ulasan tentang siapa yang melakukan apa dan berapa banyak masa yang mereka luangkan. Ini dilakukan untuk tujuan penjejakan masa — untuk mengetahui berapa banyak masa yang dibelanjakan untuk tugasan apa. Sebaik-baiknya, ini dilakukan sekali sehari: Sebelum anda meninggalkan meja anda pada waktu petang, anda menyatakan berapa banyak daripada 8 jam kerja anda yang anda habiskan untuk pelbagai tugas. Terdapat banyak lagi fungsi Jira daripada yang diterangkan di atas, tetapi ini sudah cukup untuk pemahaman awal.

1. Mereka bentuk penyelesaian baharu

Sebelum anda mencipta dan melaksanakan sesuatu, anda perlu mengkonseptualisasikannya, bukan? Seperti yang saya katakan sebelum ini, ini hanya boleh menjadi tugas dalam Jira yang diberikan kepada anda, jadi anda berusaha untuk mereka bentuk penyelesaian baharu, merekodkan dalam Jira berapa banyak masa yang anda luangkan dan untuk apa. Kerja ini juga boleh berlaku semasa perbincangan mengenai panggilan persidangan pasukan: semua orang boleh menyatakan pendapat mereka dan mencadangkan pendekatan yang mereka anggap terbaik. Dan di sini saya ingin ambil perhatian beberapa perkara. Pertama, pembangunan perisian adalah profesion yang sangat kreatif, kerana anda perlu menggunakan alat standard untuk menghasilkan cara baru untuk menyelesaikan masalah. Satu tugas selalunya boleh mempunyai banyak penyelesaian yang berbeza. Sehubungan itu, segala-galanya bergantung kepada kreativiti pembangun, yang banyak dipengaruhi oleh pengetahuan dan pengalaman terkumpul mereka. Anda boleh mempamerkan semua kreativiti dan genius anda di sini, tapi yang penting jangan berlebihan. Jika anda berbuat demikian, kod akan menjadi terlalu rumit dan tidak boleh dibaca. Akibatnya, selepas anda keluar, tiada siapa yang akan memahami sepenuhnya perkara yang anda kodkan dan cara ia berfungsi. Dan mereka perlu menulis semula segala-galanya dari awal. Dan mereka mungkin mengenangkan anda. Lebih dari sekali. Dan tidak mungkin akan ada kata-kata hangat dan baik yang diucapkan. Adakah anda memerlukan itu? Kedua, pembangun mesti mengekalkan fleksibiliti psikologi dalam erti kata bahawa anda tidak harus berpaut kepada penyelesaian tunggal dan menjadi tertutup kepada orang lain. Seolah-olah anda perlu melakukan sesuatu hanya dengan satu cara dan tidak ada pilihan lain. Anda mungkin jatuh ke dalam perangkap ini atas pelbagai sebab. Sebagai contoh, katakan anda ingin membuktikan bahawa pandangan anda betul. Atau mungkin anda telah mereka dan melaksanakan penyelesaian biasa anda sendiri — sudah tentu, anda tidak mahu mengakui bahawa ia bukan yang terbaik. Situasi ini boleh membuat anda agak buta. Malah, anda perlu boleh mengakui kesilapan anda dan sentiasa berfikiran terbuka, walaupun anda perlu mengalih keluar fungsi yang anda banggakan dan telah mengekod selama lebih dari seminggu. Saya masih ingat bagaimana rakan sekerja menceriakan hari semua orang sekali dengan meninggalkan komen penjejakan masa ini di Jira: "Saya mengeluarkan ciri lahir mati saya. Dan berkabung."

2. Menulis fungsi baharu

Langkah ini — melaksanakan fungsi baharu — mengikut logik selepas yang sebelumnya. Semua kerja yang terlibat dalam projek dibahagikan kepada tugas di Jira, yang kemudiannya diserahkan kepada pembangun berdasarkan beban kerja mereka. Terdapat pendekatan yang berbeza untuk proses ini, yang dikenali sebagai "metodologi," yang boleh anda baca dengan lebih terperinci dalam artikel ini tentang CodeGym . Sebagai peraturan, tugas mempunyai anggaran, iaitu masa ramalan yang diperlukan untuk menyelesaikannya. Ia ditetapkan sama ada oleh anda, pembangun apabila anda menerima tugas, atau oleh ketua pasukan, atau semasa perancangan, secara kolektif oleh pasukan pembangunan. Tekaan kali ini sangat jarang tepat, kerana begitu banyak faktor berbeza mempengaruhi pembangunan perisian. Sebagai contoh, sama ada pengaturcara biasa atau tidak biasa dengan teknologi yang berkaitan, pengalaman keseluruhannya, pelbagai perangkap yang tidak diduga, dsb. Jadi, jika anda tidak mencapai semua anggaran masa anda semasa pengekodan, ia bukan penghujung dunia. Ini hanyalah anggaran umum. Yang berkata, tidak semua projek memerlukan anggaran masa. Secara peribadi, saya mendapati lebih mudah untuk hidup tanpanya, terutamanya apabila PM tidak mengganggu saya beberapa kali sehari dengan soalan "di manakah anggaran masa anda?" Jadi, anda mendapat tugas,Sedia untuk semakan " di Jira dan berdoa agar perubahan kod anda tidak dikembalikan untuk semakan bersama dengan ulasan.

3. Ujian bertulis

Penyemak, iaitu orang yang menyemak kod anda, menyukai fungsi yang anda laksanakan, tetapi dia mempunyai soalan untuk anda: di manakah ujian yang berkaitan? Jadi dia menghantar semula tugas itu kepada anda untuk semakan. Ujian adalah bahagian penting dalam mana-mana aplikasi Java. Dengan menjalankan ujian, anda boleh mengenal pasti tempat di mana aplikasi tidak berfungsi dengan betul. Sebagai contoh, pembangun membuat beberapa perubahan dalam satu bahagian sistem, yang mengakibatkan perubahan dalam tingkah laku di bahagian lain, tetapi dia tidak menyedarinya semasa mengekod. Dengan menjalankan ujian, dia akan dapat melihat bahawa ujian tertentu gagal, bermakna mereka tidak menghasilkan keputusan yang diharapkan. Ini memberitahunya bahawa ada sesuatu yang rosak di tempat lain dalam sistem. Mengetahui perkara ini, dia tidak akan melakukan perubahan terputus kepada pelayan, dan sebaliknya akan terus bekerja pada penyahpepijatan kodnya. ya, agak sedikit pembangun menyukai ujian menulis, tetapi tidak dapat dinafikan faedah yang mereka bawa kepada pembangunan perisian. Pelanggan sendiri sering menunjukkan tahap liputan ujian yang mereka mahu kekalkan (contohnya, 80%). Itu bermakna anda perlu tahupelbagai jenis ujian dan boleh menulisnya. Pembangun Java terutamanya menulis ujian unit dan ujian integrasi, manakala ujian yang lebih luas (hujung ke hujung) dikendalikan oleh pakar QA dan ujian automasi.

4. Mencari dan membetulkan pepijat

Ini juga merupakan tugas yang sangat biasa dan kerap untuk pembangun Java. Tugas utama pakar QA dan automasi ujian adalah untuk menangkap pepijat. Dalam erti kata lain, mereka mencari tempat di mana program berkelakuan tidak betul, kemudian mereka membuat tugasan dalam Jira dan menyerahkannya kepada seseorang. Sebagai contoh, kepada ketua pasukan, yang, seterusnya, memutuskan pembangun mana untuk menugaskan mereka, bergantung pada beban kerja dan kebiasaan mereka dengan bahagian sistem yang berkaitan. Selepas itu, pembangun yang ditugaskan memburu punca pepijat, menghabiskan berjam-jam dalam penyahpepijat, menggunakan penerangan pepijat yang disediakan oleh pakar QA untuk menghasilkan semula keadaan di mana pepijat berlaku. Sebaik sahaja pembangun menemui pepijat dan membetulkannya, dia menghantar pembetulan untuk semakan. Kadangkala pembangun tidak dapat menghasilkan semula pepijat, jadi dia menghantar semula tugas itu kepada pakar QA bersama-sama dengan ulasan penjelasan. Nampaknya ia tidak sepatutnya mengambil masa yang lama untuk mencari dan membetulkan pepijat, tetapi terdapat beberapa nuansa. Semuanya bergantung terutamanya pada tahap pengetahuan pembangun dengan bahagian kod ini, dan pada pengalaman dan pengetahuan teorinya. Kadangkala pepijat boleh ditemui dan diperbaiki dalam masa 20 minit, dan kadangkala ia boleh mengambil masa tiga hari. Ini bermakna bahawa jenis tugasan ini amat sukar untuk dianggarkan lebih awal, melainkan pembangun, apabila membaca huraian, segera memahami apa, di mana dan bagaimana pepijat itu. Dalam kes ini,

5. Semakan kod

Seperti yang dinyatakan di atas, sebaik sahaja anda menyelesaikan tugasan, tugasan itu hendaklah dihantar untuk semakan. Jika ia lulus semakan, maka ia akan masuk ke cawangan utama. Jika tidak, ia dikembalikan kepada pembangun dengan komen yang perlu ditangani. Sudah tentu, anda faham bahawa kod anda semuanya disemak oleh rakan pembangun, bukan oleh kuasa tinggi. Walau bagaimanapun, tidak semua orang dibenarkan melakukan semakan kod — hanya pembangun yang paling berpengalaman yang dikeraskan oleh amalan dunia sebenar, yang boleh membezakan antara kod yang baik dan kod buruk. Semakan kod biasanya dilakukan menggunakan alat pembantu seperti Crucible. Pengulas meneliti kod dan, jika perlu, tinggalkan komen tentang baris tertentu. Boleh jadi macam-macam komen. Sebagai contoh, ada yang kritikal. Jika ia tidak ditangani, maka penyemak tidak akan membenarkan kod itu dilakukan. Komen lain adalah, katakan, hanya ulasan tentang pendekatan yang dipilih. Pembangun ini boleh mendengar, mengambil perhatian atau mengabaikannya. Pasukan boleh mencipta peraturan dan prosedurnya sendiri untuk semakan kod, bersetuju tentang perkara yang patut diberi perhatian dan apa yang tidak, tempoh masa yang perlu diperuntukkan untuk melengkapkan semakan kod, dll. Pengalaman sahaja tidak mencukupi untuk menjalankan semakan: anda masih perlu berkembang banyak dalam kemahiran teknikal anda dan membaca pelbagai buku (contohnya, "Kod Bersih").

6. Analisis kod

Memandangkan beberapa orang yang berfikir secara berbeza menulis kod untuk projek secara serentak, kod dan pendekatan mereka akan berbeza. Dan dari masa ke masa, semuanya beransur-ansur berubah menjadi kucar-kacir. Untuk menambah baik kod, kadangkala tugas dibuat untuk, katakan, menganalisis modul tertentu atau keseluruhan aplikasi, mencari dan mengambil maklum kekurangan, dan kemudian membuat tugas pemfaktoran semula berdasarkan analisis ini. Analisis sedemikian juga membantu dalam situasi di mana, apabila pembangunan bermula, pasukan tidak dapat melihat beberapa penyelesaian yang lebih mudah dan ringkas, tetapi mereka melihatnya sekarang. Sebagai contoh, logik sering diduplikasi dalam beberapa kaedah. Sehubungan itu, ia boleh diekstrak ke dalam kaedah yang berasingan, yang kemudiannya boleh digunakan semula berkali-kali. Atau mungkin kelas telah berkembang terlalu banyak, atau beberapa kod menjadi sukar untuk dikekalkan atau ketinggalan zaman, atau... Tugas analisis membantu meningkatkan kualiti kod dan aplikasi. Yang berkata, bagi saya, menganalisis sejumlah besar kod boleh membosankan.

7. Kod pemfaktoran semula

Bahagian seterusnya analisis kod ialah pemfaktoran semula. Kod boleh lapuk, usang, ditulis dengan buruk, sukar dibaca dan sebagainya. Anda harus sentiasa berusaha untuk kesempurnaan (walaupun ia tidak wujud) dan untuk kod terkini, mengalih keluar apa-apa yang berlebihan, kerana yang berlebihan hanya membawa kepada kekeliruan dan mengganggu keupayaan untuk melihat apa yang dilakukan oleh kod tersebut. Tidak perlu dikatakan bahawa anda tidak mungkin melihat tugasan ini pada permulaan projek: anda menemuinya pada peringkat pembangunan kemudian apabila aplikasi sedang digilap dan disempurnakan. Di sini, mungkin sesuai untuk berunding dengan rakan sekerja tentang perkara yang akan mereka lakukan dan masalah yang mereka lihat. Di hati mereka, tugas sedemikian serupa dengan membangunkan fungsi baharu. Sebagai contoh, katakan anda menerima tugas untuk mengedit beberapa fungsi tanpa mengubah tingkah lakunya. Untuk melakukan ini, anda memadamkan kod lama, menulis sendiri dan menyemak ujian. Jika anda melakukan segala-galanya dengan betul, maka tanpa membuat sebarang perubahan pada ujian, mereka semua harus lulus seperti sebelumnya. Selepas segala-galanya dalam kod adalah seperti yang sepatutnya, kami menghantarnya untuk semakan, dan minum kopi :)

8. Menulis dokumentasi

Bayangkan anda adalah pembangun baharu dalam beberapa projek pembangunan perisian jangka panjang. Anda perlu membiasakan diri dengan asas kod atau melaksanakan beberapa tugas tertentu, contohnya, mendiagnosis pepijat. Bagaimanakah anda akan menavigasi projek? Mengganggu rakan sepasukan anda setiap lima minit? Dan bagaimana jika mereka sibuk atau hujung minggu, bagaimana? Inilah sebabnya mengapa kami mempunyai dokumentasi — supaya orang yang tidak biasa dengan kod itu boleh masuk, mencari halaman yang berkaitan dan mengetahui dengan cepat perkara yang berlaku di bahagian aplikasi yang menarik minatnya. Tapi mesti ada yang buat dokumentasi, haha. Jika projek mempunyai dokumentasi yang mesti disokong oleh pembangun, maka apabila mereka melaksanakan fungsi baharu, mereka menerangkannya dan mengemas kini dokumentasi bersama-sama dengan sebarang perubahan kod atau pemfaktoran semula. Anda juga boleh mengalami situasi di mana pekerja berasingan — penulis teknikal — diupah untuk menulis, menyelenggara dan menyelia dokumentasi. Sekiranya pakar sedemikian tersedia, kehidupan pemaju biasa sedikit lebih mudah.

9. Pelbagai mesyuarat

Banyak masa pembangun dihabiskan dalam pelbagai mesyuarat, rundingan dan perancangan. Contoh paling mudah ialah mesyuarat pendirian harian, di mana anda perlu melaporkan perkara yang anda lakukan semalam dan perkara yang akan anda lakukan hari ini. Di samping itu, anda perlu mengadakan panggilan telefon satu-satu, contohnya, dengan penguji, supaya mereka boleh menunjukkan/menjelaskan nuansa penghasilan semula pepijat, atau membincangkan kehalusan dan keperluan dengan penganalisis perniagaan atau bercakap tentang isu organisasi dengan PM. Ini bermakna walaupun pembangun mungkin seorang introvert yang lebih suka menyendiri, dia masih perlu mencari titik persamaan dengan orang lain (baik, sekurang-kurangnya sedikit). Semakin tinggi kedudukan pembangun, semakin banyak masa yang dia perlukan untuk komunikasi dan semakin sedikit masa menulis kod. Pemimpin pembangun boleh menghabiskan separuh, atau lebih, hari kerjanya untuk perbualan dan mesyuarat sahaja dan mungkin menulis kod kurang kerap (mungkin menyebabkan dia kehilangan sedikit kehebatan pengekodannya). Tetapi jika anda hanya suka bercakap, anda boleh, sebagai ketua pasukan, beralih kepada pengurusan dan melupakan sepenuhnya tentang menulis kod, sebaliknya, anda akan menghabiskan sepanjang hari berkomunikasi dengan pelbagai pasukan, pelanggan dan pengurus lain.

10. Mengendalikan/lulus temu duga

Jika anda bekerja untuk syarikat penyumberan luar atau pekerja luar, anda selalunya perlu melalui temu duga luar, di mana anda perlu "menjual" diri anda kepada pelanggan (anda mungkin ditemuramah oleh seseorang yang bekerja untuk pelanggan), serta dalaman mereka untuk naik pangkat dalam syarikat. Saya akan memanggil ini peluang yang baik untuk pertumbuhan kerana temu bual yang kerap akan memaksa anda untuk memastikan pengetahuan anda tajam: anda tidak akan berkarat dan lembut. Lagipun, jika anda menjadi lembut dalam IT, anda boleh jatuh sepenuhnya dari lapangan. Apabila anda menjadi pembangun yang lebih berpengalaman, anda akan dapat mendapati diri anda berada di sisi lain meja, menjalankan temu duga dan bukannya melepasinya. Percayalah, anda akan sangat terkejut apabila anda melihatnya dari kedudukan ini, kerana bertanya soalan temuduga boleh menjadi lebih menakutkan daripada menjawabnya. Anda perlu mempunyai strategi wawancara anda sendiri, senarai soalan, dan masa untuk bertanya soalan mengenai semua topik yang diperlukan dalam satu jam. Dan selepas itu, anda bertanggungjawab untuk memberikan maklum balas yang akan mempengaruhi keputusan pengambilan pekerja dan sama ada calon menerima tawaran atau kenaikan pangkat yang sudah lama dijangkakan. Atau, anda mungkin membenarkan calon yang jelas lemah untuk mendapatkan jawatan yang dia tidak layak, dan kemudian anda mungkin ditanya, "bagaimana anda boleh membenarkan dia diambil bekerja dengan tahap pengetahuan itu"? Jadi, apabila anda berada di kerusi panas semasa temu duga, perlu diingat bahawa orang di hadapan anda juga menghadapi cabaran dan mungkin tertekan. anda bertanggungjawab untuk memberikan maklum balas yang akan mempengaruhi keputusan pengambilan pekerja dan sama ada calon menerima tawaran atau kenaikan pangkat yang telah lama dijangkakan. Atau, anda mungkin membenarkan calon yang jelas lemah untuk mendapatkan jawatan yang dia tidak layak, dan kemudian anda mungkin ditanya, "bagaimana anda boleh membenarkan dia diambil bekerja dengan tahap pengetahuan itu"? Jadi, apabila anda berada di kerusi panas semasa temu duga, perlu diingat bahawa orang di hadapan anda juga menghadapi cabaran dan mungkin tertekan. anda bertanggungjawab untuk memberikan maklum balas yang akan mempengaruhi keputusan pengambilan pekerja dan sama ada calon menerima tawaran atau kenaikan pangkat yang telah lama dijangkakan. Atau, anda mungkin membenarkan calon yang jelas lemah untuk mendapatkan jawatan yang dia tidak layak, dan kemudian anda mungkin ditanya, "bagaimana anda boleh membenarkan dia diambil bekerja dengan tahap pengetahuan itu"? Jadi, apabila anda berada di kerusi panas semasa temu duga, perlu diingat bahawa orang di hadapan anda juga menghadapi cabaran dan mungkin tertekan. Sebarang temu duga memberi tekanan kepada calon dan penemu duga. Kita mungkin akan berakhir di sini. Terima kasih kepada semua yang membaca artikel ini. Tinggalkan like dan teruskan belajar Java :)