Praktek Agile: Tinjauan Kode - Gagal meninjau atau mengemukakan masalah?

Pada akhir sprint 2 minggu dan tugas memiliki ulasan kode, dalam ulasan kami menemukan fungsi yang berfungsi, dapat dibaca, tetapi cukup panjang dan memiliki sedikit bau kode. Pekerjaan refactor yang mudah.

Kalau tidak, tugas tersebut sesuai dengan definisi yang dilakukan.

Kami punya dua pilihan.

• Gagal meninjau kode, sehingga tiket tidak ditutup dalam sprint ini, dan kami sedikit mendapat semangat, karena kami tidak dapat melewatkan tiket.
• Refactor adalah pekerjaan kecil, dan akan selesai dalam sprint berikutnya (atau bahkan sebelum dimulai) sebagai cerita setengah poin yang sangat kecil.

Pertanyaan saya adalah: apakah ada masalah atau pertimbangan yang melekat dengan menaikkan tiket di belakang ulasan, bukannya gagal?

Sumber daya yang saya dapat temukan dan telah membaca ulasan kode detail 100% atau tidak sama sekali, biasanya, tetapi saya menemukan itu biasanya tidak realistis.

Adakah masalah atau pertimbangan yang melekat dengan mengangkat tiket di belakang ulasan, bukannya gagal?

Tidak secara inheren. Sebagai contoh, implementasi dari perubahan saat ini mungkin telah menggali masalah yang sudah ada di sana, tetapi tidak diketahui / nampak sampai sekarang. Gagal tiket tidak adil karena Anda akan gagal untuk sesuatu yang tidak terkait dengan tugas yang sebenarnya dijelaskan.

dalam ulasan kami menemukan suatu fungsi

Namun, saya menduga bahwa fungsi di sini adalah sesuatu yang ditambahkan oleh perubahan saat ini. Dalam hal ini, tiket harus gagal karena kode tidak lulus tes bau.

Di mana Anda akan menarik garis, jika tidak di mana Anda sudah menariknya? Anda jelas tidak berpikir kode ini cukup bersih untuk tetap berada dalam basis kode dalam bentuk saat ini; jadi mengapa Anda kemudian mempertimbangkan untuk memberikan tiket?

Gagal meninjau kode, sehingga tiket tidak ditutup dalam sprint ini, dan kami sedikit mendapat semangat, karena kami tidak dapat melewatkan tiket.

Tampaknya bagi saya seolah-olah Anda secara tidak langsung berpendapat bahwa Anda mencoba memberikan tiket ini suatu keuntungan bagi moral tim, daripada menguntungkan kualitas basis kode.

Jika itu masalahnya, maka prioritas Anda beragam. Standar kode bersih tidak boleh diubah hanya karena itu membuat tim lebih bahagia. Kebenaran dan kebersihan kode tidak bergantung pada suasana hati tim.

Refactor adalah pekerjaan kecil, dan akan selesai dalam sprint berikutnya (atau bahkan sebelum dimulai) sebagai cerita setengah poin yang sangat kecil.

Jika implementasi tiket asli menyebabkan bau kode, maka itu harus diatasi di tiket asli. Anda hanya boleh membuat tiket baru jika bau kode tidak dapat secara langsung dikaitkan dengan tiket asli (misalnya, skenario "jerami yang mematahkan punggung unta").

Sumber daya yang saya dapat temukan dan telah membaca ulasan kode detail 100% atau tidak sama sekali, biasanya, tetapi saya menemukan itu biasanya tidak realistis.

Lulus / gagal pada dasarnya adalah keadaan biner , yang secara inheren semua atau tidak sama sekali.

Apa yang Anda maksudkan di sini, saya pikir, adalah lebih dari yang Anda menafsirkan ulasan kode memerlukan kode sempurna atau jika gagal, dan itu tidak terjadi.

Kode tidak boleh rapi, hanya harus memenuhi standar kebersihan yang masuk akal yang digunakan oleh tim / perusahaan Anda. Ketaatan pada standar itu adalah pilihan biner: ia menganut (lulus) atau tidak (gagal).

