Sedang dipersiapkan untuk tinjauan kode sebagai pengembang?


10

Saya mencari beberapa ide di sini.

Saya membaca artikel Bagaimana seharusnya ulasan kode dilakukan dan Ulasan Kode, apa kelebihannya? yang sangat informatif tetapi saya masih perlu kejelasan tentang pertanyaan di bawah ini.

Pertanyaanku adalah,

  1. Menjadi pengembang target, dapatkah Anda menyarankan beberapa praktik terbaik yang dapat dimasukkan oleh pengembang sebelum kodenya ditinjau.

    • Saat ini saya berlatih metode berikut

      • PPT untuk aliran logis
      • Komentar terperinci.

Masalah: Meskipun saya telah menerapkan praktik-praktik di atas, mereka tidak membantu dalam peninjauan. Masalah yang saya hadapi adalah, ketika logika tertentu dirujuk, saya terus mencari implementasi dan aliran dan terlalu banyak waktu yang terbuang dalam proses dan saya membuat orang takut.

Saya pikir banyak pengembang akan melalui apa yang saya lalui juga.


2
Hanya satu: jangan lakukan hal-hal bodoh dalam kode Anda.
BЈовић

1
KISS: jika kodenya sederhana, otak Anda dapat mengatur semuanya.
mouviciel

ketika Anda melakukan peninjauan kode di perusahaan Anda, siapa yang biasanya memimpin rapat? Anda atau orang yang sedang meninjau pekerjaan Anda? Saya bertanya karena pertemuan tinjauan kode di IMO bukan tempat untuk menghabiskan waktu mencari potongan-potongan kode bahkan jika Anda benar-benar cepat dalam mencari sesuatu.
DXM

@DXM Terima kasih atas balasannya. TL saya akan memimpin rapat.
Karthik Sreenivasan

@Arthik: k, bagian itu bagus. Jadi berdasarkan pertanyaan Anda, Anda tidak bertanya bagaimana menulis dan menghasilkan kode berkualitas tinggi yang siap untuk ditinjau kode. Alih-alih, perhatian utama Anda adalah ini: "Saya terus mencari implementasi dan alur serta terlalu banyak waktu yang terbuang". Dapatkah Anda menguraikan itu? mengapa Anda melakukan pencarian jika TL memiliki kode di depannya dan memimpin rapat?
DXM

Jawaban:


8

Jadi berdasarkan perincian yang diberikan OP, sepertinya pertanyaannya adalah, "bagaimana saya mempelajari kode saya sendiri sehingga ketika diminta untuk menemukan X atau menjelaskan Y, saya dapat merespons dengan cepat."

