Kapan perbaikan bug menjadi berlebihan, jika pernah?


128

Bayangkan Anda membuat pemutar video dalam JavaScript. Pemutar video ini memutar video pengguna berulang kali menggunakan fungsi rekursif dan, karena itu, browser akan memicu suatu too much recursion RangeErrorsaat.

Mungkin tidak ada yang akan menggunakan fitur loop sebanyak itu. Aplikasi Anda tidak akan pernah melempar kesalahan ini, bahkan jika pengguna meninggalkan perulangan aplikasi selama seminggu, tetapi masih ada. Menyelesaikan masalah akan mengharuskan Anda mendesain ulang cara kerja looping di aplikasi Anda, yang akan memakan banyak waktu. Apa yang kamu kerjakan? Mengapa?

  • Perbaiki bug

  • Tinggalkan bug

Bukankah seharusnya Anda hanya memperbaiki bug yang akan membuat orang tersandung? Kapan perbaikan bug menjadi berlebihan, jika pernah dilakukan?

SUNTING:

Jika pendekatan rekursif yang tidak menyebabkan bug aktual menjadi perhatian Anda, anggaplah bahwa setiap kali pemain memutar video, variabel akan bertambah 1. Setelah 2 53 loop, variabel ini akan meluap dan program Anda tidak akan bisa mengatasinya, dengan melemparkan pengecualian.


95
Jangan main-main dengan contoh skenario kasus saya
Tiago Marinho

15
@PlasmaHH Saya menggunakan skenario hipotetis ini untuk menjelaskan pertanyaan saya. Jika ada bug atau tidak, itu tidak masalah sama sekali
Tiago Marinho

13
@TiagoMarinho: poin yang saya coba buat adalah: kadang-kadang itu adalah hal yang tepat untuk mendefinisikan skenario seperti perilaku yang dimaksud.
PlasmaHH

23
Mengapa di bumi Anda menjalankan loop seperti itu menggunakan rekursi di tempat pertama? Anda mungkin tidak ingin memperbaiki bug, tetapi Anda yakin harus mempertimbangkan kembali proses desain Anda :-)
jamesqf

28
Ini sepertinya lebih seperti pertanyaan bisnis. Anda harus memprioritaskan berdasarkan pada biaya untuk memperbaiki, dan dampak / frekuensi bug.
Casey Kuball

Jawaban:


164

Anda harus pragmatis.

Jika kesalahan tidak mungkin dipicu di dunia nyata dan biaya untuk memperbaiki tinggi, saya ragu banyak orang akan menganggapnya sebagai penggunaan sumber daya yang baik untuk memperbaikinya. Atas dasar itu saya akan mengatakan biarkan saja tetapi pastikan peretasan tersebut didokumentasikan untuk Anda atau penerus Anda dalam beberapa bulan (lihat paragraf terakhir).

Yang mengatakan, Anda harus menggunakan masalah ini sebagai "pengalaman belajar" dan pada saat Anda melakukan perulangan tidak menggunakan perulangan yang berulang-ulang secara tidak perlu.

Juga, bersiaplah untuk laporan bug itu. Anda akan kagum dengan betapa baik pengguna akhir mendorong batas dan menemukan cacat. Jika itu menjadi masalah bagi pengguna akhir, Anda harus memperbaikinya - maka Anda akan senang mendokumentasikan peretasan tersebut.


119
Sepenuhnya setuju dengan "Anda akan kagum betapa pengguna akhir baik mendorong batas dan mengungkap cacat."
Melihat

74
Pengguna akhir sama sekali tidak dibatasi oleh apa yang Anda anggap sebagai penggunaan wajar perangkat lunak Anda. Akan ada pengguna yang ingin mengulang video selamanya. Ini adalah fitur yang disediakan perangkat lunak Anda, sehingga mereka akan menggunakannya.
gnasher729

36
@ gnasher729 "10-jam XXXX" video di Youtube adalah pengenal yang baik bahwa memang, beberapa orang hanya ingin mengulang sesuatu selamanya.
Chris Cirefice

23
Masalah lain: Jika perangkat lunak Anda populer, maka seseorang menemukan bug yang memang hanya terjadi dalam situasi yang jarang terjadi, mempostingnya di internet, dan tiba-tiba semua orang dan anjing mereka berkata "perangkat lunak ini adalah sampah, macet jika saya memutar video untuk satu hari". Atau pesaing menggunakannya untuk menunjukkan betapa mudahnya crash aplikasi Anda.
gnasher729

4
Tekankan pada paragraf terakhir. Tahukah Anda bahwa MacOS Classic akan macet jika menerima 32.768 acara "pers mouse" berturut-turut tanpa ada acara "pelepasan tetikus" yang mengintervensi?
Tandai

79

Ada bug serupa di Windows 95 yang menyebabkan komputer mogok setelah 49,7 hari . Itu hanya diperhatikan beberapa tahun setelah rilis, karena sangat sedikit sistem Win95 yang bertahan selama itu. Jadi ada satu poin: bug mungkin dianggap tidak relevan oleh bug lain yang lebih penting.