Berdasarkan uraian masalah Anda, jelas bahwa Anda tidak berpikir bahwa ini mematuhi standar kode yang diharapkan, dan karenanya tidak boleh dilewatkan karena alasan tersembunyi seperti moral tim.

Kalau tidak, tugas tersebut sesuai dengan definisi yang dilakukan.

Jika "itu menyelesaikan pekerjaan" adalah tolok ukur terbaik untuk kualitas kode, maka kita tidak perlu menciptakan prinsip kode bersih dan praktik yang baik untuk memulai - kompiler dan pengujian unit akan menjadi proses peninjauan otomatis kami dan Anda tidak perlu ulasan kode atau argumen gaya.

Pada akhir sprint 2 minggu dan sebuah tugas memiliki ulasan kode [...] Pekerjaan refactor yang mudah.

Mengapa itu muncul di akhir sprint? Peninjauan kode harus terjadi segera setelah Anda berpikir kode tersebut selesai (atau bahkan sebelumnya). Anda harus memeriksa definisi Anda tentang selesai dengan setiap cerita yang Anda selesaikan.

Jika Anda mendapati diri Anda menyelesaikan cerita sesaat sebelum ulasan demo / sprint Anda sehingga Anda tidak dapat melakukan tugas yang "kecil", maka Anda perlu lebih baik dalam memperkirakan pekerjaan Anda. Ya, cerita itu belum selesai. Bukan karena ulasan kode, tetapi karena Anda tidak berencana untuk memasukkan perubahan dari tinjauan kode. Itu seperti memperkirakan "pengujian" untuk mengambil waktu nol, karena "jika Anda memprogramnya dengan benar, itu hanya akan berfungsi, kan?". Itu bukan cara kerjanya. Pengujian akan menemukan kesalahan dan ulasan kode akan menemukan hal-hal yang berubah. Jika tidak, itu akan membuang-buang waktu.

Jadi untuk meringkasnya: ya, DoD adalah biner. Lulus atau gagal. Peninjauan kode bukan biner, seharusnya lebih seperti tugas yang sedang berlangsung. Anda tidak bisa gagal . Ini sebuah proses dan pada akhirnya selesai. Tetapi jika Anda tidak merencanakan dengan baik, Anda tidak akan sampai pada tahap "selesai" dan terjebak dalam wilayah "tidak selesai" di ujung sprint. Itu tidak baik untuk moral, tetapi Anda perlu memperhitungkannya dalam perencanaan.

Sederhana: Anda meninjau perubahannya . Anda tidak meninjau kondisi program sebaliknya. Jika saya memperbaiki bug di fungsi 3.000 baris, maka Anda memeriksa bahwa perubahan saya memperbaiki bug, dan hanya itu. Dan jika perubahan saya memperbaiki bug, Anda menerima perubahan itu.

Jika Anda pikir fungsi terlalu panjang, maka Anda memasukkan permintaan perubahan untuk membuat fungsi lebih pendek, atau membaginya, setelah perubahan saya diterima, dan permintaan perubahan itu kemudian dapat diprioritaskan sesuai dengan kepentingannya. Jika keputusan dibuat bahwa tim memiliki hal-hal yang lebih penting untuk dilakukan, maka itu akan ditangani kemudian.

Akan konyol jika Anda bisa memutuskan prioritas pengembangan selama tinjauan kode, dan menolak perubahan saya karena alasan itu akan menjadi upaya untuk memutuskan prioritas pembangunan.

Singkatnya, benar-benar dapat diterima untuk menerima perubahan kode dan segera menaikkan tiket berdasarkan hal-hal yang Anda lihat saat meninjau perubahan. Dalam beberapa kasus Anda bahkan akan melakukan hal ini jika perubahan itu sendiri menyebabkan masalah: Jika lebih penting untuk memiliki perubahan sekarang daripada untuk memperbaiki masalah. Misalnya jika orang lain diblokir, menunggu perubahan, maka Anda ingin membuka blokir mereka sementara kode dapat ditingkatkan.

