Ulasan Kode apakah mereka benar-benar bekerja di Agile yang sebenarnya?


13

Jadi saya mulai bekerja untuk sebuah perusahaan besar, salah satunya dengan 3 huruf dalam nama, dan mereka berusaha untuk menjadi Agile, tetapi memiliki banyak proses, yang saya rasa Agile tidak.

Salah satu yang paling membuat saya berhenti adalah ulasan kode. Pekerjaan terakhir saya adalah dengan startup yang saya akan katakan adalah tim pengembangan Agile yang paling banyak saya lihat, aktif, dan / atau pernah saya dengar.

Lagi pula, argumen saya adalah bahwa Ulasan Kode adalah buang-buang waktu dalam pengembangan berulang atau Agile di mana UX / UI ekstrem / intens (pikirkan kesempurnaan Apple / Steve Jobs). Mungkin seseorang di sini dapat membantu memahami sebelum mereka memecat saya?

Ini adalah proses pengembangan saya dan satu di startup terakhir saya ... sangat Agile.

Kami melakukan pekerjaan fitur awal untuk mengurutkan tugas pengembangan / todos. Kami akan mengejek beberapa versi dan menyajikan kepada pengguna, tim, dan pemasaran untuk mendapatkan umpan balik. Kami kemudian melakukan iterasi mockup lain untuk mendapatkan satu putaran dari para pemangku kepentingan yang sama di atas. Kemudian kami membagi-bagi pekerjaan dan memulai. Kami memiliki tonggak dan tanggal untuk bertemu, tetapi kami terus berusaha. Kami tidak memiliki ulasan kode selama ini. Beberapa kali selama minggu-minggu perkembangan kami, kami mengadakan pertemuan dengan para pemangku kepentingan lagi untuk melihat apakah mereka masih setuju fitur / fungsi / UX / UI masih cocok dan tepat sasaran.

Saat kami mendekati akhir dari siklus iterasi 8 minggu, QA mulai menguji, kemudian beralih ke pengguna alpha, dan akhirnya ke pengguna beta. Tetapi selama pengembang alpha dan beta mempelajari fitur baru dan fitur lama membuat perubahan harian atau jam ke UI untuk meningkatkan UX. Jadi fitur yang sedang dikembangkan rilis ini, mungkin berakhir diubah 3 kali lebih banyak empat minggu terakhir untuk meningkatkan dan menyempurnakannya atau menambahkan beberapa fitur kecil (misalnya membuat komponen sedikit lebih licin atau lebih pintar). Kadang-kadang perubahan mungkin dangkal yang berarti tidak ada operasi CRUD yang diubah atau dimodifikasi, tetapi semua UI hanya berubah.

Jadi dengan jenis proses pengembangan ini, Agile yang ekstrem, bukankah tinjauan kode akan membuang-buang waktu? Berarti jika saya memiliki pengembang lain atau dua meninjau kode saya, tetapi kemudian kode itu berubah 3 kali sebelum keluar dari pintu, karena semua perbaikan UI / UX, apakah kita tidak membuang-buang waktu untuk pertama 3 kali mereka meninjaunya kode karena kode / komponen / UI itu dihapus?

Kami tidak pernah memiliki banyak masalah kualitas dengan proses ini dan ya jika pengembang meninggalkan semua pengetahuan keluar dari pintu, tetapi kami selalu menemukan pengembang pintar untuk mengambil dan mengambil alih.

Dan ya, kami memiliki banyak penguji karena mereka mungkin harus menguji ulang hal 3 atau 4 kali. Juga tolong jangan terpaku untuk bertanya mengapa semua perubahan UI / UX ... itu hanya bagaimana hal-hal dilakukan ... sejak saat itulah mengapa aplikasi memenangkan banyak penghargaan untuk UI / UX dan pengguna akan membunuh untuk aplikasi. Proses pemikirannya adalah jika saya dapat membuat perbaikan bahkan 2% dalam sesuatu karena saya punya jam tambahan maka lakukanlah. Pengguna akan lebih bahagia, yang berarti lebih banyak $ atau pengguna. Dan ya, pengguna kami setuju dengan aplikasi yang berubah terus-menerus karena itulah yang dilakukan sejak hari pertama sehingga mereka tidak melihatnya sebagai buruk atau negatif.

Semoga posting ini tidak terlihat sombong, tapi saya tidak bisa melihat bagaimana Ulasan Kode tidak boros. Mungkin 2% dari semua kode kami dalam kode yang ditinjau memiliki bug. Setiap rilis kami mungkin menemukan 3 bug melalui review kode. Jadi akhirnya menjadi 40 jam ulasan kode per pengembang per rilis (4 x 40 = 160 jam) untuk menemukan 3 hingga 5 bug? Kemungkinannya adalah 50% 3 sampai 5 bug itu akan dijemput oleh QA. Bukankah lebih baik menghabiskan waktu 40 jam per pengembang untuk menambahkan fitur baru atau meningkatkan yang sudah ada?


