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. RuntimeException
Dalam 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).