Beberapa saran yang dapat saya pikirkan:

  • Saat membuat kode, Anda perlu meluangkan waktu untuk mempelajari dan memahami kode Anda sendiri. Ini bisa menjadi apa yang TL Anda coba sampaikan kepada Anda dengan tidak banyak kata. Menjadi TL pada proyek saat ini, saya telah melakukan banyak tinjauan kode dalam 11 bulan terakhir dan saya melihat ada praktek dari beberapa pengembang untuk mencari "contoh kode" baik di basis kode kita sendiri, atau di tempat lain (google , dll ...) dan salin / tempel. Secara pribadi, saya tidak tahan karena ketika kode mereka melewati tes unit sederhana, mereka tidak mengerti apa yang sebenarnya dilakukan, jadi kami tidak pernah dijamin bahwa tidak ada t beberapa kasus batas atau kondisi kegagalan yang diharapkan yang dapat terjadi.

  • Sebagai konsekuensi wajar dari pernyataan sebelumnya, jika Anda harus menyalin / menempel, cobalah hanya menyalin / menempelkan kode yang sebelumnya telah Anda tulis dan yang Anda pahami. Tentu saja tidak apa-apa untuk "meminjam" ide orang lain tetapi dalam kasus itu, menulis ulang kode mereka baris demi baris karena ketika Anda menulisnya, Anda akan mendapatkan pemahaman yang lebih baik tentang apa yang dilakukannya. Jika Anda menggunakan API eksternal, bahkan jika Anda memiliki contoh yang menggunakan API itu, luangkan beberapa menit untuk menemukan referensi dan mempelajari cara kerja API itu. Jangan hanya berasumsi bahwa jika berhasil sebelumnya, itu juga akan berfungsi dalam situasi Anda.

  • Baca dan belajar untuk mencintai prinsip KERING . Sering kali Anda tergoda untuk menyalin / menempel dapat ditempatkan di lokasi yang sama (fungsi terpisah, kelas terpisah, perpustakaan terpisah ...)

  • Baca dan belajar untuk mencintai prinsip - prinsip SOLID dan ketika Anda berada di sana, tinjau KISS yang sudah disebutkan oleh mouviciel. Prinsip-prinsip ini semuanya berorientasi pada pembuatan kode yang sangat ringkas, bersih dan modular. Jika Anda memiliki kelas besar dan fungsi besar di dalamnya, jelas akan jauh lebih sulit untuk menemukan hal-hal dan di atas itu cobalah menjelaskan apa yang dilakukan kode. Di sisi lain, jika Anda mengikuti (atau setidaknya mencoba mengikuti) SRP dan membuat setiap kelas / fungsi bertanggung jawab untuk satu hal saja, kode Anda akan kecil dan sangat mudah dibaca.

  • Ambil salinan Kode Bersih . Buku yang sangat bagus. Ini berbicara tentang menulis kode yang cukup jelas dan mudah dibaca, dipelihara dan diperluas. Jika Anda berlatih menulis kode yang mudah dibaca, Anda seharusnya tidak memiliki masalah membaca kode Anda sendiri dalam ulasan kode. Dan ini bagian yang lucu, saya meminta orang untuk membaca kode mereka sendiri atau hanya memberi tahu saya apa variabel mewakili dan mereka tidak bisa menjawab meskipun mereka menulis kode itu (kelas baru, bukan warisan) hanya seminggu yang lalu . Penamaan yang baik sangat membantu.

  • Jika setelah semua penyederhanaan dan refactoring, Anda masih memiliki fungsi yang harus melakukan beberapa jenis algoritma yang tidak terlalu jelas, meluangkan waktu dan menulis blok komentar di fungsi yang menjelaskan algoritma. Tidak hanya akan membantu ketika Anda harus memodifikasi fungsi itu 2 bulan dari sekarang, tetapi jika Anda disergap dalam tinjauan kode, Anda akan dapat dengan mudah membaca kembali apa yang Anda tulis.

  • Jika setelah semua item di atas, apakah Anda masih menemukan masalah? apakah Anda baru di tim dan diminta bekerja dengan banyak kode lama? Dalam hal ini, bisa jadi TL Anda menjadi A $$ dan Anda bisa proaktif dengan memintanya sebelum rapat agar mudah dan tidak membuang waktu semua orang yang terlibat. Ketika orang baru bergabung dengan sebuah tim, TL perlu memiliki kesabaran yang cukup karena bekerja di platform baru, produk baru, orang baru, lingkungan baru membutuhkan banyak konsentrasi dari orang baru, dan orang itu akan kehilangan beberapa detail di awal. Berfungsi sebagai Dirancang dan TL Anda seharusnya menerimanya.

  • Jika setelah semua item di atas, Anda masih merasa bahwa Anda memiliki ulasan kode yang mengerikan. Bicaralah dengan TL Anda. Kadang-kadang orang merasa buruk karena sifat pertemuan peninjauan kode padahal sebenarnya TL sangat senang dengan Anda. Ketika saya melakukan review kode, tujuan saya adalah untuk menyoroti apa yang perlu diubah, pastikan Anda memahami perubahan dan melanjutkan. Banyak kali saya tidak punya waktu untuk bersikap sopan dan beberapa orang bersikap defensif dan berusaha menjawab setiap komentar saya. Dalam situasi tersebut, pertemuan tinjauan kode berhenti, jadi saya cenderung menyela mereka dan melanjutkan. Secara umum, setelah pertemuan saya akan berbicara dengan orang-orang baru untuk memastikan mereka memahami prosesnya dan itu bukan masalah pribadi. Setelah beberapa ulasan kode orang umumnya lebih nyaman.


