Keuntungan:
- Kemampuan untuk dengan cepat mempersempit kemungkinan akar penyebab dengan memberikan catatan kerusakan (pelacakan tumpukan) ke kecerdasan buatan dengan kode dan konteks skenario yang relevan
- Kemampuan untuk menyelesaikan akar masalah secara permanen daripada memvalidasi diagnosis AI sebagai hipotesis dalam kode dan menguji serta membungkam gejalanya
- Melindungi privasi saat melakukan debug dengan menutupi data pribadi dalam catatan dan log kerusakan
Setiap aplikasi memberikan kesalahan; Yang membedakan developer yang baik adalah seberapa cepat mereka menemukan dan memperbaiki bug. Proses debug seluler — menemukan dan memperbaiki sumber masalah — sangat sulit karena kesalahan terjadi pada perangkat pengguna, di lingkungan yang tidak dapat Anda lihat. Seringkali, yang Anda miliki hanyalah log kerusakan (log kerusakan / pelacakan tumpukan — rincian teknis ke mana perginya aplikasi saat mogok). AI sangat hebat dalam membaca catatan rahasia ini, membuat daftar kemungkinan penyebabnya, dan mengusulkan solusi. Dalam unit ini kita akan mempelajari cara menggunakan AI sebagai “detektif bug” tetapi memberi Anda tanggung jawab untuk memverifikasi diagnosis akhir dan perbaikannya.
Membaca log kerusakan: Saat AI bersinar paling terang
Log kerusakan adalah teks yang panjang dan menakutkan; pengembang yang tidak berpengalaman tidak akan tahu di mana mencarinya. AI menguraikan teks ini dalam hitungan detik: di baris mana teks tersebut mogok, pengecualian mana yang diberikan, apa kemungkinan alasannya. Kesalahan seluler yang umum terlihat jelas dan AI mengenalinya dengan cepat: NullPointerException (mencoba mengakses nilai nol), IndexOutOfBoundsException (mengakses elemen daftar yang tidak ada) di Android, EXC_BAD_ACCESS (mengakses memori yang dibebaskan) di iOS, tiba-tiba menemukan nihil (memaksa nihil opsional).
Jenis kerusakan seluler yang paling umum dan penyebab umumnya adalah sebagai berikut:
Kesalahan (pengecualian)
Peron
penyebab khas
NullPointerException
Android
Mengakses nilai nol
IndexOutOfBoundsException
Android
Mengakses elemen daftar yang tidak ada
tiba-tiba ditemukan nihil
iOS
Memaksa membuka bungkus nihil opsional (!)
EXC_BAD_ACCESS
iOS
Mengakses memori yang dibebaskan
ANR/membekukan
Android
Pemrosesan yang panjang/berat pada thread utama
Alur proses debug langkah demi langkah:
- Kumpulkan catatannya. Kumpulkan log kerusakan, pesan kesalahan, dan langkah-langkah untuk mereproduksinya jika memungkinkan.
- Berikan konteks AI. Beri tahu saya bukan hanya kesalahannya, tetapi juga bagian kode yang relevan dan apa yang menyebabkan error tersebut.
- Tanyakan kemungkinan penyebabnya. “Beri tahu saya 3 penyebab yang paling mungkin dan cara memverifikasi masing-masing penyebab tersebut.”
- Memeriksa. Konfirmasikan alasan yang diajukan dalam kode dan pengujian; Jangan memperbaikinya dengan menebak-nebak.
- Perbaiki dan uji lagi. Periksa apakah kesalahan sudah benar-benar hilang dan tidak ada kesalahan baru yang dihasilkan.
Tip: Saat memberikan log kerusakan ke AI, sertakan juga cuplikan kode yang relevan. Hanya dengan pelacakan tumpukan AI membuat prediksi umum; Saat Anda melihat kodenya, kemungkinan menemukan garis yang tepat dan penyebab sebenarnya meningkat pesat. Konteks menentukan kualitas diagnosis.
Perangkap data pribadi
Log kerusakan dan log sering kali berisi data pengguna: email, ID pengguna, lokasi, bahkan konten formulir. Menempelkan catatan ini ke AI sebagaimana adanya berarti membocorkan data pribadi kepada pihak ketiga dan merupakan pelanggaran terhadap KVKK/GDPR. Bersihkan (tutupi) area pribadi sebelum mengirimkan rekaman. Selain itu, berhati-hatilah untuk tidak menulis data pribadi ke log aplikasi Anda dari awal; Log yang baik menjelaskan masalahnya tetapi tidak mengungkapkan identitasnya.
Perhatian: Perbaikan yang disarankan oleh AI mungkin “membungkam bug” tetapi mungkin tidak menyelesaikan akar masalahnya. Misalnya, membungkus NullPointerException dengan tanda centang null akan menghentikan kerusakan, namun jika Anda tidak mengetahui alasan nilainya null, kesalahan logika sebenarnya akan terus berlanjut. Obati penyakitnya, bukan gejalanya.
Analisis akar permasalahan
Tujuan dari debugging profesional bukan untuk membungkam kesalahan tetapi untuk menemukan akar permasalahannya. Saya bertanya kepada AI "mengapa ini bisa menjadi null, di mana bisa hilang dalam aliran data?" bertanya, “bagaimana cara membungkam ini?” Ini jauh lebih berharga daripada meminta. Setelah akar permasalahan ditemukan, lusinan variasi kesalahan yang sama diselesaikan sekaligus. AI ahli dalam penalaran rantai ini: ikuti data dari masukan ke keluaran dan mintalah untuk memikirkan di mana kerusakannya.
tiga kasus mini
Kasus 1 — 2 jam kerja dalam 10 menit. Seorang pengembang menghabiskan waktu 2 jam untuk mencari bug yang hanya mogok pada model Samsung tertentu. Memberikan log kerusakan (membersihkan area pribadi) ke AI; YZ mengatakan bahwa kesalahan tersebut menunjuk pada kelebihan memori yang terjadi dengan resolusi kamera yang berbeda pada perangkat tersebut. Dengan petunjuk tersebut, alasannya ditemukan dalam 10 menit. AI mempercepat pencarian, manusia memverifikasi solusinya.
Kasus 2 — Bug yang dibungkam kembali muncul. Satu tim membungkam kerusakan yang berulang dengan menggunakan saran AI untuk mencoba menangkapnya. Kerusakan berhenti, tetapi pengguna mulai mengeluh bahwa "data tidak disimpan"; karena masalah sebenarnya (koneksi database) masih ada, hanya menjadi tidak terlihat. Setelah akar permasalahan ditemukan, kerusakan dan kehilangan data dapat diatasi. Pelajaran: membungkam bukanlah solusi.
Kasus 3 — Data bocor di log. Audit menemukan bahwa nama lengkap dan nomor telepon pengguna ditulis ke dalam log kerusakan aplikasi. Pengembang secara rutin menempelkan log ini ke AI dan memperbaiki bug; Jadi data pribadi telah keluar selama berbulan-bulan. Log ditutupi dan prosesnya diperbaiki. Pelajaran: kerahasiaan berlaku bahkan saat melakukan debug.
Perintah lemah / Perintah kuat
Prompt yang buruk: "Mengapa kesalahan ini terjadi? [stack trace]"
Prompt yang kuat: "Kerusakan ini terjadi di aplikasi Android saya. Konteks: - Saat melakukan: pengguna menambahkan ke keranjang dari detail produk - Hanya di beberapa perangkat, model RAM rendah - Kode terkait: [ViewModel dan bagian Repositori] - Log kerusakan (data pribadi dihapus): [pelacakan tumpukan] Cantumkan 3 akar penyebab yang paling mungkin. Untuk masing-masing: 1) Bagaimana cara memverifikasi, 2) Perbaikan permanen (bukan membungkam). Nyatakan asumsi Anda jika Anda tidak yakin."
Templat yang dapat disalin
Templat analisis kerusakan: "Analisis kerusakan berikut. Konteks: [apa yang Anda lakukan, perangkat/versi mana]. Kode yang relevan: [kode]. Log kerusakan (data pribadi dihapus): [jejak]. Berikan 3 kemungkinan besar penyebab utama dan verifikasi + perbaikan permanen untuk masing-masingnya. Tandai juga solusi yang membungkam gejala tersebut."
Templat akar penyebab: "Nilai ini muncul [null/false] secara tidak terduga. Ikuti aliran data dari input hingga titik ini: di mana nilai tersebut bisa hilang atau rusak? Beri tahu saya di mana saya harus memeriksa di setiap tahap. [kode]"
Templat pembacaan log: "Interpretasikan keluaran log ini: peristiwa apa yang terjadi secara berurutan, di mana kelainannya, apa langkah terakhir yang sehat sebelum kesalahan? [log — data pribadi dihapus]"
Templat reproduksi: "Langkah, status perangkat, dan data apa yang harus saya coba untuk mereproduksi kesalahan ini dengan andal? Cantumkan kondisi yang dapat memicu kesalahan dalam urutan kemungkinan. [deskripsi]"
Kesalahan umum
- Memberikan pelacakan tumpukan bebas konteks. Tanpa kode dan skenario yang relevan, AI membuat prediksi umum.
- Menempelkan data pribadi ke AI bersama dengan log. Pelanggaran kerahasiaan; masker dulu.
- Diamkan gejalanya. Menyembunyikan kerusakan dengan try-catch akan meninggalkan akar masalah dan menimbulkan masalah baru.
- Menerapkan saran pertama tanpa memverifikasinya. Diagnosis AI adalah sebuah hipotesis; Konfirmasikan dalam kode.
- Mencoba mereproduksinya di emulator. Beberapa error hanya muncul pada perangkat/kondisi sebenarnya.
- Tidak menguji ulang setelah koreksi. Perbaikannya mungkin merusak hal lain; Periksa regresi.
Singkatnya
Salah satu keunggulan AI adalah membaca log kerusakan dan memilah kemungkinan penyebabnya; Kualitas diagnosis sangat meningkat bila konteksnya diberikan. Namun diagnosis dan koreksi akhir adalah milik manusia: saran AI adalah hipotesis, diverifikasi dalam kode dan pengujian. Tujuannya bukan untuk membungkam gejalanya tetapi untuk mengatasi akar permasalahannya; Kesalahan yang dibungkam biasanya muncul kembali dalam bentuk lain. Log kerusakan mungkin berisi data pribadi; Tutupi sebelum memberikannya kepada AI dan jangan menulis data pribadi di log Anda dari awal.
Tugas aplikasi
Ambil log kerusakan yang Anda miliki (atau sampel yang Anda hasilkan dari AI), tutupi semua data pribadi/khusus di dalamnya, dan berikan ke AI dengan "templat analisis kerusakan". Bedakan mana dari daftar akar penyebab AI yang merupakan perbaikan aktual dan mana yang hanya membungkam. Terapkan perbaikan permanen yang Anda pilih dan verifikasi bahwa kesalahan telah hilang dan tidak ada masalah baru yang muncul.
daftar periksa
- [] Saya telah memberikan log kerusakan dengan kode dan konteks skenario yang relevan
- [ ] Saya menutupi data pribadi/khas di log
- [ ] Saya meminta AI untuk mengetahui akar permasalahan dan perbaikan permanen, bukan membungkam
- [ ] Saya memverifikasi diagnosis dalam kode dan pengujian, saya tidak menerapkannya secara membabi buta
- [ ] Setelah diperbaiki saya tes errornya sudah hilang dan tidak ada regresi
- [ ] Saya memeriksa bahwa aplikasi saya tidak menulis data pribadi di lognya