Cara memberi umpan balik setelah proses peninjauan kode


10

Saat ini saya sedang meninjau beberapa kode pengembang junior yang baru saja bergabung dengan tim saya, saya bertanya-tanya bagaimana saya harus memberikan hasil tinjauan ini:

  1. Haruskah saya memperbaiki kode sendiri?

  2. Haruskah saya memberi mereka umpan balik tentang proses peninjauan dan membiarkan mereka melakukan perbaikan sesuai dengan instruksi saya? Dan jika demikian, bagaimana saya memberikan umpan balik ini, apakah saya mengisi dokumen templat tertentu dan mengirimkannya kepada mereka, atau ada beberapa perangkat lunak yang akan membantu saya menandai sesuatu dengan masalah di dalam file kode tempat mereka nanti dapat memeriksanya? (Saya menggunakan Visual Studio).

Setelah saya selesai meninjau kode dan perbaikan dilakukan kemudian beberapa waktu telah berlalu dan beberapa bagian dari kode yang saya tinjau di masa lalu telah berubah, bagaimana saya melakukan proses re-review? Haruskah saya periksa kembali semua kode lagi? Atau apakah saya hanya memeriksa bagian yang sudah berubah? Dan jika demikian, bagaimana cara melacak bagian yang telah diubah sehingga saya menghindari kode peninjauan ganda?


Jawaban:


14

Jawaban singkat

Haruskah saya memperbaiki kode sendiri?

Tidak.

Haruskah saya memberi mereka umpan balik tentang proses peninjauan dan membiarkan mereka melakukan perbaikan sesuai dengan instruksi saya?

Iya. Menurut saran Anda , bukan instruksi . Instruksi terdengar terlalu otoritatif.

Dan jika demikian, bagaimana saya memberikan umpan balik ini, apakah saya mengisi dokumen templat tertentu dan mengirimkannya kepada mereka, atau ada beberapa perangkat lunak yang akan membantu saya menandai sesuatu dengan masalah di dalam file kode tempat mereka nanti dapat memeriksanya? (Saya menggunakan Visual Studio).

Gunakan alat untuk memberikan umpan balik. Anda dapat menggunakan Visual Studio.

Jawaban panjang

Saya dulu menggunakan Visual Studio tetapi saya selalu harus bertanya kepada pengembang lain, "Hei, bisakah Anda mengirimkan pekerjaan Anda sehingga saya dapat memeriksanya?" Saya tidak suka itu dan itu tidak pernah berhasil dengan sangat baik. Sekarang, saya menggunakan Tinjauan Asisten karena saya dapat memulai ulasan dengan melihat checkin. Saya tidak perlu bergantung pada pengembang lain yang mengirimi saya pekerjaan untuk meninjau. Ini juga membantu saya menandai item sebagai cacat, atau cukup menandai item yang akan dilihat oleh penulis. Ini berfungsi untuk tim kami karena begitu kami memulai ulasan, ulasan itu tetap ada di papan ulasan dan tidak hilang dalam terjemahan. Ini terintegrasi dengan Visual Studio. Seperti yang saya sebutkan, Visual Studio juga memiliki proses peninjauan asli tetapi saya menemukan itu memiliki keterbatasan dan prosesnya tidak alami; oleh karena itu, saya menggunakan Asisten Peninjau.

Alat ini juga membantu proses bolak-balik, diskusi, dll.

Prosesnya, kurang lebih, adalah sebagai berikut:

Saya meninjau sesuatu, kemudian saya mengirimkannya ke penulis (dalam kasus Anda junior dev). Mereka membuat perubahan dan kemudian mengirimnya kembali. Saya melihat perubahan dan memberikan umpan balik. Jika saya baik dengan perubahan, saya tutup ulasan. Kalau tidak bolak-balik. Kadang-kadang jika ada terlalu banyak bolak-balik, saya hanya akan berjalan ke meja mereka dan menggunakan papan tulis - itu benar-benar mempercepat proses.