+1 untuk "jangan salin dan tempel kode yang tidak Anda mengerti". Itu tidak bisa ditoleransi! Juga memberi +1 untuk "berbicara dengan TL Anda"
MarkJ

@DXM Kemampuan Anda untuk memahami nuansa pertanyaan yang lebih halus sangat profesional dan jawaban Anda sangat informatif dan deskriptif. Pikiran = Ditiup!
Karthik Sreenivasan

@DXM Dari referensi Anda "Di sisi lain, jika Anda mengikuti (atau setidaknya mencoba untuk mengikuti) SRP dan membuat setiap kelas / fungsi bertanggung jawab untuk satu hal saja, kode Anda akan kecil dan sangat mudah dibaca." Bisakah Anda memberi tahu saya apa artinya * SRP ? * Saya melihat posting lain yang menarik tentang kejelasan kode di sini .
Karthik Sreenivasan

1
@KarthikSreenivasan - Dalam konteks ini digunakan praktik di mana metode atau kelas bertanggung jawab atas satu hal. Misalnya metode yang menambahkan angka bersama tidak boleh juga mengembalikan rata-rata. Pencarian sederhana menemukan ini: en.wikipedia.org/wiki/Single_responsibility_principle
Ramhound

10

Praktiknya bervariasi, tetapi menurut pengalaman saya:

  • Jangan lakukan sesuatu yang spesial pada kode. Wajar untuk meningkatkan kode Anda sedikit lagi ketika Anda mengetahui bahwa kode itu akan ditinjau, dan tidak ada salahnya memperbaiki hal-hal yang jelas seperti kesalahan pengejaan dan semacamnya. Tetapi jangan masuk dan menambahkan banyak komentar rinci atau mengubah kode hanya karena dijadwalkan untuk ditinjau.

  • Kode disiapkan dan didistribusikan kepada pengulas sebelum ulasan. Ini biasanya dilakukan oleh pihak ketiga yang netral, mungkin fasilitator peninjau kode. Jika dicetak, kode harus cukup kecil sehingga garis tidak terlalu sering dibungkus, tetapi cukup besar sehingga semua orang dapat membacanya dengan mudah. Cetak dalam format lansekap jika memang itu yang diperlukan.

  • Kode harus dicetak atau ditampilkan dengan nomor baris . Lebih disukai, nomor tersebut harus dilanjutkan dari satu file ke yang berikutnya. Jauh lebih mudah untuk merujuk ke "baris 3502" daripada "baris 238 dari foo.c", dan memiliki angka memungkinkan semua orang berbicara tentang garis tertentu tanpa membuang waktu untuk menemukan garis itu.

  • Pasti harus ada fasilitator , btw. Tugasnya adalah menjaga agar review tidak terhambat dalam hitungan mini, mencegahnya menjadi pribadi atau memanas, dan dengan ketat membatasi panjang review.

  • Sebagai penulis, Anda harus meninjau kode sendiri sebelum rapat peninjauan. Tuliskan perubahan yang Anda sarankan jika ini adalah kode orang lain. Ini menyatukan ingatan Anda tentang kode yang mungkin tidak Anda lihat dalam beberapa hari, dan ini juga membantu Anda berlatih melihat kode Anda sendiri dengan mata kritis. Setelah melalui beberapa ulasan, baik sebagai peninjau maupun sebagai penulis, Anda akan menemukan bahwa catatan Anda akan lebih cocok dengan yang lainnya.

  • Bersiaplah untuk mencatat selama peninjauan. Ini seharusnya tidak menjadi perhatian utama Anda - orang lain harus merekam item tindakan yang disetujui kelompok sehingga Anda dapat fokus pada menjelaskan kode dan mendengarkan umpan balik. Tetapi ada saat-saat ketika Anda mendapatkan umpan balik yang berharga yang bukan merupakan item tindakan, dan Anda harus memperbaiki hal-hal seperti itu saat terjadi.

  • Ingatlah bahwa itu bukan masalah pribadi. Sulit untuk menghindari perasaan (dan akting) defensif selama ulasan. Tidak apa-apa untuk menjelaskan kode Anda jika Anda pikir itu disalahpahami, tetapi lebih dari segalanya coba dengarkan saja.


