Apa yang harus saya lakukan ketika menunggu ulasan?

Sebelum mengajukan pertanyaan, saya harus menjelaskan situasinya.

Saya bekerja untuk sebuah perusahaan sebagai insinyur perangkat lunak junior. Salah satu senior selalu menghentikan saya ketika saya telah menyelesaikan pengembangan dan ingin berkomitmen.

Dia selalu ingin saya menunggu dia memeriksanya. Ini ok, karena biasanya dia menemukan beberapa bug, dan melakukan beberapa optimasi.

Namun saya harus memasukkan kode saya sebelum batas waktu. Ketika saya selesai, saya memanggilnya dan mengatakan sudah selesai. Dia biasanya datang terlambat. Jadi kode saya terlambat juga.

Pertanyaan saya adalah, apa yang harus saya lakukan? Haruskah saya menunggu dia untuk diperiksa?

EDIT: Tambahan untuk pertanyaan. Saya ingin tahu tentang satu masalah lagi.

Saya ingin bebas ketika coding. Bagaimana saya bisa mendapatkan kepercayaan untuk kebebasan pembangunan?

_{Beberapa penjelasan: Saya sudah bicara dengannya tentang ini. Tapi itu tidak membantu. Kami sudah menggunakan pelacak masalah, tetapi tidak ada tugas untuk ulasan. Hanya ada tugas pengembangan dan tes.}

Jadi kode saya terlambat juga.

Tidak, itu bukan kode Anda , itu adalah kode Anda dan senior. Anda bekerja sebagai tim, Anda memiliki tanggung jawab bersama, dan ketika Anda berdua melewatkan tenggat waktu, itu adalah kesalahan Anda berdua. Jadi pastikan orang yang membuat tenggat waktu memperhatikan itu. Jika orang itu melihat itu sebagai masalah juga, dia pasti akan berbicara dengan Anda berdua bersama - yang dapat membantu lebih dari satu pembicaraan dengan rekan kerja Anda.

Dan untuk EDIT Anda:

Saya ingin bebas ketika coding. Bagaimana saya bisa mendapatkan kepercayaan untuk kebebasan pembangunan?

Meninjau kode adalah salah satu penghemat kualitas yang paling penting. Hampir tidak mungkin untuk menulis kode yang sangat baik tanpa sepasang mata kedua, bahkan ketika Anda memiliki pengalaman pemrograman> 20 tahun. Jadi dalam tim yang baik, kode setiap orang harus selalu ditinjau - kode senior Anda dan juga kode Anda. Ini tidak ada hubungannya dengan ketidakpercayaan terhadap Anda secara langsung (atau, setidaknya, seharusnya tidak). Selama Anda percaya bahwa "pengkodean gratis" tanpa sepasang mata lebih baik, Anda masih seorang programmer junior.

Dalam tim yang baik, Anda harus memiliki antrian tugas pengembangan yang ditugaskan kepada Anda dalam pelacak masalah .

Dengan begitu, saat Anda menunggu peninjau, Anda dapat ( harus ) bekerja pada tugas berikutnya menunggu dalam antrian itu. Setelah Anda terbiasa bekerja dengan cara itu, ini akan membuka peluang untuk meminta perubahan Anda ditinjau dalam "kumpulan", sehingga mengurangi penundaan.

• ^{Jika Anda tidak memiliki "antrian", diskusikan hal ini dengan manajer Anda, atau lebih baik lagi, dengan pengulas. Jika tim Anda tidak memiliki pelacak isu yang cukup mudah untuk hal-hal seperti itu, pertimbangkan mempelajari papan kerja atau peluang kerja internal perusahaan untuk menemukan tim yang lebih baik (Anda mungkin juga mendiskusikan hal ini dengan manajer / pengulas tetapi jangan berharap ini membantu - kurang dari pelacak masalah yang baik sering merupakan gejala dari sesuatu yang rusak parah dalam tim).}

Saya ingin bebas ketika coding. Bagaimana saya bisa mendapatkan kepercayaan untuk kebebasan pembangunan?