Ulasan kode adalah area sensitif, jadi berhati-hatilah dengan pilihan kata. Saya tidak pernah memberi tahu siapa pun

Pilihan kata yang buruk

Saya meninjau kode Anda dan ada beberapa item yang perlu Anda ubah.

Saya malah mengatakan ini:

Pilihan kata-kata yang lebih baik

Saya melihat kode Anda dan saya butuh bantuan. Bisakah Anda meninjau barang-barang yang saya kirimkan kepada Anda dan melihat apakah Anda dapat menjelaskan beberapa pertanyaan saya?

Ini membuat penulis berpikir:

  1. Saya butuh bantuan agar mereka tidak masuk ke mode defensif.
  2. Sepertinya mereka adalah peninjau, bukan saya. Secara teknis, karena saya meminta mereka untuk melihat dan mengubah beberapa hal, mereka seperti pengulas.

Pilihan kata sederhana ini sangat membantu saya.

Saya tidak pernah meremehkan para devs junior. Saya telah bekerja dengan beberapa pengembang senior (lebih dari 10 tahun pengalaman) dan ada kode yang lebih buruk daripada siswa junior co-op. Jadi hanya karena mereka senior atau junior tidak terlalu penting; pekerjaan mereka benar-benar apa yang berbicara lebih keras daripada pengalaman bertahun-tahun.

Seringkali, untuk mendorong para biarawan junior dan membuat mereka berpartisipasi dalam ulasan, saya akan mengirim mereka sesuatu untuk mengulas untuk saya: Sesuatu yang bisa mereka pahami, sesuatu yang akan mereka temukan menantang tetapi tidak sepenuhnya melampaui mereka. Saya dapat mengatakannya seperti di bawah ini:

Tolong tinjau beberapa kode untuk saya karena saya tidak tahu.

Ini sangat membantu saya lagi. Ini membantu karena jelas menunjukkan bahwa saya bukan satu-satunya yang mengulas, tetapi mereka juga melakukan tinjauan dan mereka juga bagian dari proses. Ini menunjukkan bahwa seluruh ide adalah untuk menghasilkan kode yang baik dan bersih dan meminta bantuan jika diperlukan. Proses peninjauan adalah budaya sehingga kami benar-benar perlu bekerja di sana.

Sekarang beberapa orang mungkin khawatir bahwa jika mereka melakukan hal di atas, para junior devs akan kehilangan rasa hormat karena mereka hanya melakukan sesuatu yang tidak dapat Anda lakukan. Tapi itu jauh dari kebenaran: meminta bantuan menunjukkan kerendahan hati. Plus ada banyak situasi di mana Anda dapat bersinar. Akhirnya jika itu adalah ketakutan Anda, Anda memiliki masalah harga diri. Terakhir, mungkin saya benar-benar tidak mengetahuinya: Maksud saya beberapa dev ini memiliki algoritma baru di kepala mereka karena mereka baru mempelajarinya sebulan yang lalu.

Bagaimanapun, kembali ke junior dan ulasan. Anda harus melihat raut wajah mereka ketika mereka mencari tahu dan mengirim saya balasan. Saya kemudian dapat mengatakan kepada mereka, "Oke, biarkan saya melakukan perubahan dan jika Anda senang dengan itu, silakan tutup masalah ini."

Mereka merasa luar biasa memiliki kekuatan untuk melihat pekerjaan saya dan berkata: "Ya, perubahan Anda baik. Saya menutup masalah."

Saya tidak pernah memperbaiki kode sendiri karena:

  1. Penulis tidak akan belajar dari itu.
  2. Seperti yang saya katakan: "Minggir, izinkan saya menunjukkan kepada Anda bagaimana hal itu dilakukan. Kode saya lebih baik daripada milik Anda."
  3. Mengapa saya harus? Ini lebih banyak pekerjaan untuk saya.