Yang harus Anda lakukan adalah penilaian risiko untuk program secara keseluruhan dan penilaian dampak untuk bug individu.

  • Apakah perangkat lunak ini pada batas keamanan?
  • Jika demikian, dapatkah bug ini menghasilkan exploit?
  • Apakah perangkat lunak ini "misi penting" untuk pengguna yang dituju? (Lihat daftar hal-hal yang dilarang oleh Java EULA untuk Anda gunakan )
  • Bisakah bug mengakibatkan hilangnya data? Kerugian keuangan? Kerugian reputasi?
  • Seberapa besar kemungkinan bug ini terjadi? (Anda memasukkan ini dalam skenario Anda)

Dan seterusnya. Ini memengaruhi bug triage , proses memutuskan bug mana yang akan diperbaiki. Hampir semua perangkat lunak pengiriman memiliki daftar bug minor yang sangat panjang yang belum dianggap cukup penting untuk diperbaiki.


2
Saya juga mengingat bug (perangkat keras) di beberapa CPU Intel di mana nilai floating point tertentu salah.

5
@WilliamKappler en.wikipedia.org/wiki/Pentium_FDIV_bug adalah apa yang saya yakin Anda maksudkan. Sudah bangun selama setahun sebelum ada yang menyadarinya.
Jeutnarg

10
@ gnasher729 - Tidak juga, mereka sudah di bagian bawah dan masih menggali :) Kebanyakan orang harus menginstal ulang Win 95 lebih sering dari 49,7 hari IIRC.
Mcottle

4
@Luaan Komentar ini dimaksudkan sebagai penggalian ringan di M $, karenanya senyuman setelah kalimat pertama. Mereka berada di belakang delapan bola dengan '95 karena keluar sangat terlambat di 95 (mungkin karena memiliki Win95 dirilis pada tahun 1996 akan menjadi tampilan yang buruk), setengah panggang (Ingat BSOD USB?) Dan cenderung menjadi tidak stabil dan memerlukan menginstal ulang secara teratur maka kalimat kedua saya - yang tidak pernah disebutkan menjalankan server pada Windows 95, saya tidak tahu dari mana Anda mendapatkannya (kilas balik?). Rilis CD kedua meningkatkan masalah tetapi rilis awal '95 adalah doozy.
mcottle

5
TBH Saya pikir itu adalah kegagalan "Windows for Warships" yang melakukan lebih banyak kerusakan reputasi ( archive.wired.com/science/discoveries/news/1998/07/13987 ) dan yang menggunakan NT. Mesin Unix pada waktu itu dapat mengatur waktu kerja multi-tahun, bahkan menggunakan versi Linux yang sangat awal. Semua komputer di rumah juga mampu uptime tinggi, meskipun jarang digunakan seperti itu. Saya melihat BBC BBC tertanam dalam pameran pendidikan satu dekade setelah mereka usang.
pjc50

33

Jawaban lain sudah sangat baik, dan saya tahu contoh Anda hanyalah sebuah contoh, tetapi saya ingin menunjukkan sebagian besar dari proses ini yang belum dibahas:

Anda perlu mengidentifikasi asumsi Anda, dan kemudian menguji asumsi tersebut terhadap kasus sudut.

Melihat contoh Anda, saya melihat beberapa asumsi:

  • Pendekatan rekursif pada akhirnya akan menyebabkan kesalahan.
  • Tidak ada yang akan melihat kesalahan ini karena video terlalu lama untuk diputar untuk mencapai batas tumpukan.

Orang lain telah membahas asumsi pertama, tetapi lihat asumsi kedua: bagaimana jika video saya hanya sepersekian detik?

Dan tentu saja, mungkin itu bukan kasus penggunaan yang sangat umum. Tapi apakah Anda benar-benar yakin tidak ada yang akan mengunggah video yang sangat singkat? Anda menganggap bahwa video adalah durasi minimum, dan Anda mungkin bahkan tidak menyadari bahwa Anda mengasumsikan sesuatu! Bisakah asumsi ini menyebabkan bug lain di tempat lain dalam aplikasi Anda?

Asumsi yang tidak dikenal adalah sumber bug yang besar.

Seperti yang saya katakan, saya tahu bahwa contoh Anda hanyalah sebuah contoh, tetapi proses mengidentifikasi asumsi Anda (yang seringkali lebih sulit daripada kedengarannya) dan kemudian memikirkan pengecualian terhadap asumsi tersebut adalah faktor besar dalam memutuskan di mana menghabiskan waktu Anda.

Jadi jika Anda mendapati diri Anda berpikir "Saya tidak harus memprogram tentang ini, karena ini tidak akan pernah terjadi" maka Anda harus meluangkan waktu untuk benar-benar memeriksa asumsi itu. Anda akan sering memikirkan kasus sudut yang mungkin lebih umum daripada yang Anda bayangkan.