@DeadMG: Pengalaman Pengguna
Steven A. Lowe

4
@ user25702: proses yang Anda gambarkan tidak terdengar seperti Agile, ini terdengar seperti RUP / spiral. Secara khusus "Beberapa kali selama minggu-minggu perkembangan kami, kami mengadakan pertemuan dengan para pemangku kepentingan lagi untuk melihat apakah mereka masih setuju fitur / fungsi / UX / UI masih cocok dan tepat sasaran." anti-gesit; fitur dibekukan selama iterasi untuk menghindari masalah target bergerak yang terkait dengan pendekatan RUP / spiral. Mengenai pertanyaan nominal Anda, saya tidak melihat banyak nilai dalam ulasan kode di sini jika dan hanya jika Anda yakin bug akan ditemukan oleh QA.
Steven A. Lowe

1
Iterasi 8 minggu tidak gesit dan jelas tidak "gesit ekstrim".
Martin Wickman

Beberapa PM berpikir bahwa iterasi berarti kita memiliki beberapa iterasi pendek di awal dan beberapa iterasi panjang di tengah diikuti oleh iterasi pendek di akhir sesuai kebutuhan. Masalahnya adalah bahwa ini mengacaukan ritme pertempuran pengembangan perangkat lunak dan kemampuan untuk menangkap bug lebih awal. Iterasi 8 minggu akan menjadi salah satu iterasi menengah. Saya setuju bahwa ini tidak gesit.
Berin Loritsch

Jika Anda ingin membantah ulasan kode, maka saya sarankan mengambil beberapa statistik. Dokumentasikan waktu yang dibutuhkan untuk tinjauan kode (dalam total jam kerja), jumlah bug / masalah yang ditemukan di dalamnya, bersama dengan tingkat keparahan masalahnya. Untuk tim saya ternyata kami menghabiskan setidaknya 16 jam kerja per ulasan, ditemukan rata-rata 2-3 bug, yang semuanya bersifat kosmetik. Mudah untuk memperdebatkan metodologi uji-pertama untuk menggantikan ulasan sejawat dalam menghadapi angka-angka itu.
Berin Loritsch

Jawaban:


13

Ada beberapa hal yang dapat dilakukan ulasan kode untuk Anda, dan beberapa hal tidak dapat dilakukan. Argumen yang mendukung ulasan kode:

  • Kepemilikan bersama
  • Temukan bug (QC)
  • Terapkan gaya konsisten (QA)
  • Pendampingan

Banyak proses lincah menangani mereka dengan cara yang berbeda:

  • Kepemilikan Kolektif: semua orang di tim bertanggung jawab atas proyek, yang berarti mata semua orang akan tertuju pada kode pada waktu tertentu.
  • Bebas untuk refactor: ini membutuhkan ulasan kode ke tingkat berikutnya, dan memungkinkan siapa pun di tim untuk melakukan refactoring seperlunya.
  • Tes unit (QC): tes unit lebih efisien dan kurang rentan terhadap kesalahan manusia daripada inspeksi visual. Bahkan, saya belum menemukan cara yang lebih efisien.
  • Pair programming (QA): menangani mentoring dan memberikan saran refactoring awal saat kode ditulis. Ini juga masih merupakan topik yang kontroversial, tetapi saya merasa ini membantu sambil meningkatkan pengembang baru. Ini juga saat yang tepat untuk menegakkan standar pengkodean.

Pada dasarnya ada cara lain untuk mengurus potensi keuntungan yang biasanya Anda lakukan dengan melakukan tinjauan sejawat. Pengalaman pribadi saya dengan peer review adalah bahwa mereka adalah mekanisme yang sangat tidak efisien dan tidak efektif dalam menemukan bug atau cacat desain yang lebih besar. Namun, mereka memiliki tempat di beberapa tim, dan pada proyek-proyek di mana tangkas tidak layak (untuk alasan apa pun), mereka sangat diperlukan.


3
Tampaknya ada beberapa informasi yang salah dalam jawaban saat ini. Kepemilikan bersama tidak berarti "memperhatikan semua kode sepanjang waktu." Refactoring tidak ada hubungannya dengan deteksi cacat. Tes dan inspeksi unit melayani tujuan yang berbeda dan masing-masing dapat mengungkap berbagai jenis cacat yang berbeda (contoh dalam jawaban lain). Pemrograman pasangan, sementara bentuk ulasan, bukan pengganti yang benar untuk inspeksi Fagan misalnya. Pengalaman pribadi Anda tampaknya tidak lazim, terutama menyangkut kesalahan desain - ulasan seperti apa yang Anda lakukan? Bagaimana Anda mengukur efisiensi untuk ulasan?
Michael