Untuk mengetahuinya, Anda harus terlebih dahulu memahami tujuan ulasan kode. Anda menyebutkan kepercayaan - itu "perkiraan" yang bagus, tetapi tidak sepenuhnya akurat.

• ^{Sebagai contoh, dalam salah satu proyek saya baru-baru ini, pengembangan telah dilakukan oleh tim mini saya dan rekan saya. Kami sepenuhnya saling percaya dan menghormati satu sama lain - tetapi meskipun demikian, kami meninjau 100% kode. Kami melakukannya karena ini memungkinkan kami untuk menemukan dan dengan cepat memperbaiki beberapa bug dan, yang juga sangat penting, karena ulasan tidak memakan banyak waktu dan tidak menghalangi pekerjaan kami.}

Anda lihat, akan lebih akurat untuk memikirkan review kode dalam hal upaya yang diinvestasikan untuk mencegah risiko tertentu . Dalam tim yang baik, Anda bisa mengharapkan semacam pemahaman bersama tentang bagaimana "menyeimbangkan" ini dengan benar. Perhatikan bahwa tidak ada keseimbangan yang tepat satu ukuran untuk semua, itu sangat tergantung pada proyek - risiko dan dampak bug dalam misi perangkat lunak kritis secara alami berbeda dari yang ada dalam aplikasi non-kritis.

Dengan menggunakan contoh Anda, Anda dapat mengharapkan "memblokir ulasan" selama upaya yang diinvestasikan oleh pengulas Anda dibenarkan dengan menemukan bug dan perbaikan yang lebih baik diperbaiki sebelum melakukan kode Anda.

Mereka kemungkinan berharap bahwa dengan latihan dan dengan panduan yang diterima di ulasan Anda akan lebih baik dalam pengkodean, sehingga mereka akan menemukan semakin sedikit masalah yang perlu diperbaiki sebelum melakukan. Segera setelah mereka menemukan bahwa kode Anda mendapat "cukup aman" untuk memungkinkan "langkah-langkah pencegahan risiko" yang kurang rumit, Anda dapat mengharapkan prosesnya berubah, misalnya untuk ditinjau setelah dilakukan .

Bergantung pada suatu proyek, pada titik tertentu kode Anda mungkin bahkan dianggap cukup aman untuk melewati ulasan sama sekali, meninggalkan penemuan bug pada penguji (tetapi itu belum tentu akan terjadi, lihat contoh saya di atas).

Ada beberapa kemungkinan jawaban di sini, tergantung pada masalah Anda sebenarnya.

• Jika masalah utama Anda adalah "Saya kehilangan tenggat waktu", tidak. Kalian berdua sama-sama kehilangan tenggat waktu. Bisakah Anda (dengan percaya diri) mengatakan "Saya akan selesai dalam satu jam, bisakah kita melakukan review kode itu"? Itu mungkin cukup. Bisakah Anda menyelesaikan kode sehari sebelum batas waktu? Itu harus menjadi penyangga yang berlimpah. Apakah Anda menyelesaikan kode Anda, dengan banyak penyangga antara "silakan tinjau" dan batas waktu? Jika yang terakhir, itu bahkan bukan kesalahan sendi, kataku.

• Kode harus selalu ditinjau. Saya tidak bisa mengecek apa pun tanpa (setidak-tidaknya) set mata kedua dan manusia lain "tidak apa-apa". Itu berlaku untuk proyek-proyek di mana saya adalah programmer utama dan juga untuk proyek-proyek di mana saya biasanya tidak berkontribusi (tetapi telah berhasil menemukan bug yang berdampak pada saya yang ingin saya perbaiki). Namun, ketatnya review sangat didasarkan pada kepercayaan. Jika saya percaya bahwa orang yang ingin mengirimkan kode mengetahui basis kode dengan baik, saya tidak akan seketat jika saya tidak tahu seberapa baik orang tersebut mengetahui basis kode.

Pertanyaan saya adalah, apa yang harus saya lakukan? Haruskah saya menunggu dia untuk diperiksa?

