Debugging: Aturan Penting untuk Menyelesaikan Bahkan Masalah yang Paling Sulit Ditemukan (2004)

 (dwheeler.com)
2 poin oleh GN⁺ 2025-01-14 | 1 komentar | Bagikan ke WhatsApp
  • Debugging karya David J. Agans membahas dasar-dasar debugging untuk menemukan penyebab dan memperbaiki bug setelah bug ditemukan, serta menawarkan prinsip-prinsip yang layak ditinjau berulang kali bukan hanya oleh pengembang pemula dan menengah, tetapi juga oleh yang berpengalaman
  • Buku ini terdiri dari 9 aturan yang menghubungkan pemahaman sistem, reproduksi kegagalan, observasi, divide and conquer, kontrol perubahan, audit trail, pemeriksaan asumsi, sudut pandang eksternal, dan verifikasi perbaikan dengan contoh kasus nyata
  • Meski memuat teknologi lama dan contoh di luar komputer, intinya bukan alat tertentu melainkan cara berpikir untuk mempersempit masalah, sehingga dapat diterapkan pada debugging perangkat keras maupun perangkat lunak secara umum
  • Untuk bug yang sulit ditangani seperti masalah intermiten, saran Make it Fail sangat berguna, meskipun ketiadaan pembahasan langsung tentang istilah Heisenbug terasa agak disayangkan
  • Berbeda dari buku yang menjelaskan cara memakai GDB atau menulis pengujian, buku ini berfokus pada gambaran besar debugging, sehingga panduan penggunaan alat dan regresi test perlu dilengkapi dari sumber lain

Masalah yang dibidik buku ini

  • Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems karya David J. Agans membahas proses menemukan penyebab setelah bug terdeteksi lalu benar-benar memperbaikinya
  • Alih-alih berfokus pada teknologi atau alat tertentu, buku ini merangkum prinsip-prinsip debugging yang dibutuhkan oleh pengembang perangkat lunak dan perangkat keras komputer
  • Buku ini sangat cocok untuk pengembang pemula dan menengah, serta tetap berguna bagi yang berpengalaman untuk menghidupkan kembali dasar-dasar yang mudah terlewat saat situasi mendesak
  • Kekuatan buku ini terletak pada kemampuannya memadatkan debugging yang biasanya dipelajari lewat pengalaman menjadi prinsip dan contoh kasus

9 aturan debugging

  • Pahami sistemnya

    • Baca manual, pahami struktur keseluruhan, dan mengerti prinsip dasar serta detail cara kerjanya
    • Periksa juga apa yang ditampilkan alat yang digunakan dan apa yang justru disembunyikannya

  • Buat agar gagal

    • Jalankan kembali masalahnya dan mulai dari awal untuk memicu kondisi kegagalan secara langsung
    • Jangan meniru kegagalannya; picu kegagalan yang sebenarnya, dan temukan kondisi tak terkendali yang menghasilkan bug intermiten
    • Catat semuanya, jangan terlalu percaya pada statistik, dan terima bahwa kejadian langka memang bisa benar-benar terjadi
    • Jangan membuang alat debugging; gunakan alat tersebut untuk menyingkap masalah

  • Berhenti berpikir dan lihat

    • Sebelum memulai perbaikan rumit berdasarkan tebakan, kumpulkan dulu data yang bisa diamati
    • Amati kegagalan dan detailnya, lalu buat instrumentasi internal atau tambahkan instrumentasi eksternal
    • Jangan menghindari penyelidikan mendalam, tetapi waspadai efek Heisenberg, yaitu saat observasi itu sendiri dapat mengubah perilaku sistem
    • Gunakan tebakan hanya sebagai alat untuk mempersempit ruang pencarian, bukan sebagai kesimpulan

  • Gunakan divide and conquer

    • Sempitkan ruang pencarian dengan pendekatan successive approximation, lalu tentukan di sisi mana bug berada
    • Gunakan pola uji yang mudah terlihat, dan mulai dari kondisi yang buruk untuk mempersempit penyebab
    • Singkirkan dulu bug dan noise yang sudah diketahui agar objek investigasi menjadi lebih sederhana

  • Ubah hanya satu hal pada satu waktu

    • Pisahkan faktor inti, dan pahami apa yang salah sebelum memperbaikinya
    • Ubah pengujian juga satu per satu sambil membandingkannya dengan kasus normal
    • Periksa apa yang berubah sejak terakhir kali sistem masih bekerja

  • Pertahankan audit trail

    • Simpan audit trail tentang apa yang dilakukan, dalam urutan apa, dan bagaimana hasilnya
    • Detail yang tampak sepele pun bisa menjadi penyebab, jadi catat peristiwa-peristiwa tersebut sambil menghubungkannya satu sama lain
    • Audit trail dari proses desain juga membantu pengujian, jadi harus dicatat

  • Periksa colokannya

    • Ragukan asumsi yang terasa sudah pasti, lalu periksa kembali dari awal
    • Alat yang dipakai untuk mencari masalah juga harus masuk ke dalam objek pengujian

  • Dapatkan sudut pandang baru

    • Saat buntu sendirian, cari wawasan baru lewat orang lain atau lewat cara penjelasan yang berbeda
    • Menjelaskan masalah bahkan kepada manekin pun bisa membantu merapikan pikiran
    • Manfaatkan keahlian orang lain, dengarkan yang berpengalaman, dan utamakan berbagi gejala serta meminta bantuan daripada gengsi

  • Jika belum diperbaiki, berarti belum benar-benar selesai

    • Setelah melakukan perbaikan, pastikan bahwa masalahnya memang benar-benar teratasi dan verifikasi bahwa perubahan yang dibuat benar-benar menghilangkan akar penyebabnya
    • Masalah tidak hilang dengan sendirinya, jadi yang harus diperbaiki adalah penyebab sekaligus prosesnya