Gagal meninjau kode, sehingga tiket tidak ditutup dalam sprint ini, dan kami sedikit mendapat semangat, karena kami tidak dapat melewatkan tiket.

Ini tampaknya menjadi masalah.
Secara teori Anda tahu apa yang harus Anda lakukan, tetapi mendekati tenggat waktu sehingga Anda tidak ingin melakukan apa yang Anda tahu harus Anda lakukan.

Jawabannya sederhana: Lakukan apa pun yang akan Anda lakukan jika Anda mendapat kode yang sama untuk ulasan kode pada hari pertama sprint. Jika itu dapat diterima maka seharusnya sekarang. Jika tidak, itu tidak akan sekarang.

Bagian besar dari proses ini adalah memutuskan apa yang dilakukan berarti dan tetap berpegang pada senjata Anda. Ini juga berarti tidak melakukan terlalu banyak komitmen dan menyelesaikan ulasan sejawat Anda pada waktunya untuk membiarkan pengujian memastikan pekerjaan juga selesai secara fungsional.

Ketika datang ke masalah ulasan kode, ada beberapa cara Anda bisa mengatasinya, dan pilihan yang tepat tergantung pada beberapa faktor.

• Anda bisa membersihkan kode sendiri dan biarkan orang itu tahu apa yang Anda lakukan. Memberikan beberapa peluang pendampingan, tetapi ini harus menjadi hal yang cukup sederhana yang dapat dilakukan dalam beberapa menit.
• Anda dapat menendang balik dengan komentar tentang apa yang salah. Jika penanganan kesalahan dilakukan dengan buruk, atau pengembang terus mengulangi kesalahan yang sama, ini dapat dibenarkan.
• Anda dapat membuat tiket dan menimbulkan hutang teknis. Tiket ada di sana untuk memastikan Anda membayarnya nanti. Mungkin Anda berada dalam krisis waktu dan dalam proses meninjau perubahan Anda melihat masalah yang lebih besar tidak secara langsung terkait dengan perubahan tersebut.

Intinya adalah bahwa ketika Anda selesai dengan pekerjaan Anda harus selesai dengan itu. Jika ada masalah yang lebih besar dari apa yang dikerjakan pengembang, angkat bendera dan lanjutkan. Tetapi Anda tidak harus berada dalam posisi di mana ada jam sebelum akhir sprint dan Anda baru saja mendapatkan ulasan sejawat. Baunya seperti terlalu memaksakan sumber daya Anda, atau menunda-nunda ulasan sejawat. (bau proses).

Tidak ada masalah inheren dengan masalah peninjauan kode yang diprioritaskan, tetapi sepertinya masalah utama yang perlu Anda setujui, sebagai sebuah tim, adalah:

1. Apa tujuan ulasan kode Anda?
2. Bagaimana hasil tinjauan kode terkait dengan Definisi Selesai untuk item kerja?
3. Jika tinjauan kode berlaku sebagai tes gating, masalah apa yang dianggap sebagai 'pemblokir'?

Ini semua bermuara pada apa yang disepakati tim sebagai definisi Selesai. Jika meneruskan tinjauan kode dengan Zero Issues adalah definisi yang dilakukan untuk item pekerjaan, maka Anda tidak dapat menutup item yang belum memenuhi persyaratan ini.

Itu sama seperti jika selama pengujian unit suatu pengujian unit gagal. Anda akan memperbaiki bug, tidak mengabaikan tes unit, jika lulus tes unit adalah persyaratan untuk Selesai.

Jika tim belum menyetujui ulasan kode sebagai definisi Selesai, maka ulasan kode Anda bukan tes penerimaan gating dari item pekerjaan. Mereka adalah kegiatan tim yang merupakan bagian dari proses backlog Anda untuk mencari pekerjaan tambahan yang mungkin diperlukan. Dalam hal itu, setiap masalah yang Anda temukan tidak terkait dengan persyaratan item pekerjaan asli dan merupakan item kerja baru untuk diprioritaskan oleh tim.