1
Waktu melakukan tinjauan vs cacat ditemukan dan tingkat keparahannya. Kami membandingkannya dengan metrik yang sama terhadap pengujian unit. Masalah yang ditemukan selama peninjauan kode hampir selalu terkait dengan pemformatan kode, dan membutuhkan waktu lebih lama untuk melakukan. Waktu yang sama dihabiskan dengan melakukan tes unit menemukan masalah nyata dan tidak perlu lagi mempersiapkan dan melakukannya.
Berin Loritsch

"Kepemilikan Kolektif": Dalam pengalaman saya, ini sering merupakan ilusi: pengulas sering mengalah pada detail kecil dan tidak melihat gambaran besar dalam kode yang ditulis oleh orang lain. Kemudian, ketika harus memodifikasi kode itu, mereka tidak benar-benar memahaminya dan mereka (1) tidak berani mengubahnya, atau (2) mereka menulis ulang secara ekstensif sehingga mereka dapat memahaminya. Pendekatan (2) sering memiliki dua efek samping: (A) mereka memperkenalkan bug, dan (B) pengembang asli tidak lagi memahami kode.
Giorgio

Poin B menunjukkan bahwa seringkali yang terjadi bukanlah kepemilikan kolektif tetapi kepemilikan individu bergeser dari satu pengembang ke pengembang lainnya sepanjang waktu. Dengan cara ini, masing-masing anggota tim secara kasar mengetahui apa yang dilakukan kode dan bagaimana kode itu diatur, tetapi tidak ada yang benar-benar memahaminya secara mendalam. Kepemilikan kode kolektif yang benar akan membutuhkan lebih banyak waktu dan diskusi tentang kode untuk mendapatkan pemahaman yang sama, tetapi seringkali kali ini tidak tersedia.
Giorgio

11

Apakah ulasan kode hanya untuk menemukan bug saja? Anda sepertinya berpikir itu benar dan saya tidak.

Saya berpendapat bahwa ulasan kode dapat lebih tentang kepemilikan kolektif kode, memastikan bahwa pengetahuan ada di banyak kepala, dan mempersiapkan orang lain untuk mewarisi kode yang bisa untuk fitur baru maupun untuk bug. Saya suka ulasan kode sebagai cara untuk melakukan sedikit pemeriksaan dan keseimbangan ke sistem karena Anda tidak pernah tahu kapan seseorang mungkin memiliki gagasan tentang di mana sesuatu dapat ditulis ulang untuk mempertahankan konvensi.


4

Pemrograman pasangan adalah jawaban XP untuk ulasan kode. Intinya, setiap baris kode ditinjau sebagaimana ditulis. Ulasan kode diambil secara ekstrim.


7
Saya akan berdebat kuat dengan ini. Tentu, ini sedang ditinjau oleh dua orang, tetapi orang-orang itu umumnya pada halaman yang sama dengan kode sedang ditulis. Peninjauan kode adalah seseorang dengan keadaan pikiran yang sama sekali berbeda melihat kode Anda dan menemukan "doh! Lupa tentang menangani kasus itu" jenis masalah - XP benar-benar tidak membantu dengan itu.
Billy ONeal

4

Ulasan dan pengujian kode seringkali tidak menangkap bug yang sama, dan bug yang ditangkap oleh review kode cenderung lebih mudah untuk diperbaiki, karena lokasi bug diketahui.

Anda tidak dapat mengetahui apakah kode bebas bug hanya karena lolos pengujian tanpa ada yang dicatat. "Pengujian hanya dapat membuktikan keberadaan bug, bukan ketidakhadiran." (Dijkstra?)

Peninjauan kode juga menjaga gaya kode tetap sama, dan mampu menemukan tempat-tempat di mana kode tidak baik tetapi kebetulan berfungsi untuk saat ini. Menghemat biaya perawatan di jalan.

Juga, tuntutan perusahaan besar dan startup berbeda. Startup biasanya gagal, dan harus bergerak cepat. Perusahaan besar mendapatkan lebih banyak nilai dari melakukan sesuatu dengan benar daripada secepat mungkin. Anda mungkin lebih suka bekerja di startup daripada perusahaan besar, tapi itu bukan alasan untuk mencoba memaksakan strategi startup di mana mereka tidak cocok.


2

