Apa yang harus dilakukan ketika Anda telah menghabiskan semua jalan untuk memperbaiki bug

Saya seorang Junior Programmer (4 bulan pengalaman karir sejauh ini) bekerja pada Aplikasi Mobile Cross Platform (tim 1 orang - jadi saya sendiri).

Saya memiliki bug dalam program / aplikasi ini yang cukup besar (30 file header berbeda, masing-masing dengan file cpp mereka sendiri juga). Saya telah mencoba melacak apa yang sebenarnya terjadi dengan bug & juga untuk memperbaikinya (bahkan mencoba menggunakan beberapa peretasan untuk membuatnya berfungsi) tetapi dari sekitar selusin atau lebih solusi (ide yang saya miliki tentang apa yang menyebabkan masalah ) Saya telah menemukan apa yang membuat saya melacak apa bug itu atau memperbaiki bug tersebut.

Apakah Anda punya saran untuk programmer junior tentang beberapa teknik luas (jalan, cetak semua kode saya di atas kertas & lalui dengan pena, dll.) Saya bisa gunakan untuk membantu saya dengan bug ini?

Untuk memberikan sedikit lebih banyak konteks untuk bug saya; itu melibatkan lintas platform API Mosync, ketika saya melakukan urutan tindakan tertentu, layar saat ini tidak menggambar ulang (& tampaknya) bahwa layar yang ditampilkan sebelumnya masih menerima pointer / peristiwa pers kunci & bukan layar saat ini.

Urutan spesifik:
- Layar Menu Ditampilkan - klik "Tampilkan tombol pesanan sebelumnya"
- Layar Pesanan Sebelumnya Ditampilkan - klik "Muat file" lalu klik tombol menu & buka Layar
Pengiriman - Layar Pengiriman Ditampilkan - klik tombol menu & buka Layar
Pembelian - Layar Pembelian Ditampilkan - Kesalahan di sini, input ke layar ini tidak ditampilkan / tidak bereaksi, ListViews tidak gulir, tombol tidak bereaksi terhadap klik, sel ListView tidak menanggapi klik

Saya juga ingin sepasang mata yang berbeda memeriksa pekerjaan saya & menunjukkan bug, tetapi seperti yang saya katakan saya adalah tim 1, bos saya mengarahkan saya, dia memiliki perusahaan & memiliki ide untuk aplikasi tetapi tidak tidak tahu c ++ atau bahasa terbaru apa pun (kobal? Saya pikir semua). Adakah saran tentang cara mendapatkan sepasang mata kedua tanpa melanggar / memamerkan kode / properti intelektual perusahaan?

... dan tidak meninggalkan magang yang dibayar ini bukanlah suatu pilihan, kontrak mengatakan jika saya pergi sebelum 6 juta dari kontrak 12 juta saya mungkin dapat membayar 30% dari gaji tahunan saya

Jika Anda dapat mereproduksi masalah 100% dari waktu, atur titik istirahat pada langkah terakhir (sedini mungkin). Jika Anda berjalan melalui seluruh tumpukan panggilan, saya cukup yakin Anda akan datang ke beberapa nilai tak terduga di suatu tempat, atau sesuatu yang harus dipanggil tetapi tidak.

Edit:

Dan jika Anda duduk di ujung akal Anda mencoba untuk memperbaiki bug dan posting di sini berharap bahwa Anda akan mendapatkan beberapa saran yang bersinar, pergi . Jernihkan kepalamu dan kembali lagi nanti (sebaiknya besok atau setelah akhir pekan). Ada banyak waktu yang saya habiskan sepanjang hari mencari solusi untuk masalah tertentu hanya dengan berjalan kaki, kembali keesokan harinya dengan pikiran jernih dan menemukannya dalam sepuluh menit.

Debugging lebih tentang mengisolasi dan memahami apa masalah itu (dibandingkan dengan menerapkan perbaikan)

Satu hal yang perlu diperhatikan saat debugging adalah jika Anda mulai melihat bahwa Anda mengejar teori yang berbeda karena hal ini sering kali membutuhkan waktu yang lebih lama dan tidak secara sistematis menghilangkan kemungkinan masalah.

Biasanya cara terbaik untuk men-debug situasi semacam ini adalah pendekatan sistematis yang membosankan dengan memecah sistem Anda menjadi potongan-potongan kecil dan membuat masing-masing bagian bekerja secara terpisah dan terus menambahkan setiap elemen kompleksitas satu per satu hingga rusak. Maka Anda telah mengisolasi masalah yang sebenarnya. Cara ini mungkin tampak sedikit membosankan dan beberapa pekerjaan dimuka tetapi menghapus variabel dan menjaga otak Anda waras saat mencoba men-debug perangkat lunak yang kompleks.