Sebagai contoh, itu bisa sepenuhnya diterima bagi sebuah tim untuk memprioritaskan memperbaiki kesalahan pengetikan pada beberapa nama variabel karena tidak memengaruhi fungsionalitas bisnis yang telah disampaikan, meskipun tim benar-benar benci melihat nama variabel "myObkect".

Jawaban yang lebih tinggi di sini sangat baik; ini membahas sudut refactoring.

Dalam kebanyakan kasus, sebagian besar pekerjaan ketika refactoring memahami kode yang ada; mengubahnya setelah itu umumnya merupakan bagian kecil dari pekerjaan karena satu dari dua alasan:

1. Jika hanya membuat kode lebih jelas dan / atau ringkas, perubahan yang diperlukan jelas. Seringkali Anda mendapatkan pemahaman Anda tentang kode dengan mencoba perubahan yang tampak lebih bersih dan melihat apakah mereka benar-benar berfungsi, atau jika mereka melewatkan beberapa kehalusan dalam kode yang lebih kompleks.

2. Anda sudah memikirkan desain atau struktur tertentu yang Anda butuhkan untuk membuat membangun fitur baru lebih mudah. Dalam hal itu, pekerjaan untuk mengembangkan desain itu adalah bagian dari cerita yang menghasilkan kebutuhan akannya; itu terlepas dari Anda yang perlu melakukan refactoring untuk sampai ke desain itu.

Mempelajari dan memahami kode yang ada adalah jumlah pekerjaan yang adil untuk manfaat non-permanen (satu bulan dari sekarang seseorang mungkin telah lupa banyak tentang kode jika mereka tidak terus membaca atau bekerja dengannya selama waktu itu), dan karenanya tidak masuk akal untuk melakukan ini kecuali pada bidang kode yang menyebabkan Anda masalah atau bahwa Anda berencana untuk berubah dalam waktu dekat. Pada gilirannya, karena ini adalah pekerjaan utama refactoring, Anda tidak boleh melakukan refactoring pada kode kecuali jika saat ini menyebabkan Anda masalah atau Anda berencana untuk mengubahnya dalam waktu dekat.

Tetapi ada satu pengecualian untuk itu: jika seseorang saat ini memiliki pemahaman yang baik tentang kode yang akan bocor dari waktu ke waktu, menggunakan pemahaman itu untuk membuat kode lebih jelas dan lebih cepat dipahami kemudian bisa menjadi investasi yang baik. Itulah situasi seseorang yang baru saja selesai mengembangkan sebuah cerita.

Refactor adalah pekerjaan kecil, dan akan selesai dalam sprint berikutnya (atau bahkan sebelum dimulai) sebagai cerita setengah poin yang sangat kecil.

Dalam hal ini Anda berpikir untuk membuat cerita terpisah untuk refactoring adalah tanda peringatan di beberapa bidang:

1. Anda tidak memikirkan refactoring sebagai bagian dari pengkodean tetapi sebagai operasi terpisah, yang pada gilirannya membuatnya cenderung jatuh di bawah tekanan.

2. Anda sedang mengembangkan kode yang akan lebih sulit untuk dipahami saat seseorang perlu bekerja dengannya, membuat cerita lebih lama.

3. Anda mungkin membuang-buang waktu dan energi untuk melakukan refactoring hal-hal di mana Anda tidak mendapatkan banyak manfaat. (Jika perubahan terjadi jauh di kemudian hari, seseorang masih harus memahami kembali kode itu, bagaimanapun, itu lebih efisien dikombinasikan dengan pekerjaan refactoring. Jika perubahan tidak terjadi kemudian, refactoring tidak melayani apa pun tujuan sama sekali, kecuali mungkin yang estetis.)

Jadi jawabannya di sini adalah untuk gagal item untuk memperjelas bahwa sesuatu dalam proses Anda gagal (dalam hal ini, itu pengembang atau tim tidak mengalokasikan waktu untuk meninjau dan menerapkan perubahan yang keluar dari ulasan) dan membuat pengembang segera melanjutkan pekerjaan pada item.

