Kapan melakukan Peninjauan Kode

15

Kami baru saja pindah ke proses scrum dan sedang mengerjakan tugas dan kisah pengguna di dalam sprint. Kami ingin sering melakukan tinjauan kode untuk membuatnya tidak terlalu menakutkan. Kami berpikir untuk melakukannya pada tingkat cerita pengguna tetapi tidak yakin bagaimana cara memasukkan kode kami ke akun ini.

Kami menggunakan VS dan TFS 2010 dan kami adalah tim 6.

Saat ini kami bercabang untuk fitur-fitur tetapi sedang berusaha mengubah menjadi bercabang untuk scrum.

Kami saat ini tidak menggunakan rak dan tidak benar-benar ingin menerapkan jika ada teknik lain yang tersedia.

Bagaimana Anda menyarankan kami menerapkan tinjauan kode per cerita pengguna?

agile code-reviews scrum

— mcass20
sumber

3

Itu tergantung pada sifat cerita pengguna.

Ini bisa efektif untuk membuat cabang untuk setiap cerita pengguna, kemajuan pada cerita yang berbeda terlihat, mereka dapat diedarkan jika perlu, jika cerita tidak selesai dalam sprint maka kemajuan dapat tetap di cabang untuk sprint berikutnya . Ulasan akhir kemudian dapat dilakukan di akhir cerita pengguna di cabang story use dan digabung jika kode sesuai standar.

Untuk bekerja dengan cara cerita perlu dipoles halus untuk mencegah tugas-tugas penggabungan yang tidak terkelola di akhir sprint. Cerita-cerita kecil akan memungkinkan pembaruan terus-menerus dari cabang dev melalui sprint yang perlu dikembangkan oleh para pengguna kisah-kisah pengguna lainnya (VCM dasar).

Ini memang membuat overhead proses harus membuat dan menggabungkan cabang terus-menerus yang dalam beberapa kasus dapat diselesaikan dengan skrip otomatisasi tetapi tim masih perlu sangat nyaman dengan VCS.

Pada akhir sprint Anda menggabungkan cabang dev Anda ke dalam integrasi / produksi dll.

Saya juga telah bekerja dalam tim di mana setiap orang bekerja di satu cabang dev, setelah menyelesaikan cerita pengguna, kode didorong ke cabang itu untuk ditinjau dan diuji dan jika seseorang mendorong sesuatu yang merusak bangunan dev, mereka harus memasukkan bir tim.

13

Cara paling efektif untuk meninjau kode adalah berdiri, menemukan seseorang, dan meminta mereka untuk datang dan membahas kode yang baru saja Anda kembangkan.

Jangan gunakan alat kecuali Anda tidak dapat menemukan seseorang untuk meninjau kode Anda secara lokal.

Anda dapat menghindari ulasan kode sama sekali dengan memasangkan.

— Ryan Cromwell
sumber

Saya bertanya-tanya kapan seseorang akan menyebutkan pasangan. Antara itu dan pengujian unit Anda mendapatkan banyak ulasan.

— JeffO

Saya membaca ini sebagai "berdiri, tembak seseorang, dan minta mereka datang dan membahas kode yang baru saja Anda kembangkan." Terima kasih telah membuat hari saya.

— Will Morgan

4

Apakah semua orang di tim lokal? Jika demikian, minta saja seseorang untuk datang dan melihat-lihat sebelum kode masuk. Bukan lokal? Nyalakan program berbagi layar favorit Anda dan hubungi seseorang. Saya pribadi sering melakukan ini. Terkadang saya melakukannya hanya untuk mengatakan "Hei, lihat apa yang saya lakukan!"

Saya lebih suka gaya ulasan kode ad-hoc ini daripada gaya di mana seseorang berdiri dan menyajikan kode mereka kepada tim. Ulasan ad-hoc dapat memberi Anda banyak (semua?) Manfaat berpasangan tanpa kecanggungan. Juga, "resensi" Anda lebih cenderung untuk mengajukan pertanyaan dan menyarankan peningkatan dalam pengaturan informal satu lawan satu.

— jamaah
sumber

1

