Apakah masuk akal untuk bersikeras mereproduksi setiap cacat sebelum mendiagnosis dan memperbaikinya?

Saya bekerja untuk perusahaan produk perangkat lunak. Kami memiliki pelanggan perusahaan besar yang menerapkan produk kami dan kami memberikan dukungan kepada mereka. Misalnya, jika ada cacat, kami menyediakan tambalan, dll. Dengan kata lain, ini adalah pengaturan yang cukup umum.

Baru-baru ini, sebuah tiket dikeluarkan dan ditugaskan kepada saya mengenai pengecualian yang ditemukan oleh seorang pelanggan dalam file log yang ada hubungannya dengan akses database bersamaan dalam implementasi produk kami secara berkelompok. Jadi konfigurasi khusus pelanggan ini mungkin sangat penting dalam terjadinya bug ini. Yang kami dapatkan dari pelanggan hanyalah file log mereka.

Pendekatan yang saya usulkan untuk tim saya adalah mencoba mereproduksi bug dalam pengaturan konfigurasi yang mirip dengan pelanggan dan mendapatkan log yang sebanding. Namun, mereka tidak setuju dengan pendekatan saya yang mengatakan bahwa saya tidak perlu mereproduksi bug karena terlalu memakan waktu dan akan mensimulasikan server cluster pada VM. Tim saya menyarankan agar saya "mengikuti kode" untuk melihat di mana kode thread dan / atau transaksi-tidak aman berada dan melakukan perubahan dari pengembangan lokal yang sederhana, yang bukan implementasi cluster seperti lingkungan dari mana terjadinya bug berasal.

Bagi saya, mengerjakan cetak biru abstrak (kode program) daripada manifestasi nyata yang terlihat (reproduksi runtime) tampaknya sulit, jadi saya ingin mengajukan pertanyaan umum:

Apakah masuk akal untuk bersikeras mereproduksi setiap cacat dan men-debug sebelum mendiagnosis dan memperbaikinya?

Atau:

Jika saya seorang pengembang senior, haruskah saya dapat membaca kode multithread dan membuat gambaran mental tentang apa yang dilakukannya dalam semua skenario use case daripada harus menjalankan aplikasi, menguji skenario use case yang berbeda secara langsung, dan melangkah melalui kode baris demi baris? Atau apakah saya pengembang yang buruk karena menuntut lingkungan kerja seperti itu?

Apakah debugging untuk banci?

Menurut pendapat saya, setiap perbaikan yang diajukan sebagai tanggapan terhadap tiket insiden harus diuji dalam lingkungan yang disimulasikan sedekat mungkin dengan lingkungan asli. Bagaimana lagi Anda bisa tahu bahwa itu benar-benar akan menyelesaikan masalah? Ini seperti melepaskan model kendaraan baru tanpa tabrakan mengujinya dengan boneka untuk menunjukkan bahwa kantung udara benar-benar berfungsi.

Terakhir tetapi tidak kalah pentingnya, jika Anda setuju dengan saya:

Bagaimana saya harus berbicara dengan tim saya untuk meyakinkan mereka bahwa pendekatan saya masuk akal, konservatif dan lebih tahan peluru?

Apakah masuk akal untuk bersikeras mereproduksi setiap cacat dan men-debug sebelum mendiagnosis dan memperbaikinya?

Anda harus memberikan usaha terbaik Anda. Saya tahu bahwa kadang-kadang ada kondisi dan lingkungan yang begitu rumit sehingga tidak dapat direproduksi dengan tepat , tetapi Anda harus mencoba jika Anda bisa.

Jika Anda tidak pernah mereproduksi bug dan melihatnya sendiri, bagaimana Anda bisa 100% yakin bahwa Anda benar-benar memperbaikinya? Mungkin perbaikan yang Anda ajukan memperkenalkan beberapa bug halus lainnya yang tidak akan bermanifestasi kecuali Anda benar-benar mencoba mereproduksi cacat aslinya.

Jika saya seorang pengembang senior, haruskah saya dapat membaca kode (multithreaded) dan membuat gambaran mental tentang apa yang dilakukannya dalam semua skenario use case daripada harus menjalankan aplikasi, menguji skenario use case yang berbeda secara langsung, dan melangkah melalui kode baris demi baris? Atau apakah saya pengembang yang buruk karena menuntut lingkungan kerja seperti itu? Apakah debugging untuk banci?