Tidak, Anda tidak hanya duduk diam. Selalu ada sesuatu untuk dilakukan.Seperti yang disarankan nyamuk , harus ada antrian tugas. Atau, dengan cara pengembangan yang gesit, daftar tugas yang diberikan kepada Anda untuk iterasi saat ini. Jika Anda duduk diam, ada sesuatu yang salah dalam organisasi perusahaan Anda atau tim Anda.

Hal lain adalah: apakah supervisor senior Anda benar-benar memeriksa setiap bagian kode yang Anda lakukan? Jika ya, Anda juga bisa melakukan pemrograman berpasangan.

Saya ingin bebas ketika coding. Bagaimana saya bisa mendapatkan kepercayaan untuk kebebasan pembangunan?

Ada beberapa peraturan yang mensyaratkan bahwa senior memeriksa pekerjaan junior (saya pikir iso medis 62304 mengharuskan ini). Jika sudah demikian, Anda tidak bisa melakukan apa-apa.

Yang dapat Anda ubah adalah meminta senior untuk tidak memeriksa semuanya secara harfiah. Anda dapat mengatur proses peninjauan kode, dan memeriksa hal-hal penting.

Gunakan git secara lokal, komit perubahan Anda ke cabang dan mulai tugas 2 sambil menunggu. Kemudian ketika dia selesai, Anda bisa menggabungkan perubahannya ke dalam pekerjaan baru Anda dan Anda sudah di depan kurva pada tugas berikutnya.

Lakukan ini cukup lama dan segera, dia dapat meninjau 2 atau lebih hal sekaligus. Pilih hal-hal yang tidak mungkin tumpang tindih untuk meminimalkan konflik.

Salah satu solusi untuk ini adalah melibatkan pengembang senior lebih awal dengan Pair Programming pada pekerjaan Anda.

Halaman Wikipedia tentang Pair Programming

Keuntungan yang paling jelas bagi Anda adalah bahwa ulasan tersebut terjadi jauh lebih awal dalam proses sehingga Anda tidak perlu lagi menunggu pengembang senior.

Selain itu, Anda akan dapat melihat proses pemikiran dan teknik pengembang senior saat ia menulis kode, dan belajar dari ini.

Anda mungkin memiliki masalah dengan pengembang senior yang mungkin tidak ingin berpasangan dengan Anda. Itu bisa sulit, tetapi pengalaman saya sendiri adalah bahwa pengembang senior dan junior mendapatkan banyak pengalaman dari pemrograman pasangan.

Sering juga ada kekhawatiran bahwa Anda akan setengah produktivitas dengan memiliki 2 pengembang bekerja pada pekerjaan yang sama. Sulit untuk mengukur apa pengaruhnya terhadap produktivitas dengan Pair Programming, respons paling umum yang saya dengar adalah bahwa produktivitas tim yang berpasangan dan yang tidak sama. (Jika ada yang tahu riset bagus tentang ini, saya akan senang mendengarnya)

Bukan jawaban lengkap sendiri, hanya tambahan untuk jawaban bagus di atas ...

Apakah Anda meninjau kode Anda sendiri sebelum memeriksanya? Saya tahu itu bukan yang paling menyenangkan, tetapi saya mencoba membuat diri saya paling sering melakukannya. Saya telah memprogram secara profesional selama 20 tahun (total 34 tahun), tetapi saya biasanya menemukan setidaknya satu bug dan / atau satu hal yang saya lupa, atau setidaknya bisa menjadi lebih baik. Saya setuju dengan sentimen bahwa kode Anda harus selalu ditinjau dan set mata kedua lebih baik dari satu pasangan. Tetapi bahkan pasangan yang sama membaca kode dua kali lebih baik dari sekali.

Apakah Anda menulis unit test untuk kode Anda? Selain tes unit, saya juga memiliki skrip shell kecil yang mencari kesalahan paling umum yang saya buat secara pribadi. Beberapa di antaranya adalah tata bahasa dan ejaan bahasa Inggris, beberapa adalah masalah pengkodean yang tidak ditangkap oleh kompiler. Saya menjalankannya sebelum memeriksa perubahan besar sebagai rasa hormat kepada semua orang di hilir.