Saya percaya tinjauan kode bukan bagian formal dari SCRUM, namun revisi adalah taktik independen untuk mencapai kualitas dan meningkatkan proyek / tim Anda.

Jadi, Anda akan menggunakan SCRUM (atau metodologi pengembangan gesit lainnya) untuk memastikan / meningkatkan kualitas PROYEK dan tetap pada jadwal. Juga, taktik yang baik adalah melakukan revisi produk (bukan kode) secara independen dari tugas QA / pengujian normal Anda. Jika kegiatan ini dapat dilakukan di depan tim / mitra / klien / audiens Anda akan lebih baik.

Anda harus menggunakan revisi kode (atau spesifik lainnya) terutama untuk meningkatkan TIM Anda, mengharapkan hasil dengan basis jangka menengah / panjang. Ini akan memengaruhi PROYEK Anda, tetapi dalam jangka panjang sebagai produk dari peningkatan TIM Anda.

Jadi, untuk menjawab pertanyaan Anda, saya yakin Anda mencoba terlalu banyak mendorong dari SCRUM, dan Anda sebaiknya mempertimbangkan revisi hanya apa adanya.

— Ron-Damon
sumber

Scrum tidak mengatakan atau menyarankan apa pun mengenai jadwal. Itu memang mengharapkan Anda untuk memberikan nilai secara teratur. Ini juga menyediakan saat-saat di mana Anda dapat memeriksa dan mengadaptasi proses Anda untuk menjadi lebih baik (lebih baik tidak selalu berarti lebih cepat).

— Ryan Cromwell

Ya, Scrum tidak menyatakan membuat jadwal penuh sebagai bagian dari itu. Namun, saya maksudkan "perencanaan" ketika saya merujuk pada jadwal, perencanaan yang berarti bahwa klien Anda mengharapkan beberapa nilai dalam waktu tertentu, sehingga mereka dapat melakukan pertukaran antara nilai uang v / s (jika Anda menganggap bahwa Anda menyediakan layanan pengembangan / pemrograman ).

— Ron-Damon

Dalam hal itu, klien Anda harus memiliki anggaran untuk dibelanjakan dalam waktu tertentu (untuk membayar Anda, misalnya) dan ia mungkin memiliki jadwal untuk dihadiri. Saya bekerja sebagai penyedia layanan, itu sebabnya saya tidak bisa mengabaikan fakta ini.

— Ron-Damon

Selain kontrak, tim Scrum memberikan nilai bukan layanan. Kami mengembangkan / program sebagai sarana untuk memberikan nilai itu.

— Ryan Cromwell

Saya tidak percaya Anda dapat memisahkan istilah "nilai" dan "layanan" teman. Saya juga percaya ini sangat di luar topik sekarang.

— Ron-Damon

0

Bukankah sudah jelas melakukan tinjauan kode sebelum memeriksa kode Anda?

TFS tidak berfungsi seperti GIT, jadi setiap kali Anda memeriksa kode ke cabang atau trunk, kode ini tersedia untuk semua orang.

Ini berarti peninjauan harus dilakukan pada saat check-in sehingga perubahan yang buruk tidak disebarkan ke semua orang yang menyalin pekerjaan.

— Byron Whitlock
sumber

Saya akan berpikir bahwa, secara umum, unit test adalah apa yang akan mencegah perubahan buruk.

— John Saunders

@ John Saunders: Pertimbangkan ulasan kode sebagai jenis lain dari unit test.

— Gilbert Le Blanc

@ Gilbert: Saya bisa melakukan itu, tetapi kemudian saya tidak akan mendapatkan manfaatnya untuk pengujian regresi. Saya lebih suka menghabiskan waktu menulis lebih banyak dan lebih baik unit test.

— John Saunders

@John Saunders, ulasan kode @Gilbert Le Blanc dilakukan oleh pengembang lain, unit test umumnya dilakukan oleh pengembang asli, perspektif baru bisa sangat penting.

Saya beruntung dengan unit test (daftar tes disepakati sebelumnya) dan analisis kode otomatis, mungkin dikombinasikan dengan alat analisis gaya seperti StyleCop. Tapi kemudian, saya tidak sering bekerja dengan pengembang junior.

— John Saunders