Saya tidak akan mempercayai seseorang yang menjalankan kode "di kepala mereka", jika itu satu - satunya pendekatan mereka. Ini tempat yang bagus untuk memulai . Mereproduksi bug, dan memperbaikinya dan kemudian menunjukkan bahwa solusi mencegah bug dari terulang kembali - di sanalah seharusnya diakhiri .

Bagaimana saya harus berbicara dengan tim saya untuk meyakinkan mereka bahwa pendekatan saya masuk akal, konservatif dan lebih tahan peluru?

Karena jika mereka tidak pernah mereproduksi bug, mereka tidak dapat mengetahui dengan pasti bahwa bug itu sudah diperbaiki. Dan jika pelanggan kembali dan mengeluh bahwa bug itu masih ada, itu bukan Good Thing. Lagi pula, mereka membayar Anda $$$ besar (saya berasumsi) untuk mengatasi masalah ini.

Jika Anda gagal untuk memperbaiki masalah dengan benar, Anda telah melanggar kepercayaan dengan pelanggan (sampai taraf tertentu) dan jika ada pesaing di pasar Anda, mereka mungkin tidak tetap menjadi pelanggan Anda.

Bagaimana mereka bermaksud memverifikasi bahwa bug tersebut diperbaiki? Apakah mereka ingin mengirimkan kode yang belum diuji kepada pengguna dan membiarkan mereka mengetahuinya? Pengaturan tes apa pun yang tidak pernah ditampilkan untuk mereproduksi kesalahan tidak dapat diandalkan untuk menunjukkan tidak adanya kesalahan. Anda tentu tidak perlu mereproduksi seluruh lingkungan klien, tetapi Anda memang perlu cukup untuk mereproduksi kesalahan.

Saya rasa tidak masuk akal untuk mencoba mereproduksi setiap bug sebelum memperbaikinya. Namun jika Anda mencoba untuk mereproduksi dan Anda tidak bisa maka itu menjadi lebih dari keputusan bisnis tentang apakah tambalan adalah ide yang baik atau tidak.

Idealnya, Anda ingin dapat mereproduksi setiap bug sehingga, paling tidak, Anda dapat menguji apakah itu sudah diperbaiki.

Tapi ... Itu mungkin tidak selalu layak atau bahkan mungkin secara fisik. Terutama dengan perangkat lunak jenis 'perusahaan' di mana setiap instalasi unik. Ada juga evaluasi biaya / manfaat. Beberapa jam melihat-lihat kode dan membuat beberapa tebakan berpendidikan tentang masalah non-kritis mungkin jauh lebih murah daripada memiliki tim dukungan teknis yang menghabiskan waktu berminggu-minggu untuk mencoba mengatur dan menduplikasi lingkungan pelanggan dengan harapan dapat menggandakan masalah. Kembali ketika saya bekerja di dunia 'Enterprise', kami sering hanya menerbangkan coders dan meminta mereka memperbaiki bug di situs, karena tidak ada cara untuk menduplikasi pengaturan pelanggan.

Jadi, duplikat ketika Anda bisa, tetapi jika Anda tidak bisa, maka manfaatkan pengetahuan Anda tentang sistem, dan cobalah untuk mengidentifikasi pelakunya dalam kode.

Saya tidak berpikir Anda harus membuat kesalahan mereproduksi persyaratan untuk melihat bug. Ada, seperti yang telah Anda sebutkan, beberapa cara untuk men-debug masalah - dan Anda harus menggunakan semuanya. Anda harus menganggap diri Anda beruntung karena mereka dapat memberi Anda file log! Jika Anda atau seseorang di perusahaan Anda dapat mereproduksi bug, hebat! Jika tidak, Anda masih harus mencoba mengurai log dan menemukan keadaan di mana kesalahan terjadi. Dimungkinkan, seperti yang disarankan oleh kolega Anda, untuk membaca kode, mencari tahu kondisi bug apa yang bisa terjadi, kemudian mencoba membuat ulang skenario sendiri.

Namun, jangan lepaskan perbaikan yang sebenarnya belum teruji. Setiap perubahan yang Anda lakukan harus melalui standar dev, pengujian QA, dan pengujian integrasi rutin. Mungkin terbukti sulit untuk menguji - Anda menyebutkan kode multithreaded, yang terkenal sulit untuk di-debug. Di sinilah saya setuju dengan pendekatan Anda untuk membuat konfigurasi pengujian atau lingkungan. Jika Anda menemukan masalah dalam kode, Anda akan merasa lebih mudah untuk menciptakan lingkungan, mereproduksi masalah, dan menguji perbaikannya.