Yang sedang berkata, ada titik di mana ini menjadi latihan sia-sia. Anda mungkin tidak peduli apakah aplikasi JavaScript Anda berfungsi dengan baik pada kalkulator TI-89, jadi habiskan waktu berapa saja untuk itu yang terbuang sia-sia.

Jawaban lain sudah membahas hal ini, tetapi muncul dengan garis antara "ini penting" dan "ini buang-buang waktu" bukanlah ilmu pasti, dan itu tergantung pada banyak faktor yang dapat sepenuhnya berbeda dari satu orang atau perusahaan ke orang lain.

Tetapi bagian besar dari proses itu adalah pertama-tama mengidentifikasi asumsi Anda dan kemudian mencoba mengenali pengecualian terhadap asumsi itu.


Poin yang sangat bagus, Kevin. Perhatikan komentar saya pada jawaban yang dipilih di atas yang berfokus pada pertanyaan analisisWhat's the worst thing that could happen?
OMY

Asumsi lain di sini adalah bahwa tumpukan yang terus tumbuh hanya akan menyebabkan masalah ketika mencapai ukuran melimpah. Bahkan, tumpukan bisa menjadi sumber daya normal bug ini terus bocor. Seluruh browser bisa menjadi lebih lambat dan lebih lambat oleh bit kecil di setiap iterat ^ H ^ H ^ H ^ H ^ H ^ H ^ Hrecursion.
Alfe

1. OP tidak pernah mengatakan masalah itu disebabkan oleh tumpukan yang tumbuh. Itu bisa dengan mudah disebabkan oleh kesalahan dalam rutinitas penghitung (dec -> div / 0?). 2. Jika masalahnya adalah masalah stack overflow, bukankah seharusnya pertanyaan ini diposting di StackOverflow? <rimshot!> ;-D
OMY

@OMY Kepada siapa komentar diarahkan?
Kevin Workman

13

Saya akan merekomendasikan Anda membaca makalah berikut:

Ketergantungan dan Ancamannya: Taksonomi

Antara lain, ini menjelaskan berbagai jenis kesalahan yang dapat terjadi dalam program Anda. Apa yang Anda deskripsikan disebut kesalahan tidak aktif , dan dalam makalah ini dijelaskan sebagai berikut:

Kesalahan aktif saat menghasilkan kesalahan, jika tidak aktif. Kesalahan aktif adalah a) kesalahan internal yang sebelumnya tidak aktif dan yang telah diaktifkan oleh proses perhitungan atau kondisi lingkungan, atau b) kesalahan eksternal. Aktivasi kesalahan adalah penerapan input (pola aktivasi) ke komponen yang menyebabkan kesalahan aktif menjadi aktif. Sebagian besar kesalahan internal siklus antara keadaan aktif dan tidak aktif mereka

Setelah menggambarkan ini, semuanya bermuara pada rasio biaya-manfaat. Biaya akan terdiri dari tiga parameter:

  • Seberapa sering masalah muncul dengan sendirinya?
  • Apa konsekuensinya?
  • Berapa banyak hal itu mengganggu Anda secara pribadi?

Dua yang pertama sangat penting. Jika itu adalah bug yang akan memanifestasikan dirinya sekali dalam bulan biru dan / atau tidak ada yang peduli, atau memiliki solusi yang sangat baik dan praktis, maka Anda dapat dengan aman mendokumentasikannya sebagai masalah yang diketahui dan beralih ke yang lebih menantang dan lebih tugas-tugas penting. Namun, jika bug akan menyebabkan beberapa transaksi uang gagal, atau mengganggu proses registrasi yang panjang, sehingga membuat frustasi pengguna akhir, maka Anda harus menindaklanjutinya. Parameter ketiga adalah sesuatu yang sangat saya anjurkan. Dalam kata-kata Vito Corleone:

Itu bukan pribadi. Ini bisnis.

Jika Anda seorang profesional, tinggalkan emosi dan bertindaklah secara optimal. Namun, jika aplikasi yang Anda tulis adalah hobi Anda, maka Anda terlibat secara emosional, dan parameter ketiga sama validnya dengan apa pun dalam hal memutuskan apakah akan memperbaiki bug atau tidak.


“Itu bukan masalah pribadi. Ini bisnis, menurut Michael, bukan Vito. (Anda akan kagum dengan betapa baik pengguna akhir mendorong batas dan menemukan cacat)
384X21

Sebenarnya, itu oleh Vito, jika Anda membaca buku. Bahkan dalam film itu, Tom Hagen yang mengatakan bahwa pertama ketika berdebat dengan Sonny tentang apakah mereka harus pergi ke kasur, dan hanya setelah itu Michael pertama mengatakan kutipan terkenal: "Ini bukan pribadi, Sonny. Ini sepenuhnya bisnis .. . " Tapi Hagen belajar itu dari Vito.
Vladimir Stokic

11

Bug itu hanya tetap belum ditemukan sampai seseorang menempatkan pemain Anda di layar lobi menjalankan presentasi perusahaan 24/7. Jadi itu masih bug.