Tetapi saya akan menyarankan ide dan cuplikan kode dalam komentar saya untuk membantu penulis. Harap perhatikan bahwa kadang-kadang ulasan saya hanya menanyakan kepada penulis bahwa saya tidak mengerti kode mereka; mungkin tidak ada yang salah dengan kode mereka. Mereka mungkin perlu mengubah nama variabel, menambahkan komentar dll. Dengan demikian, saya bahkan tidak akan tahu apa yang harus diubah dalam kasus itu; hanya mereka yang akan melakukannya.

Jika Anda terus melakukan tinjauan, Anda akan, cepat atau lambat, memiliki gagasan yang sangat bagus tentang tingkat pengetahuan setiap pengembang dalam tim. Mengetahui hal ini sangat berguna dan Anda perlu mengambil manfaat darinya dan melepaskannya. Begini caranya: Jika saya meninjau beberapa kode dan melihat area yang jelas untuk peningkatan dan saya tahu pengembang lain mungkin menangkapnya juga, saya akan meminta mereka untuk memeriksanya. Sesuatu seperti "Hei, saya melihat beberapa area yang dapat ditingkatkan. Bisakah Anda memeriksanya lebih detail dan mengirim komentar Anda ke penulis?" Ini bekerja sangat baik karena sekarang saya memiliki 2 devs lainnya yang bekerja satu sama lain.

Jika saya meninjau beberapa pekerjaan dan saya melihat sesuatu yang dapat dimanfaatkan oleh seluruh tim, maka saya akan membuat skenario hipotetis dan menjelaskan masalah tersebut dalam sebuah pertemuan. Saya akan mulai dengan menjelaskan skenario dan bertanya kepada semua orang apakah mereka dapat menemukan masalah atau melihat masalah, melibatkan mereka. Ajak semua orang untuk bertanya. Maka akhirnya hadir pendekatan yang lebih baik. Jika orang lain memiliki pendekatan yang lebih baik, saya berterima kasih kepada mereka dan mengakui di depan tim pendekatan mereka lebih baik. Ini menunjukkan bahwa saya bukan tipe kepribadian "jalan saya atau jalan raya". Selain itu, saya TIDAK PERNAH membuka pekerjaan seseorang dan mulai menunjukkan masalah dalam sebuah pertemuan, penulis tidak akan menghargainya - terlepas dari seberapa baik dan tidak berbahaya saya pikir saya sedang.

Ketika saya melakukan review, saya tidak hanya mencari kode bersih yang baik tetapi juga apa yang dilakukan oleh kode tersebut. Jika persyaratan bisnisnya adalah: Jika seorang karyawan telah bersama perusahaan selama lebih dari 10 tahun, beri mereka kenaikan 5%. Kalau tidak, 2,5% . Hal pertama yang saya periksa adalah apakah benar-benar melakukan itu. Lalu saya memeriksa apakah itu melakukannya dengan cara yang bersih, konsisten dan berkinerja.

Jika saya melakukan review, saya pastikan untuk menindaklanjutinya atau tidak ada yang akan menganggap ulasan itu serius.

Saya dulu bekerja dengan seseorang bertahun-tahun yang lalu yang akan melakukan tinjauan dan memberi tahu manajer dev, dan manajer QA tetapi kedua manajer tersebut berasal dari latar belakang bisnis atau memiliki sedikit pengalaman pengembangan. Dia hanya melakukan ini untuk mengesankan mereka. Tidak ada yang menyukainya dan saat itulah aku berkata pada diriku sendiri aku tidak akan pernah melakukan kesalahan itu.

Hal lain yang biasa ia lakukan adalah memilih gaya pemrograman dan yakin gayanya adalah yang terbaik ("Kungfu saya jauh lebih baik daripada gaya monyet Anda ..."). Itu pelajaran lain bagi saya: selalu ada lebih dari 1 cara untuk menyelesaikan masalah.