Bagi saya, ini bukan masalah debugging dan lebih merupakan masalah layanan pelanggan. Anda telah menerima laporan bug dari pelanggan; Anda memiliki tanggung jawab untuk melakukan uji tuntas untuk menemukan masalah mereka dan memperbaikinya.

Menurut pendapat saya ... sebagai pembuat keputusan, Anda harus dapat membenarkan posisi Anda. Jika tujuan dari departemen dukungan lini ke-3 adalah untuk memperbaiki bug dalam jangka waktu terpendek dengan upaya yang dapat diterima dari klien, maka pendekatan apa pun harus sesuai dengan tujuan itu. Lebih jauh, jika pendekatan tersebut dapat dibuktikan memberikan hasil yang diharapkan tercepat, maka seharusnya tidak ada masalah meyakinkan tim.

Setelah bekerja dalam dukungan, saya selalu berharap klien dapat memberikan beberapa "skrip" tindakan yang mereka lakukan untuk secara konsisten mereproduksi bug dan jika tidak secara konsisten calon contoh yang telah menghasilkan bug.

Jika saya baru mengenal sistem dan tidak memiliki latar belakang dengan kode tersebut, langkah pertama saya adalah mencoba mengidentifikasi sumber kesalahan yang mungkin terjadi. Mungkin penebangan tidak cukup untuk mengidentifikasi kode kandidat. Tergantung pada klien, saya mungkin cenderung memberi mereka versi debug agar mereka dapat memberi Anda kembali file log yang memberikan petunjuk lebih lanjut tentang posisi kode yang menyinggung.

Jika saya dapat dengan cepat mengidentifikasi blok kode maka pemetaan visual dari aliran mungkin cukup untuk menemukan kode. Jika tidak, maka simulasi berbasis unit test mungkin cukup. Mungkin menyiapkan lingkungan replikasi klien membutuhkan waktu lebih sedikit, terutama jika ada banyak replikasi masalah.

Saya pikir Anda mungkin menemukan bahwa pendekatan Anda harus merupakan kombinasi dari solusi yang diusulkan dan mengetahui kapan harus berhenti dan beralih ke yang berikutnya adalah kunci untuk menyelesaikan pekerjaan dengan efisien.

Saya cukup yakin bahwa tim akan mendukung gagasan bahwa jika ada kemungkinan solusi mereka akan menemukan bug lebih cepat, kemudian memberi mereka kerangka waktu yang sesuai untuk membuktikan bahwa tidak akan berdampak terlalu banyak pada waktu yang diperlukan untuk memperbaiki bug mana pun rute yang Anda ambil.

Apakah masuk akal untuk bersikeras mereproduksi setiap cacat dan men-debug sebelum mendiagnosis dan memperbaikinya?

Saya katakan ya, dengan beberapa peringatan.

• Saya pikir tidak apa-apa untuk membaca kode dan mencoba mencari tempat yang terlihat bermasalah. Buat tambalan dan kirim itu ke klien untuk melihat apakah itu menyelesaikan masalah. Jika pendekatan ini terus gagal, maka Anda mungkin perlu menyelidiki opsi lain. Hanya ingat bahwa sementara Anda mungkin menangani suatu bug itu tidak mungkin dengan bug yang dilaporkan.
• Jika Anda tidak dapat mereproduksinya dengan alasan, dan Anda tidak dapat menemukan bendera merah dalam kode, maka itu mungkin memerlukan koordinasi yang lebih dekat dengan pelanggan. Saya telah terbang ke situs pelanggan sebelum melakukan debugging situs. Ini bukan lingkungan pengembang terbaik, tetapi kadang-kadang jika masalahnya adalah lingkungan, maka menemukan penyebab pasti akan menjadi paling mudah ketika Anda dapat memperbanyaknya secara konsisten.

Saya sudah berada di sisi pelanggan dalam skenario ini. Saya bekerja di kantor pemerintah AS yang menggunakan cluster database Oracle yang sangat besar (beberapa terabyte data dan memproses jutaan catatan sehari).