Jawaban atas apa yang Anda lakukan? benar-benar keputusan bisnis, bukan keputusan teknis:

  • Jika bug hanya berdampak pada 1% dari pengguna Anda, dan pemain Anda tidak memiliki dukungan untuk fitur yang dibutuhkan oleh 20% lainnya, pilihannya jelas. Dokumentasikan bug, kemudian lanjutkan.
  • Jika perbaikan bug ada di daftar todo Anda, seringkali lebih baik untuk memperbaikinya sebelum Anda mulai menambahkan fitur baru. Anda akan mendapatkan manfaat dari proses pengembangan perangkat lunak tanpa cacat, dan Anda tidak akan kehilangan banyak waktu karena itu ada di daftar Anda.

5

Terutama di perusahaan besar (atau proyek besar) ada cara yang sangat pragmatis untuk menetapkan apa yang harus dilakukan.

Jika biaya perbaikan lebih besar dari pengembalian yang akan diberikan perbaikan maka simpan bug tersebut. Viceversa jika perbaikan akan mengembalikan lebih dari biayanya maka perbaiki bug.

Dalam skenario sampel Anda, itu tergantung pada seberapa banyak pengguna yang Anda harapkan akan kalah vs berapa banyak pengguna yang akan Anda peroleh jika Anda mengembangkan fitur baru alih-alih memperbaiki bug yang mahal itu.


6
ROI untuk memperbaiki bug jarang mudah dievaluasi - Anda biasanya harus mengandalkan penilaian Anda.
Semut

Pengembalian yang akan diberikan perbaikan sebagian besar adalah reputasi yang hampir tidak mungkin diukur. Jika saya satu-satunya yang bahkan tahu bahwa mungkin ada bug dan kemudian dalam satu atau dua tahun saya berganti pekerjaan dan perusahaan baru berpikir untuk menanamkan pemutar video ke dalam produk mereka (mungkin menjual jutaan unit) saya sarankan menggunakan yang ini?
Jerry Jeremiah

@JerryJeremiah jika bug mencegah proses bisnis berjalan bukan tentang reputasi, itu tergantung pada pentingnya proses bisnis. Dan dalam setiap kasus dan setiap kebijakan yang Anda terapkan untuk memperbaiki bug atau tidak, Anda harus membuat evaluasi subyektif berdasarkan pengalaman dan pengetahuan Anda. Bahkan jika Anda dapat mengetahui jumlah pasti pengguna yang akan menghadapi bug, Anda masih harus membuat pilihan manusia (kebijakan ROI juga dapat menyertakan statistik hit bug untuk menambah biaya). Karena hari ini tidak ada cara mekanis untuk mengetahui apriori hal yang sempurna untuk dilakukan.
JoulinRouge

5

tl; dr Inilah sebabnya mengapa RESOLVED/WONTFIXada sesuatu. Hanya saja jangan terlalu sering menggunakannya - hutang teknis dapat menumpuk jika Anda tidak hati-hati. Apakah ini masalah mendasar dengan desain Anda, kemungkinan akan menyebabkan masalah lain di masa depan? Kemudian perbaiki. Jika tidak? Biarkan sampai menjadi prioritas (jika pernah).


5

Sebenarnya ada tiga kesalahan dalam situasi yang Anda uraikan:

  1. Kurangnya proses untuk mengevaluasi semua kesalahan yang dicatat (Anda memang mencatat kesalahan di tiket / jaminan / sistem apa pun yang Anda miliki, kan?) Untuk menentukan apakah kesalahan itu harus diperbaiki atau tidak. Ini adalah keputusan manajemen.

  2. Kurangnya keterampilan dalam tim Anda yang mengarah pada penggunaan solusi yang salah seperti ini. Ini mendesak agar masalah ini ditangani untuk menghindari masalah di masa depan. (Mulai belajar dari kesalahan Anda.)

  3. Masalah bahwa video mungkin berhenti ditampilkan setelah waktu yang sangat lama.

Dari ketiga kesalahan itu saja (3) mungkin tidak perlu diperbaiki.


Terima kasih telah menunjukkan masalah urutan ke-2. Terlalu banyak orang hanya mengobati gejalanya, dan penyebabnya tetap membuat lebih banyak gejala.
Jaxter

4

Ada banyak jawaban di sini yang membahas mengevaluasi biaya bug yang diperbaiki dan bukannya meninggalkannya. Mereka semua berisi saran yang bagus, tetapi saya ingin menambahkan bahwa biaya bug sering diremehkan, mungkin sangat diremehkan. Alasannya adalah bahwa bug yang ada mengacaukan perairan untuk pengembangan dan pemeliharaan lanjutan. Membuat penguji melacak beberapa bug "tidak akan memperbaiki" saat menavigasi perangkat lunak Anda mencoba menemukan bug baru membuat pekerjaan mereka lebih lambat dan lebih rentan terhadap kesalahan. Beberapa bug "tidak akan memperbaiki" yang tidak mungkin memengaruhi pengguna akhir akan tetap membuat pengembangan lebih lambat dan hasilnya akan menjadi buggier.


2