Saya akan menambahkan satu hal: "baris 3502" akan menjadi tanda merah besar. Memiliki file yang sangat panjang jelas merupakan hal yang buruk.
BЈовић

2
@ VJo: Caleb menyarankan agar nomor baris dilanjutkan di seluruh file, jadi baris 3502 sebenarnya adalah baris 238 dari foo.c.
Heinzi

Saya tidak setuju dengan nomor baris yang berlanjut di file. Bagi saya, itu hanya membingungkan dan canggung. Jika ada masalah yang ditemukan, mereka harus dilacak berdasarkan modul (kelas, file, bahkan metode). Selain itu, selama peninjauan kode, Anda seharusnya tidak meninjau keseluruhan sistem, melainkan subsistem atau bahkan beberapa kelas atau file, jadi seharusnya tidak terlalu sulit untuk melacak di mana perubahannya.
Thomas Owens

1
@ThomasOwens Nomor baris semata-mata untuk tujuan dengan mudah menggambarkan lokasi dalam kode yang ditinjau selama peninjauan. Lebih cepat dan lebih rentan kesalahan daripada menggunakan "file foo.c, line 123," dan OP secara khusus menanyakan tentang menghabiskan lebih sedikit waktu untuk menemukan kode. Setuju bahwa masalah harus dilacak berdasarkan file. IME, ulasan cenderung mencakup sekelompok kelas, mungkin dua yang besar atau selusin yang kecil. 3500+ baris terlalu banyak untuk ditinjau sekaligus - hanya mencoba menunjukkan bahwa angka terus dari satu file ke yang berikutnya.
Caleb

Jika Anda teratur, itu tidak masalah. Bagi saya, saya merasa itu akan memperlambat saya. Saya telah terlibat dengan ulasan kode dan saya selalu mencetak file, menjilidnya berdasarkan kelas / file, dan kemudian membaca dan menjelaskannya. Jika seseorang ingin memberi tahu saya di mana mencarinya, saya ingin pasangan nama file / nomor baris - itu akan membuatnya lebih mudah bagi saya, terutama karena IDE saya mencetak nama file di header / footer pada setiap halaman dan saya mencetak nomor baris berdasarkan per file.
Thomas Owens

3

Satu hal lagi untuk ditambahkan ke jawaban lain: untuk membuat pengulas kode formal lebih mudah, lakukan BANYAK ulasan kode informal ! Contohnya:

"Hei Bob, bisakah aku menunjukkan kepadamu bagaimana aku menerapkan fungsi foo ()?" "Hei Steve, bisakah kamu melihat diagram kelas ini dan biarkan aku tahu apa yang kamu pikirkan?" "Hei, Karen, bisakah kamu membantuku memikirkan masalah ini? Kurasa aku punya solusi yang bagus, tapi aku bisa menggunakan bantuanmu ..."

Jadikan ini kebiasaan biasa. Ketika Anda melibatkan rekan kerja di awal proses desain, Anda:

  • Bangun hubungan
  • Dapatkan wawasan baru tentang masalahnya
  • Tingkatkan kemampuan Anda untuk menjelaskan masalah / solusi yang ada
  • Hemat waktu nanti dalam ulasan kode formal

+1 untuk membangun tim dan Tingkatkan kemampuan Anda untuk menjelaskan masalah. Itu memang ide yang bagus!
Karthik Sreenivasan
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.