Kami mengalami masalah aneh yang sangat mudah bagi kami untuk berkembang biak. Kami melaporkan bug ke Oracle, dan bolak-balik dengan mereka selama berminggu-minggu, mengirimkan mereka log. Mereka mengatakan mereka tidak dapat mereproduksi masalah, tetapi mengirimi kami beberapa tambalan yang diharapkan dapat mengatasi masalah tersebut. Tak satu pun dari mereka melakukannya.

Mereka akhirnya menerbangkan beberapa pengembang ke lokasi kami untuk men-debug masalah di situs. Dan saat itulah akar penyebab bug ditemukan dan tambalan kemudian mengatasi masalah dengan benar.

Jika Anda tidak positif tentang masalahnya, Anda tidak bisa positif tentang solusinya. Mengetahui cara mereproduksi masalah dengan andal dalam setidaknya satu situasi kasus uji memungkinkan Anda membuktikan bahwa Anda tahu cara menyebabkan kesalahan, dan karenanya juga memungkinkan Anda untuk membuktikan di sisi lain bahwa masalah tersebut telah dipecahkan, karena kekurangan berikutnya kesalahan dalam test case yang sama setelah menerapkan perbaikan.

Yang mengatakan, kondisi ras, masalah konkurensi, dan bug "non-deterministik" lainnya adalah yang paling sulit bagi pengembang untuk dijabarkan dengan cara ini, karena jarang terjadi, pada sistem dengan beban yang lebih tinggi dan kompleksitas yang lebih banyak daripada salinan pengembang mana pun. program, dan mereka menghilang ketika tugas dijalankan kembali pada sistem yang sama di lain waktu.

Lebih sering daripada tidak, apa yang awalnya terlihat seperti bug acak akhirnya memiliki penyebab deterministik yang menghasilkan bug yang secara reproduktif dapat direproduksi begitu Anda tahu caranya. Orang-orang yang menentang ini, Heisenbugs sejati (bug yang kelihatannya acak yang menghilang ketika mencoba mengujinya di lingkungan yang steril dan terpantau), adalah 99,9% terkait waktu, dan begitu Anda memahami itu, jalan Anda ke depan menjadi lebih jelas; memindai hal-hal yang bisa gagal jika ada hal lain yang mendapatkan kata-kata buruk selama eksekusi kode, dan ketika Anda menemukan kerentanan seperti itu, cobalah untuk mengeksploitasinya dalam tes untuk melihat apakah itu menunjukkan perilaku yang Anda coba untuk reproduksi.

Sejumlah besar inspeksi kode mendalam biasanya diperlukan dalam situasi ini; Anda harus melihat kode tersebut, meninggalkan gagasan yang sudah terbentuk sebelumnya tentang bagaimana kode itu seharusnya berperilaku, dan bayangkan skenario di mana ia bisa gagal dalam cara yang diamati oleh klien Anda. Untuk setiap skenario, cobalah untuk mengembangkan tes yang dapat dijalankan secara efisien dalam lingkungan pengujian otomatis Anda saat ini (yaitu, tanpa memerlukan tumpukan VM baru hanya untuk tes yang satu ini), yang akan membuktikan atau membantah bahwa kode berperilaku seperti yang Anda harapkan ( yang, tergantung pada apa yang Anda harapkan, akan membuktikan atau menyangkal bahwa kode ini adalah kemungkinan penyebab masalah klien). Ini adalah metode ilmiah untuk insinyur perangkat lunak; mengamati, membuat hipotesis, menguji, merefleksikan, mengulangi.

Apakah masuk akal untuk bersikeras mereproduksi setiap cacat dan men-debug sebelum mendiagnosis dan memperbaikinya?

Tidak, tentu saja tidak. Itu akan menjadi kebijakan bodoh.

Masalah yang saya lihat dengan pertanyaan Anda dan proposal Anda adalah bahwa mereka gagal membuat perbedaan

• laporan bug
• kegagalan ( kesalahan )
• bug (juga kadang-kadang disebut kesalahan )

Sebuah laporan bug adalah komunikasi tentang bug. Ini memberitahu Anda seseorang berpikir ada sesuatu yang salah. Ini mungkin atau mungkin tidak spesifik tentang apa yang seharusnya salah.

Laporan bug adalah bukti kegagalan.

Sebuah kegagalan adalah insiden sesuatu yang tidak beres. Kerusakan tertentu, tetapi tidak harus dengan petunjuk apa pun yang menyebabkannya.