Satu hal yang saya pelajari selama bertahun-tahun dalam pengkodean adalah bahwa bug akan kembali. Pengguna akhir akan selalu menemukannya dan melaporkan kembali. Apakah Anda akan memperbaiki bug atau tidak "hanyalah" masalah prioritas dan tenggat waktu.

Kami memiliki bug besar (menurut pendapat saya utama) yang diputuskan untuk tidak diperbaiki dalam satu rilis, hanya untuk menjadi penghenti acara untuk rilis berikutnya karena pengguna akhir menemukan itu berulang kali. Begitu juga sebaliknya - kami didorong untuk memperbaiki bug pada fitur yang tidak digunakan siapa pun, tetapi hal itu berguna bagi manajemen untuk melihatnya.


2

Ada tiga hal di sini:

Prinsip

Ini adalah satu sisi dari koin. Untuk batas tertentu, saya merasa itu adalah baik untuk bersikeras memperbaiki bug (atau implementasi buruk, bahkan jika mereka "bekerja"), bahkan jika tidak ada orang yang menyadarinya.

Lihatlah dengan cara ini: masalah sebenarnya belum tentu bug, dalam contoh Anda, tetapi fakta bahwa seorang programmer berpikir itu adalah ide yang baik untuk mengimplementasikan loop dengan cara ini, di tempat pertama. Sudah jelas sejak saat pertama, bahwa ini bukan solusi yang baik. Sekarang ada dua kemungkinan:

  • Programmer tidak memperhatikan. Nah ... seorang programmer harus mengembangkan intuisi tentang bagaimana kodenya berjalan. Bukannya rekursi adalah konsep yang sangat sulit. Dengan memperbaiki bug (dan berkeringat melalui semua pekerjaan tambahan), dia mungkin belajar sesuatu dan mengingatnya, jika hanya untuk menghindari pekerjaan tambahan di masa depan. Jika alasannya adalah bahwa ia tidak punya cukup waktu, manajemen mungkin belajar bahwa programmer yang membutuhkan lebih banyak waktu untuk membuat kode kualitas yang lebih tinggi.

  • Si programmer memang memperhatikan, tetapi menganggapnya "tidak masalah". Jika ini dibiarkan berdiri, maka budaya laissez-faire dikembangkan yang pada akhirnya akan menyebabkan bug di mana itu benar-benar menyakitkan. Dalam kasus khusus ini, siapa yang peduli. Tetapi bagaimana jika programmer itu sedang mengembangkan aplikasi perbankan di lain waktu, dan memutuskan bahwa konstelasi tertentu tidak akan pernah terjadi. Lalu itu terjadi. Waktu yang buruk.

Pragmatisme

Ini adalah sisi yang lain. Tentu saja, Anda kemungkinan besar tidak akan memperbaiki bug. Tapi hati-hati - ada pragmatisme, dan kemudian ada pragmatisme. Pragmatisme yang baik adalah jika Anda menemukan solusi yang cepat namun kokoh, beralasan untuk suatu masalah. Yaitu, Anda menghindari hal-hal yang dirancang berlebihan, tetapi hal-hal yang sebenarnya Anda implementasikan masih dipikirkan dengan matang. Pragmatisme buruk adalah ketika Anda hanya meretas sesuatu bersama yang berfungsi "hanya begitu" dan akan pecah pada kesempatan pertama.

Gagal cepat, gagal keras

Jika ragu, gagal cepat dan gagal keras.

Ini berarti, antara lain, bahwa kode Anda memperhatikan kondisi kesalahan, bukan lingkungan.

Dalam contoh ini, paling tidak yang dapat Anda lakukan adalah membuatnya sehingga kesalahan runtime keras ("tumpukan kedalaman melebihi" atau sesuatu seperti itu) tidak terjadi, dengan menggantinya dengan pengecualian keras Anda sendiri. Anda dapat, misalnya, memiliki penghitung global dan secara sewenang-wenang memutuskan bahwa Anda menyelamatkan setelah 1000 video (atau berapa pun jumlah yang cukup tinggi tidak akan pernah terjadi dalam penggunaan normal, dan cukup rendah untuk tetap berfungsi di sebagian besar browser). Kemudian berikan pengecualian (yang bisa berupa pengecualian umum, mis. RuntimeExceptionDalam Java, atau string sederhana dalam JavaScript atau Ruby) pesan yang bermakna. Anda tidak perlu sampai sejauh untuk membuat jenis pengecualian baru atau apa pun yang Anda lakukan dalam bahasa pemrograman khusus Anda.

Dengan cara ini, Anda punya

  • ... mendokumentasikan masalah di dalam kode.
  • ... menjadikannya masalah deterministik. Anda tahu bahwa pengecualian Anda akan terjadi. Anda tidak berada pada perubahan teknologi browser yang mendasarinya (pikirkan tidak hanya browser PC, tetapi juga smartphone, tablet, atau teknologi masa depan).
  • ... membuatnya mudah untuk memperbaikinya ketika Anda akhirnya harus memperbaikinya. Sumber masalah ditunjukkan oleh pesan Anda, Anda akan mendapatkan backtrack yang berarti dan semua itu.
  • ... masih tidak membuang waktu untuk melakukan penanganan kesalahan "nyata" (ingat, Anda tidak pernah mengharapkan kesalahan terjadi).