Saat Anda memperkirakan untuk iterasi berikutnya, perkirakan kembali cerita yang ada sebagai jumlah pekerjaan yang tersisa untuk membuatnya lulus review dan menambahkannya ke iterasi Anda berikutnya, tetapi pertahankan estimasi dari iterasi sebelumnya. Ketika cerita selesai pada akhir iterasi berikutnya, tetapkan jumlah total historis pekerjaan ke jumlah perkiraan pertama dan kedua sehingga Anda tahu berapa banyak perkiraan pekerjaan yang benar-benar dimasukkan ke dalamnya. Ini akan membantu menghasilkan perkiraan yang lebih akurat dari cerita yang sama di masa depan pada kondisi proses Anda saat ini. (Yaitu, jangan berasumsi bahwa perkiraan Anda yang sebenarnya tidak akan terjadi lagi; anggap itu akan terjadi lagi sampai Anda berhasil menyelesaikan cerita serupa sambil mengurangi pekerjaan.)

Saya terkejut dengan kurangnya tanggapan dalam jawaban dan komentar terhadap gagasan "gagal" review kode, karena itu bukan konsep yang saya, secara pribadi, kenal. Saya juga tidak akan merasa nyaman dengan konsep itu atau siapa pun dalam tim saya menggunakan terminologi itu.

Pertanyaan Anda secara eksplisit menyerukan "praktik tangkas," jadi mari kita tinjau kembali manifesto tangkas (penekanan milik saya):

Kami menemukan cara yang lebih baik untuk mengembangkan perangkat lunak dengan melakukannya dan membantu orang lain melakukannya. Melalui pekerjaan ini, kami menghargai:

• Individu dan interaksi atas proses dan alat
• Bekerja dengan perangkat lunak melalui dokumentasi yang komprehensif
• Kolaborasi pelanggan atas negosiasi kontrak
• Menanggapi perubahan setelah mengikuti rencana

Artinya, sementara ada nilai di item di sebelah kanan, kami lebih menghargai item di sebelah kiri.

Bicaralah dengan tim Anda. Diskusikan kode yang dimaksud. Nilai biaya dan manfaatnya dan putuskan - sebagai kelompok ahli yang kohesif - apakah akan memperbaiki kode ini sekarang, nanti, atau tidak pernah.

Mulai berkolaborasi. Berhenti gagal ulasan kode.

dalam ulasan kami menemukan fungsi yang berfungsi, dapat dibaca, tetapi cukup panjang dan memiliki beberapa bau kode ...

Apakah ada masalah atau pertimbangan yang melekat dengan menaikkan tiket di belakang ulasan, bukannya gagal?

Tidak masalah apa pun (menurut pendapat tim saya). Saya berasumsi bahwa kode memenuhi kriteria penerimaan yang dinyatakan dalam tiket (yaitu, itu berfungsi). Buat item backlog untuk mengatasi panjangnya, dan kode apa pun berbau, dan prioritaskan sama seperti tiket lainnya. Jika benar-benar kecil, maka hanya memprioritaskannya tinggi untuk sprint berikutnya.

Salah satu ucapan yang kami miliki adalah "Pilih peningkatan progresif daripada kesempurnaan yang tertunda".

Kami memiliki proses yang sangat lancar, dan membangun sejumlah fitur 'bukti konsep' yang cukup baik (1 atau 2 per sprint) yang berhasil melalui dev dan pengujian tetapi tidak pernah melewati tinjauan pemangku kepentingan internal (hmm, bisakah kita melakukan ini sebagai gantinya ?), alpha, atau beta ... sebagian bertahan, sebagian tidak.