Kegagalan mungkin disebabkan oleh bug.

Sebuah bug adalah penyebab kegagalan; sesuatu yang dapat (pada prinsipnya) diubah untuk mencegah kegagalan yang terjadi di masa depan.

Terkadang, ketika bug dilaporkan, penyebabnya segera jelas. Dalam kasus seperti itu, mereproduksi bug tidak masuk akal. Di lain waktu, penyebabnya tidak jelas sama sekali: laporan bug tidak menggambarkan kegagalan tertentu, atau memang demikian, tetapi kegagalannya sedemikian rupa sehingga tidak memberikan petunjuk tentang apa yang mungkin menjadi penyebabnya. Dalam kasus seperti itu, saya merasa saran Anda dibenarkan - tetapi tidak selalu: seseorang tidak bersikeras menabrak roket luar angkasa $ 370 juta kedua sebelum menerima untuk menyelidiki apa yang menyebabkan yang pertama jatuh (bug tertentu dalam perangkat lunak kontrol).

Dan ada juga berbagai macam kasus di antaranya; misalnya, jika laporan bug tidak membuktikan, tetapi hanya menunjukkan, bahwa masalah potensial yang sudah Anda sadari mungkin memainkan peran, ini mungkin cukup insentif bagi Anda untuk melihatnya lebih dekat.

Jadi, walaupun bersikeras untuk dapat bereproduksi adalah hal yang bijaksana untuk kasus-kasus yang lebih sulit, tidak bijaksana untuk memaksakannya sebagai kebijakan ketat.

Seperti semua hal lain dalam pengembangan perangkat lunak, jawaban yang benar adalah kompromi.

Secara teori, Anda tidak boleh mencoba untuk memperbaiki bug jika Anda tidak dapat membuktikan bahwa itu ada. Melakukan hal itu dapat menyebabkan Anda membuat perubahan yang tidak perlu pada kode Anda yang pada akhirnya tidak menyelesaikan apa pun. Dan membuktikannya berarti mereproduksinya terlebih dahulu, kemudian membuat dan menerapkan perbaikan, kemudian menunjukkan bahwa itu tidak lagi terjadi. Naluri Anda di sini mengarahkan Anda ke arah yang benar - jika Anda ingin yakin bahwa Anda telah menyelesaikan masalah pelanggan Anda, Anda harus tahu apa yang menyebabkannya.

Dalam praktiknya, itu tidak selalu mungkin. Mungkin bug hanya terjadi pada kelompok besar dengan lusinan pengguna secara bersamaan mengakses kode Anda. Mungkin ada kombinasi spesifik operasi data pada set data tertentu yang memicu bug dan Anda tidak tahu apa itu. Mungkin pelanggan Anda menjalankan program secara interaktif tanpa henti selama 100 jam sebelum bug terwujud.

Dalam semua kasus itu, ada peluang kuat bahwa departemen Anda tidak akan punya waktu atau uang untuk mereproduksi bug sebelum Anda mulai bekerja. Dalam banyak kasus, jauh lebih jelas bagi Anda, pengembang, bahwa ada bug dalam kode yang mengarahkan Anda ke situasi yang benar. Setelah Anda mendiagnosis masalahnya, Anda mungkin dapat kembali dan mereproduksinya. Ini tidak ideal, tetapi pada saat yang sama, bagian dari pekerjaan Anda sebagai pengembang senior adalah untuk mengetahui cara membaca dan menafsirkan kode, sebagian untuk menemukan jenis bug yang terkubur ini.

Menurut pendapat saya, Anda berfokus pada bagian pertanyaan yang salah. Bagaimana jika Anda akhirnya tidak dapat mereproduksi bug yang dimaksud? Tidak ada yang lebih membuat frustrasi pelanggan daripada mendengar "ya, kami tahu Anda membuat program macet tapi kami tidak bisa memperbanyaknya, jadi itu bukan bug." Ketika pelanggan Anda mendengar ini, mereka menafsirkannya sebagai "kami tahu perangkat lunak kami buggy tetapi kami tidak bisa repot-repot untuk memperbaiki dan memperbaiki bug sehingga hanya menyeberangi jari Anda." Jika lebih baik menutup bug yang dilaporkan sebagai "tidak dapat direproduksi", atau menutupnya sebagai "tidak dapat direproduksi, tetapi kami telah membuat beberapa perubahan yang masuk akal untuk mencoba meningkatkan stabilitas"?