Konvensi saya adalah untuk mengawali pesan kesalahan seperti itu dengan kata "Paranoia:". Ini adalah pertanda yang jelas bagi saya dan semua orang bahwa saya tidak pernah mengharapkan kesalahan itu muncul. Saya dapat dengan jelas memisahkan mereka dari pengecualian "nyata". Jika saya melihat yang seperti itu di GUI atau logfile, saya tahu pasti bahwa saya memiliki masalah yang serius - saya tidak pernah berharap mereka akan terjadi. Pada titik ini saya masuk ke mode crunch (dengan peluang bagus untuk menyelesaikannya dengan cepat dan agak mudah, karena saya tahu persis di mana masalahnya terjadi, menyelamatkan saya dari banyak debugging palsu).


2
Maaf jika Anda merasakan hal ini tentang seberapa cepat saya menerima jawaban. Dalam pembelaan saya, saya tidak tahu pertanyaannya akan memiliki> 10.000 pandangan dan banyak jawaban pada saat penerimaan. Lagi pula saya masih belum berubah pikiran tentang jawaban terbaik.
Tiago Marinho

@TiagoMarinho, tidak masalah, komentar itu terutama tidak ditujukan kepada Anda secara pribadi, dan saya tidak mengharapkan Anda untuk mempertimbangkan kembali. ;) Saya lebih bingung dengan motivasi siapa pun yang memilih untuk benar-benar menghapus jawaban saya ... Juga, ada beberapa downvoting untuk beberapa jawaban di sini tanpa komentar. Tidak yakin apakah itu yang dilakukan di area SE khusus ini.
AnoE

Saya setuju sepenuhnya tentang downvoting yang aneh
Tiago Marinho

Saya bertanya-tanya apakah, dalam hal ini setidaknya, perawatannya lebih baik daripada penyembuhannya. Jika Anda memutuskan apakah akan melakukan penanganan khusus untuk cacat desain yang telah Anda identifikasi, masuk akal untuk membandingkan biaya siklus hidup penuh dari a) menerapkan penanganan kesalahan dan berpotensi bertindak atas kesalahan ketika itu terjadi dengan memperbaiki desain, atau b) hanya memperbaiki desain di tempat pertama.
Jaxter

@jaxter, tepatnya. Oleh karena itu pendekatan saya membuka pikiran untuk perbaikan bug (bahkan jika itu tampaknya berlebihan), tetapi ketika Anda memutuskan untuk tidak memperbaiki bug, maka setidaknya menerapkan hal gagal-cepat. Jelas, jika solusi gagal-cepat lebih mahal daripada perbaikan bug "nyata" di tempat pertama, maka hindari dan lakukan perbaikan bug nyata.
AnoE

1

Sebuah post-it di meja pengembang senior di tempat kerja saya mengatakan

Apakah ini membantu siapa pun?

Saya pikir itu sering merupakan titik awal yang baik untuk proses berpikir. Selalu ada banyak hal untuk diperbaiki dan ditingkatkan - tetapi berapa banyak nilai yang sebenarnya Anda tambahkan? ... apakah itu dalam kegunaan, keandalan, kemampuan pemeliharaan, keterbacaan, kinerja ... atau aspek lainnya.


0

Tiga hal muncul di pikiran:

Pertama , dampak bug yang diidentifikasi perlu diselidiki secara menyeluruh sebelum keputusan untuk meninggalkan bug dalam kode dapat dibuat secara bertanggung jawab. (Dalam contoh Anda, saya langsung berpikir tentang kebocoran memori yang ditimbulkan oleh tumpukan yang terus tumbuh dan yang mungkin membuat peramban Anda lebih lambat dan lebih lambat dengan setiap rekursi.) Penyelidikan menyeluruh ini seringkali memakan waktu lebih lama daripada memperbaiki bug, jadi saya lebih suka memperbaiki bug dalam banyak kasus.

Kedua , bug memiliki kecenderungan untuk memiliki dampak lebih dari yang diperkirakan pada awalnya. Kita semua sangat terbiasa dengan kode kerja karena ini adalah kasus "normal". Bug di sisi lain adalah "pengecualian". Tentu saja, kita semua telah melihat banyak bug, tetapi kita telah melihat cara kerja lebih banyak secara keseluruhan. Karena itu, kami memiliki lebih banyak pengalaman dengan bagaimana kode kerja berperilaku daripada dengan bagaimana kode kereta berperilaku. Ada banyak buku tentang kode kerja dan apa yang akan dilakukan dalam situasi apa. Ada hampir tidak ada tentang perilaku kode kereta.