Ini hanya beberapa hal yang telah saya lakukan di masa lalu, jelas mereka tidak akan bekerja di setiap situasi:

1. Sadarilah bahwa itu hanya kode, dan di suatu tempat ada bug (bukan hanya ilmu hitam) yang BISA Anda perbaiki.
2. Istirahat.
3. Langkah melalui kode sangat lambat, menganalisis setiap langkah dan memastikan Anda memahaminya dan apa yang dilakukannya, tidak mengabaikan apa pun.
4. Dapatkan sepasang mata kedua untuk melihat masalahnya.
5. Pergilah tidur dan lupakan itu sampai besok (jernihkan kepalamu), datanglah dengan perspektif yang segar).
6. Cetak kode Anda, dan analisis setiap baris, buat catatan di margin, pahami setiap implikasi dari setiap baris
7. Jika itu bukan bug yang kritis, tetapi menyebabkan kesalahan yang tidak perlu diketahui oleh pengguna, saya (malu-malu, tetapi jujur) telah menjebak bug itu, dan menelannya ! Jika tidak berbahaya, dan Anda tidak dapat menemukan penyebabnya, kadang-kadang Anda hanya menjebaknya dan tidak memberi tahu pengguna apa pun yang terjadi. Ini semua tentang ROI untuk klien, dan terkadang itu tidak sepadan.
8. Katakan bug itu secara lisan bahwa Anda akan memburu dan membunuhnya. Terkadang itu akan lari. :-)

Saya biasanya memiliki pendekatan ini ketika menyelesaikan bug.

1. Buat langkah demi langkah yang bagus untuk mereproduksi bug
2. Sederhanakan langkah demi langkah
3. Di mana dalam kode tempat bug itu terjadi? Seperti apa fungsi yang terlibat?
4. Apa jalur yang dipilih kode ketika bug terjadi, callchain.
5. Fokus pada lokasi, kapan tidak apa-apa, kapan tidak. Kemudian ulangi ini sampai Anda menemukan tempat di mana kesalahan terjadi.
6. Mengapa ini terjadi?

Pada titik ini biasanya agak jelas apa yang telah terjadi karena saya belajar banyak dalam proses fokus pada masalah sehingga saya tahu apa yang harus dilakukan. Atau saya punya pertanyaan yang cukup fokus yang bisa saya tanyakan di forum.

Lalu saya mencoba untuk memperbaiki masalah, dan gunakan langkah demi langkah yang Anda buat di langkah pertama untuk memverifikasi apakah bug sudah diperbaiki.

Semua saran sebelumnya sangat bagus, dan sebagian besar ditujukan untuk memverifikasi asumsi tentang bug / kesalahan dan kemudian mengikuti proses debug untuk menemukan kesalahan (kadang-kadang dengan memeriksa lingkungan sekitar bug dan kadang-kadang langsung dalam kode).

Pendekatan ini tidak akan selalu berhasil, terlepas dari bergantung pada senioritas atau keahlian Anda. Terkadang Anda hanya perlu satu set mata pada masalah. Temukan seseorang untuk meninjau masalah atau sesi debugging dengan Anda - sering hanya berbicara melalui kode akan membawa Anda ke kesalahan.

Seperti yang dikatakan orang lain 1) dapat mereproduksi dengan andal, dan 2) melangkah maju dalam debugger hingga ke titik di mana hal itu terjadi.

Jika saya tidak dapat melakukan itu, untuk alasan apa pun, saya memiliki dua metode lain yang keduanya memerlukan versi kode yang berbeda yang tidak menunjukkan bug.

1. Jalankan kedua versi kode secara berdampingan di bawah debugger. Ikuti mereka sampai yang jahat melakukan sesuatu yang berbeda dari yang baik.

2. Bergantian menjalankan versi kode yang baik dan buruk. Memiliki perbedaan atau beberapa daftar perbedaan antara versi. Kemudian secara bertahap ubah kode dari salah satu versi untuk membuatnya lebih cocok dengan yang lain. Jika yang buruk menjadi baik, atau yang baik menjadi buruk, saya mundur dari perubahan dan membuat perubahan yang lebih kecil. Dengan cara ini saya pulang dengan bug. Saya menganggapnya sebagai "mendapatkan kedua sisi masalah dan bekerja menuju pusat". Metode ini tidak memerlukan debugger.

Jika masalah sulit untuk mereproduksi, maka saya perlu informasi sebanyak yang saya bisa, seperti dump stack, ketika tidak terjadi. Jadi saya memastikan saya bisa mendapatkan diagnosa itu, menunggu masalah terjadi, dan berharap saya mendapat informasi yang cukup untuk menemukannya.