Kecuali jika kesalahannya jelas, jelas dan sepele, dengan pesan kesalahan yang sangat spesifik, dll., Seringkali sangat sulit untuk memperbaiki bug jika pengguna atau pengelola tidak dapat mengulanginya.

Juga, bagaimana Anda membuktikan kepada mereka bahwa bug telah diperbaiki jika Anda tidak dapat meniru langkah-langkahnya?

Masalah dengan kasing Anda adalah bahwa pengguna juga tidak tahu bagaimana kesalahan terjadi, yaitu di layar apa melakukan operasi apa. Mereka hanya memiliki log.

Saya pikir poin Anda masuk akal. Jika Anda memiliki kekuatan psikis , Anda mungkin tidak akan bekerja dengan gaji.

Saya pikir Anda harus memberi tahu atasan Anda bahwa tanpa bisa meniru kesalahan itu akan membutuhkan waktu lama untuk mengetahuinya, dan tidak ada jaminan sama sekali yang Anda mau.

Masalahnya adalah ketika beberapa rekan kerja Anda menemukan bug dari keberuntungan murni dan memperbaikinya.

Mari kita bahas ekstrim, dan asumsikan bahwa Anda menemukan bug lebih awal: dalam kode Anda, saat Anda menulisnya. Maka Anda tidak akan memiliki keraguan untuk memperbaikinya di sana - Anda melihat cacat logika pada kode yang baru saja Anda tulis, itu tidak melakukan apa yang Anda inginkan. Anda tidak akan merasa perlu mengatur seluruh lingkungan untuk menunjukkan bahwa itu sebenarnya bug.

Sekarang ada laporan bug. Ada beberapa hal yang dapat Anda lakukan. Salah satunya adalah kembali ke kode dan membacanya kembali. Sekarang anggaplah pada bacaan kedua ini, Anda segera menemukan bug dalam kode - itu hanya tidak melakukan apa yang Anda inginkan, dan Anda gagal memperhatikan ketika Anda menulisnya. Dan , itu menjelaskan dengan sempurna bug yang baru saja masuk! Anda yang memperbaiki. Anda butuh dua puluh menit.

Apakah itu memperbaiki bug yang menyebabkan laporan bug? Anda tidak dapat 100% yakin (mungkin ada dua bug yang menyebabkan hal yang sama), tetapi mungkin memang demikian.

Hal lain yang dapat Anda lakukan adalah mereproduksi konfigurasi pelanggan sebaik yang Anda bisa (beberapa hari kerja), dan akhirnya mereproduksi bug. Dalam banyak kasus, ada masalah waktu dan konkurensi yang berarti Anda tidak dapat mereproduksi bug, tetapi Anda dapat mencoba banyak waktu dan terkadang melihat hal yang sama terjadi. Sekarang Anda mulai men-debug, menemukan kesalahan dalam kode, meletakkannya di lingkungan, dan Anda mencoba berkali-kali lagi. Anda tidak melihat bug terjadi lagi.

Apakah itu memperbaiki bug yang menyebabkan laporan bug? Anda masih tidak dapat 100% yakin - satu, Anda mungkin sebenarnya telah melihat bug yang sama sekali berbeda dengan yang dilakukan pelanggan, dua, mungkin Anda tidak cukup sering mencoba, dan tiga, mungkin konfigurasi masih sedikit berbeda dan itu memperbaiki sistem ini, tetapi bukan pelanggan.

Jadi kepastian tidak mungkin diperoleh dalam hal apa pun. Tetapi metode pertama adalah cara yang lebih cepat (Anda dapat memberi pelanggan patch lebih cepat juga), jauh lebih murah dan, jika Anda menemukan bug pengkodean yang jelas yang menjelaskan gejala, sebenarnya lebih mungkin untuk menemukan masalahnya juga.

Jadi itu tergantung. Jika murah untuk menyiapkan lingkungan pengujian (atau lebih baik: tes otomatis yang menunjukkan masalah), maka lakukan itu. Tetapi jika mahal dan / atau keadaan di mana bug menunjukkan tidak dapat diprediksi, maka selalu lebih baik untuk mencoba menemukan bug dengan membaca kode terlebih dahulu.

Membaca pertanyaan, saya tidak melihat adanya pertentangan mendasar antara posisi Anda dan tim Anda.