Alasannya sederhana: Bug bukan ketertiban tetapi kekacauan . Mereka sering memiliki jejak pesanan yang tersisa di dalamnya (atau sebaliknya: Mereka tidak menghancurkan pesanan sepenuhnya), tetapi sifat kereta mereka adalah penghancuran urutan yang diinginkan oleh programmer. Kekacauan itu sendiri cenderung menentang diperkirakan dengan benar. Adalah jauh lebih sulit untuk mengatakan apa yang akan dilakukan oleh sebuah program dengan bug daripada apa yang akan dilakukan oleh program yang benar hanya karena tidak sesuai dengan pola mental kita lagi.

Ketiga , contoh Anda berisi aspek yang memperbaiki bug berarti harus mendesain ulang program. (Jika Anda menghapus aspek ini, jawabannya sederhana: Perbaiki bug, seharusnya tidak terlalu lama karena tidak perlu mendesain ulang. Jika tidak :) Dalam kasus seperti itu saya akan kehilangan kepercayaan pada program seperti saat ini dirancang. Desain ulang akan menjadi cara untuk memulihkan kepercayaan itu.

Semua yang dikatakan , program adalah hal-hal yang digunakan orang, dan fitur yang hilang atau yang kedua, bug yang sangat merepotkan di tempat lain dapat diprioritaskan daripada memperbaiki bug Anda. Tentu saja kemudian mengambil cara pragmatis dan melakukan hal-hal lain terlebih dahulu. Tapi jangan pernah lupa bahwa perkiraan cepat pertama dampak bug bisa sangat salah.


2
Silakan tinggalkan komentar saat Anda downvote. Kita harus tahu apa kritiknya untuk meningkatkan jawaban.
Alfe

0

Probabilitas rendah / Konsekuensi ringan = Memperbaiki prioritas yang rendah

  • Jika probabilitas terjadinya sangat rendah
  • Jika konsekuensi dari kejadian itu ringan
  • Maka bug tidak menimbulkan ancaman, maka bukan perbaikan prioritas.

Tapi ini tidak bisa menjadi penopang bagi pengembang yang malas ...

  • Apa artinya "sangat rendah" bahkan?
  • Apa "konsekuensi ringan" yang berarti?

Untuk menyatakan probabilitas terjadinya sangat rendah dan konsekuensinya ringan, tim pengembang harus memahami kode, pola penggunaan, dan keamanan.

Kebanyakan pengembang terkejut bahwa hal-hal yang semula mereka pikirkan tidak akan pernah terjadi, sebenarnya sering terjadi

Sistem pendidikan kami tidak mengajarkan probabilitas dan logika dengan baik. Kebanyakan orang, termasuk sebagian besar insinyur perangkat lunak memiliki logika yang rusak dan intuisi proabilitas yang rusak. Pengalaman dengan masalah dunia nyata dan pengalaman dengan simulasi luas adalah satu-satunya cara yang saya tahu untuk memperbaikinya.

Hadapi intuisi Anda dengan data dunia nyata

Penting untuk membuat beberapa log agar dapat mengikuti pola penggunaan. Isi kode dengan pernyataan hal-hal yang menurut Anda tidak boleh terjadi. Anda akan terkejut bahwa mereka melakukannya. Dengan begitu Anda akan dapat menghadapi intuisi Anda dengan data keras dan memperbaikinya.

Contoh saya tentang masalah ringan dan ukuran kontrol

Di situs e-commerce saya bekerja sejak lama, programmer lain membuat kesalahan: Dalam beberapa kondisi yang tidak jelas sistem mendebit klien satu sen lebih sedikit daripada yang terdaftar di log. Saya menemukan bug karena saya membuat laporan untuk mengidentifikasi perbedaan antara log dan kebetulan akun untuk membuat sistem akuntansi lebih tangguh. Saya tidak pernah memperbaiki bug ini karena perbedaannya sangat kecil. Perbedaannya dihitung setiap hari dan lebih rendah dari US $ 2,00 per bulan. Kebetulan kami mengembangkan sistem baru secara keseluruhan sehingga dalam satu tahun harus menggantikan yang sekarang. Tidak masuk akal untuk mengalihkan sumber daya dari proyek yang berpotensi menguntungkan untuk memperbaiki sesuatu yang harganya US $ 2,00 per bulan dan menjadi sasaran tindakan kontrol yang tepat.

Kesimpulan

Ya, ada bug yang tidak perlu diperbaiki segera, yang tidak cukup penting untuk menunda pengembangan fitur baru. Namun sistem harus memiliki kontrol terhadap kemunculan bug ini untuk memastikannya kecil karena kita tidak dapat mempercayai intuisi kita sendiri.


-1

Saya pikir ini menanyakan pertanyaan yang salah sejak awal.

Pertanyaannya bukan "apakah saya harus memperbaiki bug ini atau saya tidak memperbaiki bug ini". Setiap pengembang memiliki waktu terbatas. Jadi pertanyaannya adalah "apa hal paling berguna yang bisa saya lakukan dalam satu jam, atau empat jam, atau seminggu".