Apakah ulasan kode Anda hanya menampilkan perubahan UI / UX? Saya berpendapat bahwa itu bukan review kode, ini adalah tes kegunaan. Ulasan kode lebih banyak tentang memunculkan masalah yang tidak pernah dilihat pengguna / penguji / bisnis /, karena mereka ada dalam kode. Petunjuknya ada di sana dalam nama.

Sekarang saya akan setuju dengan Anda bahwa ada garis yang harus ditarik di suatu tempat. Apakah Anda meninjau 4 iterasi perubahan UI yang sama? Atau apakah Anda melewati 4 iterasi itu, dengan masing-masing berpotensi membuat kode kurang terawat? Saya akan mengatakan mencoba dan mengukur kedua pendekatan dan menemukan keseimbangan yang tepat untuk tim Anda, tetapi jangan tinggalkan ulasan kode sepenuhnya.

Bahkan jika tinjauan kode tidak pernah menemukan masalah, ada manfaat yang jarang Anda sadari sampai tidak ada: setiap bagian kode dilihat oleh dua pengembang, sehingga dua pengembang tahu apa perubahan itu dan apa yang ingin dicapai . Jadi salah satu dari mereka jatuh sakit keesokan harinya dan libur selama seminggu, yang lain dapat mengambil pekerjaan mendesak yang mereka lakukan.


1

Saya cenderung setuju bahwa kepemilikan dan pemasangan kode kolektif bersama dengan TDD dan CI adalah penangkal Agile untuk sesi tinjauan kode formal.

Bahkan di bawah UP / Spiral saya bukan penggemar berat dari langkah proses khusus menjadi "review kode" karena menurut saya jenis masalah yang mungkin ditemukan ditemukan lebih lambat daripada yang mungkin terjadi jika energi yang sama malah diinvestasikan di beberapa muka kolaborasi dan beberapa otomatisasi sederhana.

Saya merasa bahwa karena ada: - beberapa ulasan review tentang desain (biasanya dinyatakan dalam UML setidaknya di papan tulis) berarti masalah desain skala besar atau buruknya penggunaan API, dll. Tertangkap sebelum banyak kode ditulis. - FxCop, CheckStyle, FindBugs (atau serupa) berjalan bersama dengan integrasi berkelanjutan otomatis dibangun untuk menangkap penamaan, gaya, visibilitas, duplikasi kode, dll.

Kami dapat gagal lebih awal dan mendapatkan umpan balik lebih cepat daripada kebiasaan tinjauan kode hilir.

Saya tidak mengatakan itu buang-buang waktu untuk duduk dan melihat basis kode Anda sesekali, tetapi membuat tinjauan kode menjadi langkah gating untuk memanggil sesuatu dilakukan sepertinya itu menciptakan banyak pekerjaan dalam proses yang bisa saja dihindari dengan inspeksi / kolaborasi yang lebih baik di hulu.


0

Salah satu tujuan utama yang saya harapkan dari ulasan kode adalah untuk meningkatkan kemudahan pemeliharaan kode. Ulasan kode harus membantu semua orang menulis kode yang jelas sesuai dengan standar pengkodean yang baik. Sebagian besar kode mendapat banyak perawatan terutama di perusahaan besar. Pengembalian untuk kode yang dapat dipelihara harus dimulai sebelum kode dirilis, dan melanjutkan setelah itu.

Ulasan kode dalam dan dari dirinya sendiri tidak boleh menghasilkan perubahan kode. Jika tinjauan kode menunjukkan bahwa perubahan diperlukan, maka penerapan perubahan akan menghasilkan perubahan dalam kode.

Status kode dapat berubah sebagai hasil peninjauan, tetapi yang seharusnya sebagian besar tidak relevan dengan masalah yang Anda sebutkan.

Jika tinjauan kode menghasilkan beberapa perubahan kode maka ada sesuatu yang rusak dalam proses pengembangan Anda. Mengingat jumlah penguji yang Anda miliki mungkin ada lemparan ke dinding dan biarkan penguji menemukan mentalitas masalahnya.

Hal-hal harus pergi ke penguji dalam kondisi lengkap. Sebanyak mungkin pengujian harus dilakukan secara otomatis, sehingga penguji tidak menguji ulang barang yang sama dari waktu ke waktu.

UI / UX memang membutuhkan waktu pengujian, tetapi memiliki ahli desain / pengembangan di ujung depan harus mengurangi itu. Itu juga membutuhkan wajah di depan layar. Namun, dalam semua aplikasi yang saya gunakan, itu adalah bagian yang relatif kecil dari kode.

Biaya untuk menerapkan perubahan (termasuk perbaikan bug) umumnya naik untuk setiap tahap yang dilaluinya. Menemukan bug dalam pengembangan umumnya lebih murah daripada memperbaikinya setelah pengujian menemukannya.

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.