Saya biasanya membiarkan orang menulis kode mereka dan kadang-kadang mengeluh tentang hal itu, tetapi saya tidak meninjau setiap check-in. Saya pernah bekerja dengan programmer yang sangat junior yang kodenya harus saya tinjau dan biasanya dibatalkan karena mereka membuat banyak kesalahan. Itu tidak berakhir dengan baik. Anda berada dalam profesi di mana seringkali lebih penting untuk menyelesaikannya dengan benar daripada melakukannya tepat waktu. Jika Anda belajar dari kesalahan Anda, Anda akan melangkah jauh.

Jika Anda dapat meminimalkan jumlah perubahan yang perlu dilakukan oleh pengulas Anda untuk kode Anda, Anda memaksimalkan peluang bahwa mereka akan mempercayai Anda untuk menulis kode yang tidak selalu perlu ditinjau dengan hati-hati. Jika Anda menginginkan kebebasan dari ulasan, ambil tanggung jawab maksimum untuk kualitas hasil Anda sendiri.

Beberapa atau semua saran ini dapat dilakukan sambil menunggu orang lain meninjau kode Anda.

Saya pikir melakukan tinjauan kode manual adalah ... baik ... agak 80-an. Yah, mungkin 90-an.

Di era modern integrasi berkelanjutan dan sistem peninjauan kode online ini, Anda benar-benar tidak ingin menahan komitmen kode apa pun hanya karena Anda takut bahwa "itu mungkin merusak kontrol sumber".

Ayo, semuanya. Itulah gunanya changeset (atau daftar perubahan). Anda membuat programmer Anda memberi makan lapar lapar dari sistem kontrol sumber Anda. Kemudian server integrasi berkesinambungan Anda menendang dengan litani build yang ditargetkan (well, semoga hanya build harian, tetapi beberapa dari kita terbawa suasana). Jika ada yang rusak, Anda meletakkan piala kode monyet (biasanya mainan plastik yang ditemukan seseorang dari kotak sereal Lucky Charms) di meja pelaku, dan memutar kembali daftar perubahan. Nah, beberapa sistem integrasi berkelanjutan secara otomatis mengeluarkan notifikasi email / IM / desktop untuk semua orang di tim / departemen / organisasi bahwa build rusak, bersama dengan hyperlink yang bagus untuk menunjukkan kepada semua orang yang benar-benar memecahkan build di mana file atau tes. Sekarang programmer yang malang '

Saat proses ini berjalan, sistem peninjauan kode akan masuk (sekali lagi, dipicu oleh check-in). Daftar anggota tim yang memenuhi syarat diberitahu tentang daftar perubahan yang berkomitmen untuk kontrol sumber, peninjauan dimulai dalam sistem peninjauan, dan semua orang mulai membuat anotasi terhadap perubahan dalam daftar perubahan. Semoga semua orang akan mengatakan "LGTM". Jika programmernya pintar, dia akan ingat untuk berdoa / menyuap / menyembunyikan. Jika ada masalah serius, pengulas dapat membuat cacat (yang dapat dihubungkan ke sistem pelacakan bug), atau bahkan mengharuskan daftar perubahan untuk dicadangkan. Ya, perubahan yang disokong tidak hanya menyakiti ego, tetapi juga pikiran, itu benar. Ini adalah bumbu yang baik pada pengembang junior, untuk mengintegrasikan kembali daftar perubahan yang ditolak.

Jika lingkungan dev Anda kurang CI atau sistem peninjauan kode, Anda harus menyelidiki ini dengan serius. Beberapa tautan mungkin membantu Anda:

Atlassian Crucible
JetBrains TeamCity
reitveld
Cruise Control

Jika Anda akan mendapatkan server CI, Anda juga harus serius memikirkan kerangka kerja unit test. Jika Anda seorang C # dev, lihat sesuatu seperti NUnit untuk memulai.

Anda memberi tahu dia sebelumnya kapan kode Anda akan siap, bukan pada saat itu selesai. Anda harus dapat menentukan sekitar itu. satu minggu ke depan. Itu memberinya waktu untuk mempersiapkan dan merencanakan peninjauan sehingga cocok dengan kedua rencana Anda.