Jika memperbaiki bug itu adalah hal yang paling berguna untuk dilakukan, karena memperbaiki perangkat lunak dengan jumlah terbesar bagi kebanyakan orang, maka perbaiki bug tersebut. Jika Anda dapat melakukan peningkatan yang lebih besar di tempat lain, dengan menambahkan fitur yang hilang orang, atau dengan memperbaiki bug yang lebih penting, maka lakukan hal-hal lain ini. Dan poin bonus tambahan untuk apa pun yang membuat pengembangan masa depan Anda lebih efisien.


Tidak yakin metrik utilitarian berfungsi paling baik di sini. Jelas, contoh pemutar video dirancang agar berdampak rendah, tetapi bahkan itu tidak mudah. Salah satu penjawab sudah mengutip loop promo 24/7 di lobi Use Case, dan yang lain mungkin kios di konvensi penjualan / teknologi yang berjalan seminggu. Keduanya akan menelan biaya rep dan / atau uang untuk bisnis, jadi tidak sepele.
Jaxter

Itu berarti memperbaiki bug memberikan lebih banyak manfaat daripada yang diperkirakan, sehingga harus naik dalam prioritas. Jadi, Anda akan lebih sukses dalam hidup jika pendapat Anda tentang apa yang paling berguna sependapat dengan kenyataan.
gnasher729

-2

Memperbaiki bug selalu berlebihan

Mari kita mengklasifikasikan bagian bug terlebih dahulu.

Apakah ini kesalahan jujur , mis. Kesalahan satu kali atau bayangan yang lolos dari pengujian? Dalam hal ini, saya yakin berharap bahwa selain "memperbaiki" masalah Anda juga menulis tes unit baru, mengambil kesempatan untuk memperbaiki kode terdekat, di mana semua yang terakhir adalah pekerjaan yang bermanfaat .

Namun, jika itu sebenarnya cacat desain seperti dalam kasus Anda, Anda harus mengevaluasi kembali desain, atau dalam kasus terburuk, menonaktifkan fitur ini.

Jadi, tolong jangan mencoba memperbaikinya saja.

Tentu saja Anda dapat melakukan lebih buruk --- Anda dapat mencoba metodologi hack-upon-hack . Video looping adalah peretasan (arsitektur buruk dan ada kerusakan yang diketahui). Anda dapat menambahkan dalam batas loop , sehingga setelah N iterasi (yang Anda uji di bawah batas browser) loop berakhir.

Konsekuensi jelas, sekarang Anda harus mendukung kode yang rusak dan batas loop baru.

PS meminta maaf atas pandangan ekstremnya.

PPS Catatan tentang terminologi: Anda tidak dapat "memperbaiki" bug. Yah dokter hewan mungkin bisa, tetapi jangan pergi ke sana ;-). Masalah teratasi atau "diperbaiki", sementara bug dihapus atau diselesaikan.


Apakah Anda benar-benar bermaksud mengatakan itu selalu "berlebihan"? Saya pikir Anda mungkin telah menggabungkan definisi di suatu tempat. Overkill berarti "bekerja melebihi apa yang diminta", atau dengan kata lain, lebih dari yang seharusnya dilakukan siapa pun. Anda menegaskan perbaikan bug selalu di atas, sementara secara bersamaan memohon orang itu tidak cukup dan bahwa kita harus melakukan lebih banyak pekerjaan di atasnya, yang tidak masuk akal.
doppelgreener

@doppelgreener Saya melihat bagaimana itu bisa membingungkan. memperbaiki bug adalah praktik yang mengerikan dan tidak boleh dilakukan. Di sisi lain, mengadaptasi desain atau arsitektur perangkat lunak dengan persyaratan yang berubah adalah praktik yang baik yang harus diikuti. Sama untuk memperbaiki kesalahan jujur ​​dengan asumsi itu dilakukan dengan benar.
Dima Tisnek

2
Saya tidak tahu apa jenis perbaikan bug yang Anda bicarakan, tetapi di dunia saya sehari-hari, "ubah arsitektur" adalah metode untuk memperbaiki bug. Anda mungkin ingin mendefinisikan apa yang Anda kumpulkan di bawah istilah "memperbaiki bug".
doppelgreener

@doppelgreener - Istilah "perbaikan" diberikan arti khusus dalam beberapa bentuk Manajemen Kualitas dan bahwa penggunaan khusus telah diadopsi oleh banyak manajer pemrograman. Sebuah " memperbaiki " hanya sementara solusi atau solusi sedangkan yang benar " solusi " untuk masalah ini memerlukan identifikasi dan penghapusan dari " akar penyebab ". Dalam perangkat lunak bug dapat sesederhana koma salah tempat di mana perbaikan (mengoreksi koma) ADALAH solusinya, tetapi jika bug disebabkan oleh sesuatu yang lebih besar maka perbaikan (mis: loop limiter) tidak akan sama dengan solusi (mendesain ulang / menulis ulang).
OMY

2
@OMY Terima kasih atas penjelasannya. Saya merasa bahwa karena definisi seperti "memperbaiki" tidak digunakan oleh pertanyaan, jawabannya harus menanggapi arti kata yang yang sedang digunakan.
doppelgreener
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.