Jika Anda ditugaskan untuk melakukan pekerjaan di tangan sebagai programmer junior, setidaknya ada satu orang yang percaya bahwa Anda mampu menangani semuanya sendiri.

Kemudian, sebelum meminta bantuan dari atasan Anda, tulis di kertas bekas, daftar langkah / metode yang Anda ambil dalam melacak bug, seberapa jauh Anda melanjutkannya, mengapa Anda menyerahkan setiap metode, dan apa yang telah Anda pelajari dalam setiap upaya. Juga, rangkum apa yang telah Anda pelajari tentang proyek sejauh ini.

Kemungkinannya adalah, ketika Anda selesai menulis ini, apa yang bisa dilakukan harus menjadi sangat jelas. Jika ya, Anda hanya harus mengikuti apa yang terungkap sendiri untuk mereproduksi bug, dan, coba perbaiki. Jika tidak, Anda memiliki landasan di mana Anda dapat berbicara dengan atasan Anda. Jika Anda meminta bantuan mereka tanpa menunjukkan apa yang telah Anda lakukan, mereka mungkin mendapat kesan negatif pada Anda.

Tetapi, jika Anda menjernihkan pikiran, kembali setelah akhir pekan, Anda mungkin bisa menyelesaikannya dalam waktu singkat, tanpa bantuan siapa pun. Itu terjadi, setiap saat.

Kita perlu tahu betapa sulitnya mereproduksi, karena metodenya sangat berbeda. Untuk cacat yang direproduksi dengan andal, otomatisasi yang menyebabkan cacat. Gunakan debugger dan jejak debug (jejak memiliki dampak paling kecil pada cacat jenis ras). Dapatkan metodis. Selangkah demi selangkah, setiap langkah memberikan lebih banyak informasi, bahkan itu mengkonfirmasikan apa yang sudah Anda ketahui. Jika Anda mendapatkan hasil yang mengejutkan, hentikan, pahami 100% sebelum melanjutkan. Ini sangat lambat, tetapi selalu membuat Anda sampai pada hasil akhir jika Anda memberikan waktu yang cukup.

Jika Anda tidak dapat membuat ulang, maka Anda memiliki masalah, bagaimana Anda mengonfirmasi bahwa Anda telah memperbaikinya. Masukkan kode debug dan tinggalkan di sana. Akhirnya, tanyakan pada diri sendiri, apakah "Ditutup: DNR" adalah opsi yang valid? (Tidak / Tidak bisa membuat ulang). Dalam bisnis, akhirnya itu adalah keputusan biaya / manfaat.

Jangan menganggap perpustakaan Anda benar, konfirmasikan itu.

Beristirahatlah, bersikaplah pragmatis tentang biaya yang perlu diperbaiki, dan yang terpenting, minta orang lain untuk duduk di samping Anda dan membantu.

Banyak jawaban bagus di sini. Beberapa tips lainnya:

UI jarang hidup dalam isolasi. Buat program pengujian dengan sekumpulan fitur minimal yang diperlukan untuk mereproduksi bug. Jika UI dirancang dengan baik, Anda harus dapat memisahkan komponen UI yang gagal, dan menjalankannya secara terpisah dalam program pengujian. Masih bisakah Anda mereproduksi masalahnya? Jika demikian, masalahnya kemungkinan ada pada struktur atau kerangka UI Anda. Periksa struktur UI Anda - terutama perhatikan elemen yang tidak terlihat. Coba pelajari dengan tepat apa yang terjadi ketika Anda mengklik ListView itu dan tidak merespons - penangan acara apa yang dipanggil? Ingatlah, mungkin ada bug dalam kerangka UI itu sendiri - jangan langsung sampai pada kesimpulan itu, tetapi jangan mengesampingkannya langsung. Tes cepat adalah untuk meningkatkan versi Mosync Anda dan memeriksa apakah gejalanya ada.

Gagal itu: Apa yang tersisa dalam program pengujian Anda? Memahami semua komponen yang tersisa, terutama semua thread yang berjalan. Sesuatu melakukan pemeliharaan basis data di latar belakang? File spooler atau sejenisnya? Kode pemantauan perilaku pengguna NSA? Apakah UI berfungsi dengan beberapa komponen ini (mungkin di belakang layar)? Operasi latar belakang apa yang diandalkan oleh UI?

Saat Anda membaca kode - yang seharusnya menghabiskan banyak waktu, mengingat kesulitan dalam bug - perhatikan beberapa praktik buruk yang dapat mengaburkan bug Anda. Secara khusus, apakah Anda melihat semua ini?