Cara contoh kasus menghidupkan prinsip

  • Jika hanya dilihat sebagai daftar aturan, isinya mungkin terasa kering, tetapi penjelasan rinci dan cerita kasus membawa prinsip-prinsip itu ke situasi nyata
  • Banyak contoh membahas detail teknis secara mendalam, sehingga bagi sebagian pembaca hal ini bisa terasa cukup berat
  • Ada contoh yang membahas teknologi lama, tetapi karena inti buku ini adalah prinsip, bukan teknologi tertentu, itu bukan masalah besar
  • Tidak semua contoh berkaitan dengan komputasi; ada juga contoh menarik tentang instalasi kabel rumah
  • Jika sama sekali tidak memahami perangkat keras dan perangkat lunak komputer, banyak contoh akan sulit diikuti
  • Setelah penjelasan aturan, buku ini melanjutkan dengan kisah yang menerapkan beberapa aturan sekaligus, latihan ringan untuk pembaca, tips helpdesk, dan penutup

Bagian yang paling menonjol dan keterbatasannya

  • Prinsip “Berhenti berpikir dan lihat” sangat penting
    • Karena banyak orang mencoba memperbaiki masalah berdasarkan tebakan sebelum mengumpulkan data untuk membuktikan atau membantah hipotesis mereka
  • “Jika belum diperbaiki, berarti belum benar-benar selesai” juga merupakan prinsip yang sangat membekas
    • Yang harus dipastikan bukan hanya apakah perbaikannya berhasil, tetapi juga apa penyebabnya dan mengapa perbaikannya berhasil
  • Pembahasan “picu kegagalan, jangan meniru kegagalan” tidak sejelas bagian lain dalam buku ini, tetapi tetap layak dipahami
  • Masalah intermiten biasanya yang paling sulit ditangani, dan buku ini memberi saran langsung untuk menanganinya di bagian Make it Fail
  • Heisenberg memang disebut, tetapi istilah yang umum di pengembangan perangkat lunak, Heisenbug, tidak dibahas
    • Heisenbug berarti bug yang menghilang atau berubah perilaku saat diamati atau saat diisolasi

Perbedaannya dengan sumber lain

  • Buku ini berbeda dari manual alat atau buku pengujian karena menempatkan prinsip-prinsip dasar debugging sebagai fokus utama
  • Debugging with GDB: The GNU Source-Level Debugger karya Richard Stallman dan lainnya terutama menjelaskan teknologi atau perintah alat tertentu
  • Ada juga sumber berisi saran umum seperti Guide to Faster, Less Frustrating Debugging karya Norman Matloff, tetapi cakupannya tidak seluas buku Agans
  • Buku pengujian seperti Software Testing Techniques karya Boris Beizer berfokus pada penulisan pengujian untuk menemukan bug, dan relatif lebih sedikit membahas cara memperbaiki bug yang sudah ditemukan
  • Setelah menemukan bug, pengujian untuk bug tersebut seharusnya ditambahkan ke regression test suite, tetapi testing dan regression testing berada di luar cakupan buku ini