• Ya, Anda harus berusaha sebaik mungkin untuk mereproduksi masalah yang terjadi di pengaturan klien. Tetapi upaya terbaik berarti bahwa Anda harus menentukan kotak waktu untuk itu, dan mungkin tidak ada cukup data dalam log untuk benar-benar mereproduksi masalah.

  Jika demikian, semua tergantung pada hubungan dengan pelanggan ini. Ini bisa berubah dari Anda tidak akan memiliki apa pun darinya, hingga Anda dapat mengirim pengembang di situs dengan alat diagnosis dan kemampuan untuk menjalankannya pada sistem yang gagal. Biasanya, kita ada di suatu tempat di antara dan jika data awal tidak cukup ada cara untuk mendapatkan lebih banyak.

• Ya, pengembang senior harus dapat membaca kode dan cenderung menemukan alasan masalah setelah konten log. Sungguh, sering kali mungkin untuk menulis beberapa unit test yang menunjukkan masalah setelah membaca kode dengan hati-hati.

  Berhasil menulis unit test hampir sama baiknya dengan mereproduksi lingkungan fungsional yang rusak. Tentu saja, metode ini juga bukan jaminan bahwa Anda akan menemukan apa pun. Memahami urutan kejadian yang tepat yang menyebabkan kegagalan dalam beberapa perangkat lunak multi-utas bisa sangat sulit ditemukan hanya dengan membaca kode, dan kemampuan untuk melakukan debug langsung cenderung menjadi kritis.

Singkatnya, saya akan mencoba untuk kedua pendekatan secara bersamaan dan meminta baik sistem hidup yang menunjukkan masalah (dan menunjukkan bahwa itu diperbaiki setelah itu) atau untuk beberapa unit tes melanggar pada masalah (dan juga menunjukkan itu diperbaiki setelah perbaikan).

Mencoba memperbaiki kode dan mengirimkannya di alam liar, memang terlihat sangat berisiko. Dalam beberapa kasus serupa yang terjadi pada saya (di mana kami gagal mereproduksi cacat secara internal), saya menjelaskan bahwa jika perbaikan terjadi di alam liar dan gagal menyelesaikan masalah pelanggan, atau memiliki konsekuensi negatif tak terduga lainnya, orang yang mengajukan itu harus membantu tim pendukung untuk menemukan masalah yang sebenarnya. Termasuk berurusan dengan pelanggan jika perlu.

Kedengarannya bagi saya seperti Anda perlu logging lebih detail.

Meskipun menambahkan lebih banyak logging tidak dapat menjamin bahwa Anda tidak perlu melakukan debug (atau, dalam hal ini, mereproduksi situasi), ini akan memberi Anda wawasan yang jauh lebih baik tentang apa yang sebenarnya salah.

Terutama dalam situasi rumit / threading, atau apa pun di mana Anda tidak dapat menggunakan debugger, kembali ke "debug oleh printf ()" mungkin satu-satunya jalan Anda. Dalam hal ini, catat sebanyak yang Anda bisa (lebih dari yang Anda harapkan butuhkan) dan miliki beberapa alat bagus untuk menyaring gandum dari sekam.

Apakah masuk akal untuk bersikeras mereproduksi setiap cacat dan men-debug sebelum mendiagnosis dan memperbaikinya?

Karena belum ada yang mengatakannya dengan jelas: Sama sekali tidak!

Seperti semua hal lain dalam pengembangan perangkat lunak, perbaikan bug berarti mengingat waktu, risiko, dan biaya. Menemukan keseimbangan antara ini adalah setengah dari deskripsi pekerjaan seorang pengembang.

Beberapa bug tidak cukup penting untuk menghabiskan waktu 2 hari, tetapi cukup penting untuk menghabiskan 10 menit untuk memperbaikinya. Bug lain bersifat non-deterministik dan Anda sudah tahu lingkungan pengujian tidak dapat membuktikan bahwa mereka telah diperbaiki. Jika pengaturan lingkungan pengujian memakan waktu 2 hari, Anda tidak melakukannya untuk bug ini. Alih-alih, Anda menghabiskan waktu untuk hal-hal yang lebih cerdas, seperti menemukan cara untuk mengatur lingkungan pengujian dalam 5 menit, bukan 2 hari.

Dan tentu saja ada bug di mana jika Anda salah, klien akan kehilangan $ 100'000 +. Dan bug di mana klien akan kehilangan $ 100'000 + untuk setiap jam bug tidak diperbaiki. Anda perlu melihat bug dan membuat keputusan. Pernyataan selimut untuk memperlakukan semua bug sama tidak berfungsi.

