Debug PHP bisa dilakukan dengan tiga cara utama: mencetak nilai variabel langsung ke halaman, memakai debugger langkah demi langkah, atau menulis log ke berkas. Masing-masing punya biaya dan hasil berbeda. Perbandingan cara debug PHP berikut membantu memilih alat yang tepat sesuai jenis masalah yang dihadapi.

Kapan Var Dump dan Sejenisnya Masih Berguna

Fungsi seperti var_dump(), print_r(), dan var_export() bekerja dengan menulis isi variabel ke output. Cara ini paling cepat dipakai ketika menelusuri nilai yang salah di satu titik eksekusi.

Kelebihannya: tidak butuh instalasi tambahan, bisa dipakai di server mana pun, dan langsung terlihat di browser. Cocok untuk skrip kecil, eksperimen di REPL, atau memastikan tipe data pada fungsi yang baru diperbaiki.

Kekurangannya muncul saat kode bertambah besar. Output yang bercampur dengan HTML bisa merusak header respons, terutama jika dipanggil setelah output dimulai. Jika lupa dihapus, jejak debug ikut terkirim ke pengguna. Untuk API berbasis JSON, var_dump() membuat respons tidak valid.

Pemakaian yang lebih rapi: bungkus dengan helper kecil yang hanya aktif di lingkungan pengembangan, atau kirim hasilnya ke berkas alih-alih ke layar. Contoh sederhana:

function dd($value) {
    if (getenv('APP_ENV') !== 'local') {
        return;
    }
    echo '<pre>';
    var_dump($value);
    echo '</pre>';
    exit;
}

Dengan begitu, panggilan dd() yang tertinggal di kode produksi tidak membocorkan apa pun ke pengunjung.

Xdebug: Debugger Langkah demi Langkah

Xdebug adalah ekstensi PHP yang menyediakan debugger interaktif, pelacakan stack, dan profiler performa. Alih-alih menebak di mana nilai berubah, Anda memasang breakpoint dan menelusuri eksekusi baris per baris.

Alat ini menyelesaikan masalah yang sulit dijangkau cara cetak manual: nilai yang berubah di dalam loop panjang, pemanggilan fungsi berlapis, atau kondisi yang hanya terpenuhi pada data tertentu. Anda bisa melihat isi semua variabel lokal pada satu titik tanpa menambahkan satu baris kode.

Ada beberapa hal yang perlu diperhatikan sebelum memasangnya di server produksi:

  • Xdebug menambah beban memori dan waktu eksekusi, terutama mode profiler.
  • Debugger interaktif membuka port jaringan yang harus dibatasi ke alamat tepercaya.
  • Aktifkan hanya untuk lingkungan pengembangan, jangan di server publik.
  • Konfigurasi xdebug.mode menentukan fitur yang aktif, jadi tidak perlu menyalakan semuanya sekaligus.

Perbandingan langsung dengan var_dump(): untuk kesalahan logika di satu titik, cetak manual lebih cepat. Untuk masalah yang melibatkan alur kompleks atau nilai yang berubah di banyak tempat, Xdebug menghemat waktu karena Anda tidak perlu menebak titik periksa.

Logger: Merekam Kejadian Tanpa Menghentikan Aplikasi

Logging bekerja dengan menulis pesan ke berkas atau layanan terpusat. Berbeda dari dua cara sebelumnya, logger tidak menghentikan eksekusi dan tidak mengubah output halaman.

Pendekatan ini paling cocok untuk masalah yang sulit direproduksi: permintaan yang gagal sesekali, kesalahan pada jam sibuk, atau perilaku yang hanya muncul di lingkungan tertentu. Anda menyisipkan catatan di titik penting, lalu membaca polanya setelah kejadian berlalu.

Standar PSR-3 mendefinisikan tingkat log seperti debug, info, warning, dan error. Memakai tingkat yang tepat membuat berkas log bisa disaring. Contoh dengan Monolog:

