Saya telah tertarik pada pertanyaan ulasan kode untuk waktu yang sangat lama. Berkali-kali satu atau lain masalah muncul, baik dengan kualitas kode, atau dengan iklim dalam tim. Memang, tinjauan kode adalah jika bukan satu-satunya, maka salah satu tempat paling penting untuk konflik dalam tim pengembangan.
Dan baru-baru ini, dalam persiapan untuk rilis podcast Zinc Prod berikutnya , saya mengetahui bahwa Google telah menerbitkan kode praktik Peninjauan Kode yang penuh dengan pemikiran berharga. Semua materi cukup banyak dan tidak akan cocok menjadi satu artikel, jadi saya akan mencoba untuk menyoroti pemikiran (bagi saya) yang paling menarik.
Jadi ayo pergi
Istilah yang digunakan dalam artikel asli:
CL - daftar perubahan. Tapi biasanya itu disebut Permintaan Gabung atau Permintaan Tarik, jadi dalam artikel ini saya akan menggunakan singkatan MR
LGTM - Terlihat Bagus untukku. Singkatnya, ketika mereka menekan tombol "setujui". Saya akan menggunakan istilah "aprov" sebagai lebih dimengerti oleh publik.
Mr idealitas
Dalam praktiknya, seseorang dapat menemukan berbagai ekstrem ketika mempertimbangkan MR. Seseorang sebagai seluruh tim berkomentar zadalivaet, sampai semuanya dianggap sepele, dikoreksi, seseorang melihat tentang logika dan menekan "upruv".
Pikiran yang menarik ditulis dalam dokumen Google. MR seharusnya tidak sempurna, tetapi harus meningkatkan basis kode. Artinya, dengan setiap perubahan yang diperkenalkan, kode harus menjadi lebih baik dan lebih baik. Dan jika MR menambahkan banyak hal baik, maka Anda tidak perlu menemukan kesalahan dengan hal-hal kecil; lebih menguntungkan untuk mendapatkan peningkatan ini lebih cepat.
Tidak ada MR yang dapat memperburuk kode. Satu-satunya pengecualian adalah jika MR adalah perbaikan yang mendesak untuk sesuatu.
Kebebasan untuk berkomentar
Terlepas dari kenyataan bahwa Anda tidak dapat menyingkirkan hal-hal sepele, namun, Anda dapat dengan bebas menulis hal-hal sepele ini ke setidaknya setiap baris. Kontradiksi dengan paragraf sebelumnya diselesaikan dengan sederhana: resensi awalan sepele dan nit-picking dengan awalan "nit:" dari bahasa Inggris. nitpick (nitpicking). Tidak perlu memperbaiki komentar tersebut, namun, penulis MR mungkin ingin memperbaiki sesuatu atau, bahkan jika tidak, memperhitungkan beberapa poin untuk masa depan.
Fakta Lebih Dari Preferensi Pribadi
Hampir selalu, prinsip-prinsip desain perangkat lunak standar, berdasarkan praktik terbaik, lebih baik daripada sepeda rumit. Karena itu, preferensi harus diberikan kepada mereka.
Jika Anda dapat menerapkan beberapa pendekatan standar, maka ini merupakan kebijaksanaan penulis.
Kutipan langsung untuk pemahaman yang lebih baik:
Aspek desain perangkat lunak hampir tidak pernah menjadi masalah gaya murni atau hanya preferensi pribadi. Mereka didasarkan pada prinsip-prinsip yang mendasari dan harus ditimbang pada prinsip-prinsip itu, bukan hanya dengan pendapat pribadi. Terkadang ada beberapa opsi yang valid. Jika penulis dapat menunjukkan (baik melalui data atau berdasarkan prinsip-prinsip rekayasa padat) bahwa beberapa pendekatan sama-sama valid, maka peninjau harus menerima preferensi penulis. Kalau tidak, pilihannya ditentukan oleh prinsip standar desain perangkat lunak.
Jika pengulas dan penulis MR tidak setuju satu sama lain
Pertama datang upaya untuk mencapai konsensus dalam komentar di MR. Jika ini tidak berhasil, maka diskusi pribadi. Jika Anda masih belum mencapai konsensus, maka tarik anggota tim. Tetapi yang paling penting, MR tidak boleh macet untuk waktu yang lama karena ketidaksepakatan dua orang.
Dibahas dalam komentar -> Dibahas secara pribadi -> Dibahas dalam tim -> Pindah
Kecepatan cek MR
Kecepatan sangat penting. Jika Anda memberikan satu komentar setiap beberapa hari, maka penulis MR akan mengeluh bahwa mereka menemukan kesalahan padanya dan mencegahnya bekerja.
Jika MR diperiksa dengan sangat cepat, maka komentar apa pun tidak akan menjadi masalah besar - lagipula, perbaikannya akan diperiksa di sini, dan tugas akan berlanjut.
Google menyarankan Anda untuk tidak mengalihkan perhatian dari fokus pada tugas Anda, tetapi jika Anda terganggu, maka lihat apakah ada sesuatu untuk direvisi. Misalnya, dia kembali dari makan siang - dia merevisinya. Datang bekerja - direvisi. Dll
Pesanan tampilan MR
Pertama, Anda perlu melihat MR secara keseluruhan. Apakah perlu sama sekali, adalah kode di tempat yang tepat (atau harus di perpustakaan terpisah), apakah ada masalah global.
Yaitu tidak masuk akal untuk melihat beberapa detail implementasi jika kode tidak ada dan tidak ada sama sekali.
Secara umum, urutan tontonan penting untuk memberikan umpan balik kepada penulis sesegera mungkin (lihat paragraf sebelumnya).
Ketika Anda melihat MR secara keseluruhan, Anda harus melihat file-file utama, mis. periksa hal yang paling penting (jika tidak jelas apa yang paling penting, Anda dapat bertanya kepada pengembang).
Sekali lagi, masalah apa pun harus segera dilaporkan, bahkan jika Anda belum memeriksa MR dan memutuskan untuk memeriksanya secara umum nanti.
Selanjutnya, Anda perlu memilih urutan logis untuk melihat file yang tersisa. Tidak ada file yang harus dilewati.
Apa yang harus dicari saat melihat
- Kode ini dirancang dengan baik
- Fungsionalitas dibuat dengan baik dari sudut pandang pengguna kode ini, tidak peduli siapa mereka.
- Penampilan (jika ada) harus bagus
- Semua nuansa pemrograman paralel (jika ada) diperhitungkan.
- Kode tidak didesain ulang
- Pengembang tidak bekerja terlalu keras: Anda tidak perlu menulis kode yang mungkin diperlukan, atau mungkin tidak diperlukan
- Kode memiliki tes
- Tes dirancang dengan baik
- Nama (untuk semuanya) dipilih dengan baik
- Komentar pada kode dapat dimengerti dan diperlukan. Mereka harus menjelaskan mengapa ini dilakukan, dan bukan bagaimana melakukannya.
- Dokumentasi ditambahkan.
- Kode sesuai dengan panduan gaya.
MR terlalu besar
MR yang terlalu besar harus diminta untuk dibubarkan. Itu hampir selalu mungkin.
Cara menulis komentar pada ulasan kode
- Anda harus sopan, bukan untuk pribadi. Diskusikan kode, bukan enkoder.
- Bukan hanya mengeluarkan arahan untuk koreksi, tetapi jelaskan mengapa Anda harus memperbaikinya.
- Pertahankan keseimbangan: identifikasi masalah dan dorong pengembang sehingga ia sendiri memahami cara terbaik untuk menyelesaikannya; atau segera mengeluarkan solusi yang sudah jadi. Yang pertama mengembangkan pengembang (manfaat strategis), yang kedua meningkatkan dan mempercepat MR (manfaat taktis).
- Jika peninjau tidak mengerti pada suatu titik dalam kode dan meminta penulis untuk menjelaskan apa, maka jawaban terbaik adalah dengan mengubah kode. Sehingga semuanya jelas dari kode tanpa pertanyaan.
Jika Anda tidak setuju dengan pendapat Anda
Perlu dipahami secara rinci. Mungkin Anda tidak mengerti sesuatu, minta informasi lebih lanjut. Mungkin sebaliknya. Bagaimanapun, pemahaman sering muncul hanya setelah beberapa putaran penjelasan di kedua sisi.
Takut mengganggu penulis MR
Kebetulan pengembang marah jika peninjau bersikeras beberapa perubahan. Namun, kebanyakan pengembang kesal karena bentuk komentar, dan bukan karena konten. Bersikap sopan, jelaskan dengan argumen, dan kemungkinan besar semuanya akan baik-baik saja.
"Aku akan memperbaikinya nanti."
Jika pengembang setuju bahwa ada masalah dalam kode, tetapi meminta untuk memperbaiki MR, berjanji bahwa ia akan memperbaikinya lain kali, maka, menurut orang-orang dari Google, ini "nanti" paling sering tidak pernah terjadi. Oleh karena itu, jika MR bukan perbaikan bug mendesak, maka Anda harus meminta perbaikan.
Kesimpulan
Saya sangat menyukai dokumen ini dari Google. Terutama hack kehidupan dengan kata "nit", penekanan pada kecepatan ulasan kode, dan juga bahwa MR tidak harus sempurna. Tampaknya sederhana, tetapi selama ini jelas tidak dipertimbangkan, itu tidak mencapai titik.
Jika artikel ini tampaknya menarik bagi pembaca dan mengambil sejumlah keuntungan, maka saya akan menulis bagian berikut: proses tinjauan kode oleh penulis MR.
Perbarui: bagian kedua artikel di sini
Juga, dalam edisi mendatang Penjualan Seng, kami akan membahas secara rinci kode ulasan dari berbagai sudut. Jadi, pastikan untuk berlangganan podcast pengembangan kami !