Materi pelengkap dan hal yang disayangkan

  • Situs pendamping buku, debuggingrules.com, menyediakan tautan ke informasi terkait dan poster 9 aturan yang bisa diunduh lalu dicetak
  • Cukup disayangkan bahwa daftar lengkap subaturan yang penting untuk memahami aturan-aturan ini tidak dikumpulkan dalam satu halaman di buku maupun situs web
  • Akan lebih berguna jika ada saran dan contoh yang lebih spesifik tentang alat umum dan jenis masalah, seperti symbolic debugger, digital logic probe, atau ddd on gdb
  • Tampaknya juga menarik bila ada buku terpisah yang memperluas aturan yang sama ke pemecahan masalah umum di luar komputasi, tetapi contoh-contoh dalam buku ini terlalu teknis bagi pembaca nonkomputer
  • Prinsip-prinsip dasarnya mungkin tampak jelas di permukaan, tetapi pemula tetap perlu mempelajarinya dan pengembang berpengalaman pun perlu terus diingatkan, dan buku ini cocok untuk proses belajar sekaligus pengingat itu

Bacaan terkait

1 komentar

 
GN⁺ 2025-01-14
Komentar Hacker News

  • Saya rasa godaan paling berbahaya adalah mencoba membuat kode yang rusak berjalan dengan menambahi “perbaikan” di atasnya
    Kode yang sudah rusak terlalu banyak memiliki titik perubahan yang mungkin, sehingga sulit diperbaiki, dan jauh lebih mudah justru merusak kode yang tadinya berjalan
    Jika serangkaian lampu Natal sama sekali tidak menyala, pendekatan mengganti bohlam satu per satu akan gagal bila ada beberapa bohlam yang rusak
    Sebagai gantinya, kita harus mulai dari contoh minimum yang berfungsi, lalu menambahkannya sedikit demi sedikit sampai menemukan titik munculnya error; dalam praktiknya, sering kali memulai ulang dari awal justru menghemat waktu

    • Jika prioritasnya bukan belajar dari masalah itu, mungkin yang paling cepat bukan memeriksa bohlam satu per satu, melainkan mengganti seluruh rangkaian lampu
      Dalam masalah produksi yang sulit ditangkap, pernah ada anggota tim yang menulis ulang rutin bermasalah itu, dan versi hasil tulis ulang ter-deploy lebih dulu sementara yang lain masih debugging
      Setidaknya sekali, karena tidak mungkin terus menghabiskan waktu tanpa batas pada masalah yang “sudah diperbaiki”, bug aslinya akhirnya tidak pernah benar-benar ditemukan

  • Aturan nomor 0 adalah jangan panik
    Tenggat waktu dan pelanggan yang marah menghalangi kejernihan berpikir, jadi manajer yang baik dan dapat dipercaya harus melindungi engineer dari tekanan itu agar mereka bisa fokus menyelesaikan masalah

    • Sangat setuju. Saat on-call SEV-2, kalau para manajer dari tim yang terdampak masuk beramai-ramai dan masing-masing ikut campur, rasanya sangat menyebalkan
      Seorang manajer yang baik memindahkan kami ke panggilan lain dan berkata, “abaikan omongan mereka dan fokus saja, biar saya yang urus,” dan sejak itu rasa hormat saya kepadanya naik drastis
    • Ada cerita di buku bahwa di kapal selam nuklir, ada batang kuningan di depan panel instrumen dan tuas, dan para engineer dilatih untuk tidak langsung menyentuh tuas saat ada masalah, melainkan “berpegangan pada batang itu” terlebih dahulu
    • Pelan itu mulus, dan mulus itu cepat
      Jika tidak ada waktu untuk melakukannya dengan benar, mengapa merasa ada waktu untuk melakukannya dua kali
    • Mantan atasan pernah menyebut perannya sebagai “payung tahi”
      Maksudnya, tugasnya adalah menahan hal-hal yang jatuh dari atas agar para engineer bisa fokus pada pekerjaan utama mereka
    • Prinsip yang mengikuti dari sini adalah selalu punya rencana rollback yang baik
      Jauh lebih baik jika bisa kembali ke versi yang berjalan lalu melakukan debugging tanpa tekanan setingkat krisis

  • Untuk nomor 4, “divide and conquer”, git bisect sangat membantu
    Jika ada satu commit yang diketahui baik dan setelah itu ada puluhan hingga ratusan commit dengan satu commit buruk di antaranya, kita bisa mempersempit commit atau kode bermasalah hanya dalam beberapa langkah
    Contoh penggunaannya ada di https://nickjanetakis.com/blog/using-git-bisect-to-help-find...
    Saat live consulting pada codebase besar yang asing, saya pernah cepat mempersempit masalah dengan cara ini; kalau tidak, cakupan hal yang mungkin rusak akan terlalu luas

    • Karena git bisect, saya menjaga disiplin bahwa semua commit yang masuk ke branch “nyata” harus bisa di-build secara mandiri, lulus semua pengujian yang saat itu diketahui, dan sejauh pengetahuan yang ada harus layak di-deploy
      Saya menganggap ini lebih penting daripada prinsip menyimpan setiap penekanan tombol atau mempertahankan sampai commit “Fixes.” terakhir. Prinsip-prinsip seperti itu membuat pencarian biner menjadi tidak berguna
      Saya memang tidak sering memakainya, tetapi untuk bug paling besar dan misterius, cukup sekali kena dengan tepat sudah bisa memberi petunjuk setara beberapa hari kerja, jadi sangat sepadan
    • Saat debugging masalah konfigurasi jaringan pada 1990-an, rekan kerja yang lebih berpengalaman mengajarkan prinsip umum di balik git bisect
      Caranya adalah membandingkan sistem yang rusak dengan sistem yang berfungsi lalu secara sistematis menghilangkan perbedaannya untuk menemukan cacat
      Ini bisa diterapkan bukan hanya pada software atau hardware, dan dulu saat saya punya dua jet ski yang sama, sangat membantu karena saya bisa memperbaiki satu sambil membandingkannya dengan yang lain
    • Inti di sini lebih pada prinsip pencarian biner yang lebih umum daripada git bisect itu sendiri
      Ini bisa dipakai bukan hanya pada rentang commit, tetapi juga saat membagi ruang sistem
      Misalnya, jika workflow 10 langkah rusak, kita bisa mengecek apakah langkah ke-5 masih normal, atau mempersempit apakah ini bukan masalah hardware atau justru memang masalah hardware
      Ini terutama penting ketika penyebab masalah mungkin bukan commit kode di repositori yang sedang Anda bisect sekarang
    • bisect memang luar biasa, tetapi kita perlu membedakan “aturan” sebagai filsafat dan cara berpikir buku ini dari “alat” sebagai saran praktis
      Orang yang memulai dari “alat apa yang harus saya pakai” berada pada posisi yang kurang menguntungkan dibanding orang yang memulai dari “bukankah ini dulu pernah berjalan?”
      Dunia penuh dengan alat, dan jika mencoba menyimpan semuanya di kepala Anda bisa jadi gila, jadi lebih baik menerima filsafatnya lebih dulu
    • Saya tambahkan tulisan tentang git bisect run. Ini alat kecil yang benar-benar luar biasa
      https://andrewrepp.com/git_bisect_run

  • Kita harus memastikan sedang mengedit file yang benar di mesin yang benar

    • Ini variasi dari “periksa colokannya”
      Zaman sekarang, saya selalu menambahkan sementara satu baris yang memunculkan fatal error untuk memastikan file yang saya pegang memang benar, dan tergantung situasinya, bahkan memastikan barisnya juga benar
    • Hanya Tuhan yang tahu berapa banyak waktu terbuang karena mengedit file hasil generate, file dengan versi berbeda, atau lupa menyimpan perubahan
    • Prinsip terbesar yang selalu saya katakan pada diri sendiri dan orang yang saya ajar adalah memastikan bahwa kode yang sedang dijalankan benar-benar kode yang saya kira sedang dijalankan
    • Karena itu, pertama-tama kita harus membuatnya rusak dengan cara yang berbeda
      Tujuannya untuk memastikan perubahan saya benar-benar memberi pengaruh

  • Ada aturan tambahan
    “Ini semua salah saya”: mungkin saja ini bug compiler atau kesalahan perangkat keras, tetapi itu sangat jarang, jadi yang pertama harus dicurigai adalah perubahan pada kode saya sendiri
    “Kalau menemukan bug, cari juga keluarga dan teman-temannya”: perlu memikirkan dan memeriksa di mana lagi hal sejenis bisa terjadi
    “Optimalkan untuk pengguna terlebih dahulu, programmer pemeliharaan kedua, dan komputer terakhir”

    • Aturan pertama dikenal di The Pragmatic Programmer sebagai “select tidak rusak”
      Ringkasannya ada di https://blog.codinghorror.com/the-first-rule-of-programming-...
    • Pendekatan “mari buat test case yang bisa dilaporkan ke mailing list karena mungkin ini memang bug” juga kadang berguna
      Biasanya saat menyederhanakan kode yang memunculkan error menjadi kasus yang lebih sederhana, saya justru menemukan bug dalam logika saya sendiri
      Sekali dua kali, hasil akhirnya memang layak dilaporkan ke developer, dan umumnya itu library dengan kurang dari beberapa ratus pengguna sehingga pengujiannya tidak banyak
    • Saya selalu punya pola pikir “ini salah saya”, tetapi jujur saja rasanya memalukan ketika workstation Linux saya terus crash karena i9-13900K
      Pada akhirnya saya sangat lega mengetahui bahwa itu masalah CPU, bukan error kode yang tampak mustahil
    • Lebih sehat mengasumsikan bahwa kode saya yang salah
      Meski begitu, yang terbaik adalah memastikan dengan melakukan pencarian biner pada rantai sebab-akibat beberapa kali lagi
    • Terkait “keluarga dan teman”, ada beberapa kali bug yang saya cari justru terungkap saat memperbaiki masalah kecil di sekitar yang tampak tidak berkaitan

  • Nasihat “Pahami sistem: baca manual, baca semuanya dengan mendalam, ketahui dasar-dasarnya, ketahui roadmap-nya, pahami alatnya, dan cari detailnya” terdengar agak aneh
    Kalau ada bug di kode, ini terdengar seperti menyuruh kita membaca dulu seluruh manual 700 halaman dari library yang dipakai, membaca 7 buku terkait, lalu baru melihat bug itu satu-dua bulan kemudian
    Saya penasaran apakah benar ada satu pun programmer yang benar-benar mengikuti nasihat ini

    • Tulisan ini dibuat pada 2004, tahun saat Google IPO
      Atwood dan Spolsky baru membuat Stack Overflow pada 2008, dan itu masa ketika orang mengenal buku dengan nama seperti “Camel book” dan memang sudah menyimpan pengetahuan itu begitu saja
      0. https://stackoverflow.blog/2021/12/14/podcast-400-an-oral-hi...
      1. https://www.perl.com/article/extracting-the-list-of-o-reilly...
    • Di sini tampaknya maksudnya sedikit berbeda
      “baca semuanya dengan mendalam” tidak harus berarti “baca dulu seluruh manual 700 halaman dari library yang dipakai”
      Kalau ada masalah pada git bisect, alih-alih menempelkan beberapa potongan Stack Overflow, kita bisa memahami topik itu sedikit lebih dalam dari https://git-scm.com/docs/git-bisect
    • Pada dasarnya ini benar
      Hanya saja, keliru kalau menganggap hasil kerja beberapa bulan itu sekadar menambal satu bug dengan asal
      Tujuannya adalah benar-benar memperbaiki sebanyak mungkin bug dari jenis itu, dan bahkan berhenti menulisnya sejak awal
      Alternatifnya adalah terjun seperti pasukan terjun payung ke sistem yang tidak dikenal, mengutak-atik sana-sini tanpa memahaminya, lalu mengirim PR saat tes berubah hijau sambil berharap tidak membuat keadaan lebih buruk; melakukan itu sebagai rutinitas sehari-hari nyaris seperti mimpi buruk
      Tambahan lagi, kalau manual library yang Anda pakai panjangnya 700 halaman, besar kemungkinan Anda memakai library yang salah

  • Sebagai langkah ke-10, bukankah bug itu sebaiknya ditambahkan ke tes CI untuk mencegah regresi
    Perlu dipastikan bahwa sebelum perbaikan CI gagal, dan setelah perbaikan CI lolos

    • Di proyek pure JavaScript terbesar yang pernah saya kerjakan, sekitar 150 ribu baris kode, aturan ini ada dan benar-benar menyelamatkan hidup
      Terutama karena ada commit yang usianya lebih dari 5 tahun, dan karena itu komponen/library, ada cukup banyak hack aneh untuk IE
    • Saya tidak menganggap ini selalu sepadan
      Beberapa tes butuh waktu lama atau rumit untuk ditulis dan juga perlu dipelihara, dan kita juga harus menerima bahwa kumpulan tes tidak memeriksa semua kondisi batas
      Ini bisa berarti bug yang sudah sampai ke produksi bisa muncul lagi, tetapi kalau itu sekadar kesalahan sederhana, belum tentu peluang terulangnya lebih tinggi daripada ratusan kesalahan potensial lain
      Pada akhirnya ini tergantung konteks, dan menulis tes bukanlah sesuatu yang gratis
    • Lebih umum lagi, ini harus didokumentasikan
      Saya tak terhitung berapa kali melihat akar masalah yang dalam aktif lagi dan memunculkan masalah yang sama, atau tidak ada yang tahu bahwa saya sudah memperbaikinya sehingga semua orang terus memakai workaround seolah bug itu masih ada
      Bahkan setelah mencapai “Sudah diperbaiki!”, meninggalkan catatan singkat dan analisis akar masalah akan membantu orang lain
    • Bagaimana dengan tes perbaikan bug yang sudah berumur beberapa tahun
      Setelah tes menumpuk lama, seberapa cepat CI masih bisa dijalankan, dan apakah tetap masuk akal untuk terus menyimpannya dalam jangka panjang

  • Jika ingin menanamkan pola pikir seperti ini kepada anak-anak, diri sendiri, atau orang lain, setidaknya saya merekomendasikan yang berikut
    The Martian by Andy Weir https://en.wikipedia.org/wiki/The_Martian_(Weir_novel)
    https://en.wikipedia.org/wiki/Zen_and_the_Art_of_Motorcycle_...
    https://en.wikipedia.org/wiki/The_Three-Body_Problem_(novel)
    To Engineer Is Human - The Role of Failure in Successful Design By Henry Petroski
    https://pressbooks.bccampus.ca/engineeringinsociety/front-ma...
    https://en.wikipedia.org/wiki/Surely_You%27re_Joking,_Mr._Fe...!

    • Setuju. Zen and the Art of Motorcycle Maintenance menurut saya paling baik menangkap seni pemecahan masalah
      Terutama konsep “gumption traps” yang sangat bagus
      Jika terjebak dalam perangkap kekakuan nilai, kita pada akhirnya memang akan melambat, jadi kita perlu sengaja memperlambat diri, meninjau kembali tempat-tempat yang sudah kita lewati, dan memastikan apakah hal-hal yang kita anggap penting benar-benar penting
      Hanya menatap mesin sejenak pun bukanlah hal yang salah, dan ada bagian yang mengatakan bahwa jika kita mengamatinya seperti melihat tali pancing, akan datang saat ketika satu fakta kecil dengan hati-hati bertanya apakah kita tertarik; itu terasa hampir seperti pedoman hidup
    • Saya tidak mengerti bagian mana dari Three Body Problem yang berkaitan dengan debugging, pemecahan masalah, atau perencanaan
      Peristiwa-peristiwanya seolah begitu saja terjadi lewat lompatan logika yang kasar, dan menurut saya itu lebih mendekati fantasi yang ditutupi celoteh sains yang sebenarnya sangat tipis

  • Beberapa tahun lalu saya pernah menulis artikel serupa. Saat itu saya belum membaca buku asli yang disebutkan di sini
    https://explog.in/notes/debugging.html
    Zine debugging karya Julia Evans juga sangat bagus: https://wizardzines.com/zines/debugging-guide/

  • Bahkan setelah berhasil melakukan debugging, pekerjaan belum selesai
    Inti dari “Three Questions About Each Bug You Find” <http://www.multicians.org/thvv/threeq.html> adalah tiga hal
    Apakah kesalahan ini juga ada di tempat lain, bug berikutnya apa yang bersembunyi di balik bug ini, dan apa yang harus dilakukan untuk mencegah bug seperti ini