Pada proyek saat ini, saya kehilangan jejak berapa kali kami membangun fitur tertentu, membawanya ke tangan para pemangku kepentingan, dan satu atau dua sprint kemudian, benar-benar menghapusnya karena arah produk telah berubah, atau persyaratan yang disebabkan penyusunan ulang lengkap tentang bagaimana fitur tersebut harus diimplementasikan. Tugas 'penyempurnaan' yang tersisa untuk fitur yang dihapus, atau yang tidak sesuai dengan persyaratan baru akan dihapus serta bagian dari perawatan jaminan simpanan.

Menurut saya ada dua cara untuk melihat masalah ini:

1. Cara akademik
2. Cara dunia nyata

Berbicara secara akademis, sebagian besar proses peninjauan kode ada untuk gagal penyebaran PBI (item jaminan simpanan produk) ketika standar kualitas kode tidak terpenuhi.

Namun, tidak ada seorang pun di dunia nyata yang tangkas mengikuti T karena untuk satu (karena banyak alasan), industri yang berbeda memiliki persyaratan yang berbeda. Dengan demikian, memperbaiki kode sekarang atau mengambil utang teknis (kemungkinan besar Anda akan membuat PBI baru) harus diputuskan berdasarkan kasus. Jika itu akan mengkompromikan sprint atau rilis atau memperkenalkan sejumlah risiko yang tidak masuk akal, para pemangku kepentingan bisnis harus dilibatkan dalam keputusan tersebut.

Tidak juga . Jika gagal tinjauan kode maka tugas tidak selesai. Tapi Anda tidak bisa gagal tinjauan kode pada pendapat pribadi. Kode melewati; beralih ke tugas berikutnya.

Itu harus menjadi panggilan yang mudah, dan fakta bahwa itu tidak menunjukkan bahwa Anda tidak memiliki aturan tertulis yang cukup jelas untuk ulasan kode.

1. "Fungsinya cukup panjang". Tuliskan: Fungsinya harus kurang dari garis X (saya tidak menyarankan aturan tentang panjang fungsi adalah hal yang baik).

2. "Ada beberapa bau kode". Tulis: fungsi publik harus memiliki unit test untuk fungsionalitas dan kinerja, baik CPU dan penggunaan memori harus di bawah batas x dan y.

Jika Anda tidak dapat menghitung aturan untuk melewatkan tinjauan kode maka Anda akan mendapatkan kasus ini tentang apa yang pada dasarnya 'kode yang tidak Anda sukai'.

Jika Anda gagal 'kode yang tidak Anda sukai'? Saya akan mengatakan tidak. Anda secara alami akan mulai lulus / gagal berdasarkan aspek non-kode: Apakah Anda menyukai orang itu? Apakah mereka berdebat keras untuk kasus mereka atau hanya melakukan apa yang diperintahkan? Apakah mereka lulus kode Anda ketika mereka meninjau Anda?

Anda juga menambahkan langkah yang tidak dapat diverifikasi untuk proses estimasi. Saya memperkirakan tugas berdasarkan pada bagaimana saya pikir itu harus diprogram, tetapi kemudian pada akhirnya saya harus mengubah gaya pengkodean.

Berapa lama itu akan ditambahkan? Akankah peninjau yang sama melakukan peninjauan kode berikutnya dan setuju dengan peninjau pertama atau akankah mereka menemukan perubahan tambahan? Bagaimana jika saya tidak setuju dengan perubahan itu dan menunda melakukannya sementara saya mencari pendapat kedua atau membantah kasus ini?

Jika Anda ingin tugas diselesaikan dengan cepat, Anda harus membuatnya sespesifik mungkin. Menambahkan gerbang kualitas yang tidak jelas tidak akan membantu produktivitas Anda.

Re: Tidak mungkin untuk menuliskan aturan !!

Tidak terlalu sulit. Maksud Anda "Saya tidak bisa mengungkapkan apa yang saya maksud dengan kode 'baik'" . Setelah Anda mengetahuinya, Anda bisa melihat itu jelas masalah SDM jika Anda mulai mengatakan pekerjaan seseorang tidak tepat, tetapi Anda tidak bisa mengatakan mengapa.

Tuliskan aturan yang Anda bisa dan diskusikan sambil minum bir tentang apa yang membuat kode 'baik'.