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:
Haruskah saya memperbaiki kode sendiri?
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?
sumber
Jawaban:
Jawaban singkat
Tidak.
Iya. Menurut saran Anda , bukan instruksi . Instruksi terdengar terlalu otoritatif.
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 malah mengatakan ini:
Pilihan kata-kata yang lebih baik
Ini membuat penulis berpikir:
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:
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:
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
Tidak, harap lihat alasan yang saya nyatakan di atas.
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.
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.
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.
sumber
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.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:
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.
sumber
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.
sumber