try {
    SaveTheWorld();
} catch (std::exception& ex) { /* oh it didn't work, let's just ignore it */ }

Itu praktik yang sangat buruk dan karenanya cukup lumrah (hei lihat itu tidak crash!). Pastikan Anda memutakhirkan kode apa pun yang melakukan itu untuk setidaknya mencatatnya - sebaiknya hapus penanganan kesalahan seluruhnya. (Aturan praktisnya adalah bahwa jika Anda tidak tahu apa pengecualiannya, Anda tidak siap untuk menanganinya.) Jika berinteraksi dengan API gaya-C, perhatikan penurunan nilai kode pengembalian, dan pastikan bahwa Anda memeriksa informasi status kesalahan dari alat apa pun yang berinteraksi dengan Anda.

Melihat bagaimana program pengujian Anda sekarang menangani kegagalan dengan benar, dan Anda telah membaca log yang telah Anda hasilkan, tetapi tetap tidak ada yang menyoroti bug, cari antarmuka yang dapat Anda selidiki. Apakah ada transaksi jaringan yang harus terjadi di bawah perlindungan? Jika demikian, pukul dengan Wireshark. Transaksi basis data? Coba beberapa penebangan kueri, atau memeriksa status server database. Filesystem atau jaringan berbagi dipukul? Periksa file perantara, atau gunakan debugger untuk melacak I / O. Perangkat Keras I / O? Monitor dan selidiki. Bersikap empiris. UI mungkin dapat ditutup pada beberapa operasi latar belakang yang belum Anda antisipasi.

Terakhir: Jangan panik. Tetap tenang, dan pantau apa yang telah Anda coba. Jika Anda masih tidak dapat menemukannya, itu harus menjadi "masalah yang diketahui" untuk dilacak pada hari hujan. Anda akan ingin banyak bahan untuk membenarkan keputusan itu jika harus seperti itu.

Dalam skema ini, bug yang dapat direproduksi (relatif) mudah! Mengapa? Karena Anda selalu dapat meretas kode ke minimum sampai bug hilang, dan kemudian bekerja kembali untuk mencari tahu kode apa yang menyebabkannya. Jadi itu satu metode. Ini direproduksi, Anda memiliki makhluk di sana di bawah kendali Anda. Anda dapat menyodoknya, dan bereksperimen dengannya. Anda bahkan dapat membedahnya jika Anda mau.

Tujuan pertama Anda adalah untuk memahami mengapa bug terjadi dalam kode Anda . Jangan mencoba memperbaikinya pada awalnya. Cobalah untuk memahaminya . Jika Anda mencoba memperbaikinya tanpa memahaminya Anda akan meretas dan kemungkinan akan memperkenalkan utang teknis , bahkan jika Anda menyelesaikannya.

Langkah melalui perilaku aplikasi, baris demi baris. Perhatikan nilai variabel. Perhatikan aliran kontrol. Di mana perilaku itu pertama kali menyimpang dari apa yang menurut pemahaman Anda kepada Anda bahwa itu seharusnya? Apakah Anda mengerti bagaimana sistem operasi mengirimkan acara ke aplikasi Anda? Jika Anda terhambat oleh masalah "kotak hitam", dapatkah Anda mendapatkan sumber untuk pustaka / kerangka kerja yang dikompilasi, memungkinkan Anda untuk melangkah lebih jauh jika Anda harus melakukannya?

Apakah Anda memiliki komit di sistem kontrol versi Anda yang tidak menghasilkan bug ini? (Anda menggunakan kontrol versi bukan?) Jika Anda memiliki komit seperti itu, maka Anda dapat melakukan pencarian biner pada riwayat untuk mencari tahu di mana bug itu diperkenalkan.

Tujuan Anda seharusnya adalah (1) memahami - menentukan penyebab dan untuk itu, mencoba (2) memeriksa, memahami perilaku aplikasi secara terperinci (3) mengisolasi masalah dengan membuatnya pergi lalu memeriksa dan memahami delta yang memungkinkan Anda untuk melakukan itu

Tapi jelas jangan duduk di sana selama berminggu-minggu jika Anda benar-benar terjebak. Anda harus memberi tahu seseorang di organisasi Anda juga. Mintalah bantuan di mana Anda bisa dan melewati titik tertentu, tentu saja Anda wajib memberi tahu manajemen bahwa Anda merasa telah mengalami hambatan untuk maju. Tetapi Anda mungkin akan dapat menyelesaikan ini jika Anda menekannya dari sejumlah sudut pandang yang berbeda, semuanya terfokus pada pembelajaran dan pemahaman.