Jawab beberapa pertanyaan bernomor Anda

1 - haruskah saya memperbaiki kode sendiri?

Tidak, harap lihat alasan yang saya nyatakan di atas.

2 - haruskah saya memberi mereka umpan balik tentang proses peninjauan dan membiarkan mereka melakukan perbaikan sesuai dengan instruksi saya?

Ya, coba gunakan kalimat dan nada yang ramah tetapi membutuhkan perhatian. Menjadi sejelas mungkin. Nyatakan apa masalahnya dengan kode itu, bagaimana memperbaikinya. Jangan hanya meminta untuk mengubahnya. Namun berikan alasan.

bagaimana saya memberikan umpan balik ini, apakah saya mengisi dokumen templat tertentu dan mengirimkannya kepada mereka, atau ada beberapa perangkat lunak yang akan membantu saya menandai hal-hal dengan masalah di dalam file kode tempat mereka nanti dapat memeriksanya? (Saya menggunakan Visual Studio).

Seperti yang saya katakan, Anda dapat menggunakan alat yang saya gunakan atau alat lain. Jangan gunakan email atau dokumen kata karena tersesat dan sulit untuk melacaknya.

Setelah saya selesai meninjau kode dan perbaikan dilakukan maka kadang-kadang telah berlalu dan beberapa bagian dari kode yang saya tinjau di masa lalu telah berubah, bagaimana saya melakukan proses re-review? haruskah saya periksa kembali semua kode lagi?

Kebanyakan yang saya lakukan adalah memeriksa delta (perubahan saja). Tetapi Anda harus memiliki gambaran keseluruhan untuk memastikan tidak ada yang rusak dan mengikuti arsitektur.

Pikiran terakhir

Saya pribadi berpikir kata "review kode" adalah pilihan yang buruk dan tidak tahu bagaimana memulainya. Mereka bisa memilih kata yang jauh lebih baik dan kurang otoritatif.


Ini hanya akan berfungsi untuk hal-hal kecil seperti nama variabel. Namun, jika arsitekturnya salah, tidak ada alat yang dapat membantu. Anda hanya perlu membuang semuanya dan menulis ulang.
t3chb0t

@ t3chb0t Mengapa hal-hal kecil? Dengan making sense architecturally, saya bermaksud memastikan kode lapisan akses data berada di dalam lapisan akses data, validasi UI ada di UI dll. Dengan kata lain, memastikan kekhawatiran tidak berdarah ke area lain. Ada alat untuk membantu menjaga arsitektur; sebenarnya VS melakukan ini sekarang di luar kotak sekarang . Kami juga menggunakannya.
CodingYoshi

Berkenaan dengan alat, saya pikir alat yang benar-benar valid untuk digunakan adalah segala bentuk perangkat lunak tiketing / pelacakan kerja yang mungkin sudah Anda gunakan untuk melacak apa yang perlu dilakukan. Misalnya, jika Anda menggunakan Github, Anda mungkin memiliki semua perubahan yang terkait dengan masalah dan kemudian ulasan akan dilakukan di utas diskusi itu. Jira dan Trac adalah dua alat lainnya. Ini membuat tempat terpusat untuk semua info yang terkait dengan pekerjaan dan itu terlihat jelas sebelum tiket ditutup.
Kat

@ Kat Saya tidak yakin apakah alat tiket adalah alat yang tepat untuk digunakan di sini. Alat ulasan kode menunjukkan perbedaan antara perubahan dan masalah adalah masalah yang berbeda dari masalah pada sistem tiket; mereka berarti hal yang berbeda. Tapi saya bisa saja salah.
CodingYoshi

3

Banyak tergantung pada bagaimana Anda memahami ulasan kode di perusahaan Anda. Ada perusahaan di mana tinjauan kode adalah proses yang sangat formal yang jarang terjadi tetapi merupakan masalah besar. Di sisi lain, tinjauan kode adalah bagian wajib dari setiap tugas yang diimplementasikan, dan merupakan hal yang sangat biasa dan cepat dengan sedikit formalisme. Secara pribadi, saya memilih pendekatan yang terakhir, tetapi mungkin atau mungkin bukan keputusan Anda jika Anda dapat menggunakannya atau tidak.

