Mungkin Anda membaca bagian pertama artikel tentang kode ulasan oleh resensi (omong-omong, kami sudah berhasil membahasnya dalam edisi terakhir podcast Zinc Prod ).
Karena artikel tersebut mendapatkan banyak suka, saya menulis kelanjutan yang dijanjikan tentang ulasan kode di sisi lain - dari penulis perubahan kode
Seperti biasa, kita akan mengatakan MR (Permintaan Gabung), bukan CL, karena sedikit orang yang memahami istilah CL.
Instruksi asli untuk penulis MR menurut Google dapat ditemukan di sini , dan saya akan memeras singkat.
Jadi ayo pergi
Deskripsi MR
Di Google, deskripsi perubahan disimpan dalam sejarah sistem kontrol versi, dan sangat mungkin bahwa banyak orang akan membacanya di masa mendatang. Karena itu, deskripsi MR sangat penting.
Baris pertama (dalam judul) harus berisi satu frasa yang menggambarkan apa yang dilakukan dalam MR. Selain itu, menurut tradisi, gaya imperatif (imperatif) digunakan, yaitu Hapus blablabla , bukan Menghapus blablabla
Deskripsi itu sendiri harus informatif, berisi deskripsi singkat tentang masalah yang sedang dipecahkan, tautan ke dokumen yang diperlukan (jika perlu), tugas pelacak tugas, dan konteks lainnya. Bahkan di MR kecil, sesuatu seperti itu seharusnya.
Deskripsi tipe "Perbaiki bug", tentu saja, dianggap tidak memadai.
MR harus sekecil mungkin
- MR kecil dapat diperiksa dengan cepat
- Verifikasi akan lebih bermakna
- Lebih kecil kemungkinannya untuk melewatkan bug.
- Tidak terlalu ofensif jika seluruh MR ditolak. Sangat buruk ketika banyak pekerjaan dilakukan, dan kemudian ternyata semua ini tidak perlu sama sekali
- Lebih mudah mendorong perubahan, lebih sedikit konflik
- Lebih mudah untuk mendapatkan kode berkualitas baik.
- Semakin banyak perubahan dalam satu waktu, semakin sulit untuk memutar kembali kode jika perlu
Sangat jarang ada situasi ketika tidak mungkin untuk mengurangi ukuran MR, memecahnya menjadi berkeping-keping. Peninjau memiliki hak untuk menolak MR jika terlalu besar
Tentu saja, tidak ada aturan yang keras dan cepat, MR mana yang akan dianggap besar, yang kecil. Apakah 100 baris kode besar atau tidak? Siapa tahu.
- MR harus melakukan satu hal. Biasanya ini bukan fitur keseluruhan, tetapi bagian dari itu
- Pisahkan refactoring menjadi MR terpisah
MR harus kecil tetapi mandiri
- Segala sesuatu yang peninjau perlu memahami MR harus di MR itu
- Setelah menyuntikkan kode, sistem harus berfungsi secara normal.
- Jika metode API ditambahkan, metode untuk menggunakannya harus ditunjukkan dalam MR yang sama. Dengan kata lain, MR seharusnya tidak terlalu kecil sehingga akan sulit untuk memahami bagaimana itu akan digunakan, apa konsekuensi yang akan ditimbulkannya.
- Tutup kode dengan tes, dan tes harus di MR yang sama
Jangan mengambil hati
Terkadang pengulas tidak terlalu sopan, mereka dapat menulis sesuatu yang buruk tentang kode Anda. Ini tidak terlalu profesional di pihak mereka, tetapi seringkali masih ada butir kebenaran dalam komentar seperti itu, dan ini harus diperhitungkan. Jangan merespons terlalu keras. Ini hanya akan memperburuk situasi.
Jika Anda tidak menyukai nada percakapan dalam komentar, lebih baik menemukan orang ini dan berbicara dengannya secara pribadi, untuk menjelaskan apa yang tidak sesuai dengan Anda.
Jika ini tidak membantu, Google menyarankan untuk menghubungi manajer.
Dari pengalaman saya, saya ingin menambahkan bahwa sering seseorang menulis komentar tidak sopan sering tidak memberikan akun yang dapat terlihat agresif. Teks menyembunyikan setengah emosi; misalnya, apa yang dikatakan dengan nada ramah bercanda dalam bentuk teks mungkin tampak seperti pukulan keras. Karena itu, saya sepenuhnya setuju dengan Google - jika terjadi kesalahpahaman, komunikasikan hanya secara langsung!
Jelaskan kodenya
Jika Anda diminta untuk menjelaskan beberapa poin dalam kode, pertimbangkan apakah Anda dapat memperbaiki kode tersebut sehingga dapat dimengerti tanpa penjelasan. Karena jika seseorang tidak mengerti, maka orang lain mungkin tidak mengerti.
Tanggapan untuk Komentar Peninjau
Seringkali, ketika pekerjaan dilakukan dan dikirim ke kode ulasan, secara psikologis sulit untuk menerima kenyataan bahwa sesuatu juga harus diperbaiki. Karena itu, cobalah untuk tidak melihat komentar-komentar dari resensi dengan permusuhan, berpikir, mungkin dia benar, dan kode akan menjadi lebih baik sebagai hasilnya.
Namun, jika peninjau masih salah, silakan menulis tentangnya, memberikan jawaban dengan argumen dan fakta.
Kesimpulan
Secara umum, seperti yang saya pahami dari dokumen dari Google, penulis MR harus melakukan segalanya untuk membuat pengulas lebih mudah; agar peninjau memahami mengapa kode itu dibuat, bagaimana kode itu dibuat, harus ada semua konteks yang diperlukan untuk memahami, dll.
Tidak dapat dihindari bahwa pertentangan akan diselesaikan dengan mencapai konsensus dalam bentuk profesional yang sopan.
Dalam terbitan Zinc Selling berikutnya, kita pasti akan membahas artikel ini (dan banyak lagi), jadi pastikan untuk berlangganan podcast kami , jika tidak lewati bagian yang menyenangkan!