use MonologLogger;
use MonologHandlerStreamHandler;

$log = new Logger('app');
$log->pushHandler(new StreamHandler(__DIR__ . '/var/app.log', Logger::WARNING));

$log->warning('Kuota API hampir habis', ['sisa' => $sisa]);

Isi konteks sebagai array, bukan digabung ke dalam pesan. Struktur ini memudahkan pencarian di kemudian hari, terutama jika log dikirim ke alat agregasi.

Satu jebakan yang sering terjadi: menulis terlalu banyak. Log yang penuh dengan pesan rutin membuat masalah justru tenggelam. Pilih titik catat yang benar-benar membantu, dan gunakan tingkat yang sesuai.

Perbandingan Berdasarkan Situasi

Tidak ada satu alat yang menang di semua kasus. Tabel berikut merangkum kapan masing-masing paling berguna.

Situasi Alat yang cocok Alasan
Memeriksa satu nilai variabel var_dump / dd Tanpa setup, hasil langsung terlihat
Melacak alur fungsi berlapis Xdebug Breakpoint dan stack trace
Masalah yang sulit direproduksi Logger Rekaman bertahan setelah kejadian
Mencari penyebab lambat Xdebug profiler Menampilkan waktu tiap fungsi
Memantau aplikasi berjalan Logger Tidak mengganggu permintaan pengguna

Jika bekerja di tim, sepakati satu format log sejak awal. Cara menyimpan konfigurasi aplikasi, termasuk pengaturan debug dan lokasi berkas log, sebaiknya juga konsisten agar tidak ada lingkungan yang tertinggal. Ulasan tentang cara menyimpan konfigurasi database di PHP membahas pola serupa untuk kredensial dan pengaturan lingkungan.

Kesalahan Umum Saat Debug

Beberapa kebiasaan memperlambat proses tanpa disadari. Menyalakan semua mode Xdebug sekaligus membuat aplikasi berat dan sulit dinilai performanya. Menaruh var_dump() di dalam loop besar menghasilkan ribuan baris yang akhirnya diabaikan.

Mencatat log tanpa tingkat keseriusan membuat berkas sulit disaring. Menjalankan debugger di server produksi berisiko membuka akses ke data sensitif. Menghapus log sebelum masalah selesai juga menghilangkan bukti yang mungkin masih dibutuhkan.

Memilih Kombinasi yang Efisien

Pendekatan yang lazim dipakai: dd() untuk pemeriksaan cepat, Xdebug untuk menelusuri alur rumit di lingkungan lokal, dan logger untuk memantau aplikasi setelah berjalan. Ketiganya bisa dipakai bergantian dalam satu sesi debugging yang sama.

Yang lebih penting dari pilihan alat adalah konsistensi. Tim yang punya aturan jelas tentang kapan memakai apa akan menyelesaikan masalah lebih cepat daripada tim yang tiap orang memakai caranya sendiri.

Pertanyaan yang Sering Diajukan

Apakah Xdebug aman dipasang di server produksi?

Umumnya tidak disarankan. Xdebug menambah beban dan membuka jalur koneksi debugger yang perlu diamankan. Jika memang harus ada di sana, nyalakan hanya mode yang perlu, batasi akses jaringan, dan pantau dampaknya terhadap performa.

Kapan sebaiknya memakai logger daripada var_dump?

Saat masalah tidak bisa dihentikan dan diperiksa saat itu juga, misalnya kegagalan yang muncul hanya pada sebagian permintaan. Logger merekam kejadian tanpa mengubah respons, sehingga bisa dianalisis setelahnya.

Bisakah ketiga cara ini dipakai bersamaan?

Bisa, dan sering justru begitu. Pemeriksaan cepat dengan var_dump() mempersempit area masalah, Xdebug menelusuri alurnya, lalu logger memastikan perbaikan berjalan di lingkungan nyata.