Saya menulis posting blog berjudul Apakah ulasan kode layak untuk Anda? untuk merangkum proses yang digunakan oleh tim saya. Takeaways, karena berkaitan dengan pertanyaan Anda akan:

  1. Biarkan pengembang memperbaiki kode. Ini akan memungkinkan mereka untuk lebih memahami komentar Anda (atau menyadari bahwa mereka tidak sepenuhnya mengerti dan bertanya), dan melakukan tugas adalah cara belajar yang lebih baik daripada hanya membacanya.
  2. Perangkat lunak untuk ulasan kode adalah caranya. Ada banyak opsi yang tersedia, baik open-source dan proprietary. Sebagian besar bekerja dengan git. Tim saya menggunakan BitBucket (sebelumnya dikenal sebagai Stash), ada juga GitLab dan GitHub, Gerrit (yang saya pribadi bukan penggemar), dan banyak lainnya. Sebagian besar aplikasi ini berbasis web sehingga tidak masalah apa IDE yang Anda gunakan, tetapi ada juga plugin untuk banyak IDE, jadi saya yakin ada beberapa untuk Visual Studio juga. Perangkat lunak seperti ini memungkinkan Anda untuk meninjau kode sebelum digabungkan ke cabang utama (biasanya melalui Permintaan Tarik) dan memperlihatkan bagian yang dimodifikasi dan beberapa garis konteks di sekitar setiap perubahan. Ini membuat tinjauan kode lancar dan tidak merepotkan.

Adapun siklus review-fix-check-the-fix, apa yang Anda pilih harus bergantung pada kematangan pengembang dan beratnya masalah yang Anda temukan. Setelah tim membuat tinjauan kode sebagai proses harian, Anda dapat mengharapkan perubahan sepele seperti mengganti nama kelas, untuk diterapkan secara sederhana dan mungkin tidak perlu memeriksanya kembali. Jika tim belum dijual berdasarkan ulasan kode atau orang-orangnya benar-benar tidak berpengalaman, Anda mungkin ingin memeriksa hal-hal seperti itu. Di sisi lain, jika ulasan Anda menemukan masalah konkurensi kompleks yang mungkin tidak sepenuhnya dipahami oleh para junior dev setelah Anda menunjukkannya, Anda sebaiknya memeriksa perbaikannya dan tidak memberikan perubahan pada persetujuan Anda sebelum Anda yakin itu benar-benar diperbaiki.

Alat dapat membantu Anda dengan ini karena jika Anda bekerja dengan permintaan tarik, Anda dapat dengan mudah mengatur perangkat lunak untuk tidak membiarkan penggabungan perubahan sampai memiliki persetujuan dari sejumlah pengembang yang telah ditentukan. Biasanya Anda dapat melihat perubahan dalam setiap komitmen dari perubahan yang memungkinkan Anda untuk dengan mudah melihat hanya perubahan yang ditambahkan sejak putaran komentar terakhir Anda.


1

Saya memilih opsi kedua. Junior mungkin memiliki "lerning curve" yang lebih baik ketika melakukan perubahan sendiri.

Juga: jangan hanya menjadi satu-satunya yang meninjau kode.
Biarkan beberapa anggota tim Anda yang berpengalaman juga melihat kode dan menjadwalkan pertemuan tinjauan berkala di mana pengulas mempresentasikan temuan mereka (mereka buat sebelum pertemuan!) Kepada penulis. Ini akan meningkatkan motivasi dari kedua, junior dan anggota tim pengalaman.


4
Poin yang bagus. Juga, junior harus "meninjau" kode OP dan kode masing-masing juga.
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.