Pertanyaan yang sangat bagus Pendapat saya adalah bahwa jika Anda tidak dapat mereproduksi masalah maka Anda tidak dapat 100% pasti mengatakan bahwa perbaikan yang Anda buat tidak akan:

a) benar-benar memperbaiki masalah. b) buat bug lain

Ada kalanya bug terjadi dan saya memperbaikinya dan saya tidak repot-repot mengujinya. Saya tahu 100% pasti berhasil. Tetapi sampai departemen QA kami mengatakan bahwa itu berfungsi maka saya menganggapnya masih ada kemungkinan masih ada bug ... atau bug baru yang dibuat dari perbaikan.

Jika Anda tidak dapat mereproduksi bug dan kemudian menginstal versi baru dan mengonfirmasi bahwa itu sudah diperbaiki maka Anda tidak bisa, dengan kepastian 100%, mengatakan bahwa bug sudah hilang.

Saya mencoba selama beberapa menit untuk memikirkan analogi untuk membantu Anda menjelaskan kepada orang lain tetapi tidak ada yang benar-benar terlintas dalam pikiran. Vasektomi adalah contoh yang lucu tetapi tidak dalam situasi yang sama :-)

[bug yang terkait dengan] akses database bersamaan, implementasi cluster, multithreaded

Apakah masuk akal untuk bersikeras mereproduksi setiap cacat dan men-debug sebelum mendiagnosis dan memperbaikinya?

Saya tidak akan menghabiskan terlalu banyak waktu untuk mereproduksi. Itu tampak seperti masalah sinkronisasi dan itu lebih sering ditemukan dengan alasan (mulai dari log seperti yang Anda harus menunjukkan dengan tepat subsistem di mana masalah terjadi) daripada dengan dapat menemukan cara untuk mereproduksi dan menyerangnya dengan debugger . Dalam pengalaman saya, mengurangi tingkat optimisasi kode atau kadang-kadang dan bahkan mengaktifkan instrumentasi tambahan bisa cukup untuk menambah penundaan yang cukup atau kurangnya sinkronisasi primitif untuk mencegah bug terwujud.

Ya, jika Anda tidak memiliki cara untuk mereproduksi bug, Anda tidak akan dapat memastikan bahwa Anda memperbaikinya. Tetapi jika pelanggan Anda tidak memberi Anda cara untuk memperbanyaknya, Anda mungkin juga mencari sesuatu yang serupa dengan konsekuensi yang sama tetapi akar penyebab yang berbeda.

Kedua aktivitas (tinjauan dan pengujian kode) diperlukan, juga tidak cukup.

Anda dapat menghabiskan waktu berbulan-bulan membuat percobaan yang mencoba untuk mereprorosi bug, dan tidak pernah mencapai apa pun jika Anda tidak melihat kode dan membentuk hipotesis untuk mempersempit ruang pencarian. Anda mungkin menghabiskan waktu berbulan-bulan menatap pusar Anda mencoba memvisualisasikan bug dalam kode, bahkan mungkin berpikir Anda telah menemukannya sekali, dua kali, tiga kali, hanya untuk meminta pelanggan yang semakin tidak sabar berkata, "Tidak, bug itu masih ada. "

Beberapa pengembang relatif lebih baik di satu aktivitas (review kode vs tes membangun) daripada yang lain. Seorang manajer yang sempurna menimbang kekuatan ini ketika menugaskan bug. Pendekatan tim mungkin lebih bermanfaat.

Pada akhirnya, mungkin tidak ada informasi yang cukup untuk repro bug, dan Anda harus membiarkannya meresap untuk sementara berharap pelanggan lain akan menemukan masalah yang sama, memberi Anda lebih banyak wawasan tentang masalah konfigurasi. Jika pelanggan yang melihat bug benar-benar ingin memperbaikinya, mereka akan bekerja dengan Anda untuk mengumpulkan lebih banyak informasi. Jika masalah ini hanya muncul satu kali, itu mungkin bukan bug prioritas tinggi bahkan jika pelanggan itu penting. Kadang-kadang bug yang tidak berfungsi lebih pintar daripada meniup jam kerja untuk mencari cacat yang tidak jelas dengan informasi yang tidak mencukupi.