Saya berhenti menggunakan Twitter beberapa waktu lalu karena Twitter cenderung membangkitkan kemarahan, sebagaimana memang seharusnya dilakukan. Namun sesekali saya memeriksanya kembali – terkadang berguna untuk mengikuti riset grafis, berita pengembangan game, dan beberapa orang memposting hal-hal baik, seperti berbagi proyek yang sedang mereka kerjakan, jadi ada sesuatu yang menarik saya kembali dari waktu ke waktu.
Setelah memeriksa beberapa hari yang lalu saya melihat perdebatan terjadi tentang tidak menggunakan IDE atau debugger, hanya menggunakan ‘notepad’ untuk menulis kode. Saya melihat di komentar, orang-orang berdebat tentang siapa yang benar dan semua getaran beracun yang biasa terjadi, dan itu mengingatkan saya pada beberapa kesempatan sebelumnya ketika orang-orang mendiskusikan topik yang sama.
Rasanya seperti perdebatan lama yang sama sudah berlangsung lama, dikemas berbeda setiap saat, tapi saya tidak begitu mengerti mengapa orang-orang begitu terpaku pada suatu hal. Argumen utamanya adalah “jika Anda perlu menggunakan debugger, Anda idiot dan Anda tidak memahami kode yang Anda tulis” (itu bukan kutipan sebenarnya tetapi ada pendapat serupa). Lalu ada “Jika Anda tidak dapat menggunakan debugger, Anda idiot”. Kebencian terhadap kru ‘printf’ ada di mana-mana.
Dengan risiko menjadi sarang lebah, saya hanya ingin berbagi beberapa pemikiran dan ide mengenai hal ini secara seimbang, karena menurut saya tidak perlu ada solusi akhir di sini. Kita perlu men-debug kode dan ada alat yang tersedia untuk membantu kita, beberapa di antaranya lebih berguna daripada yang lain dalam situasi tertentu, namun pada akhirnya lakukan apa pun yang perlu Anda lakukan untuk memperbaiki bug tersebut.
Debugger
Saya menggunakan debugger secara teratur, saya akan meluncurkan sebagian besar pekerjaan di C++ dari Visual Studio atau Xcode dan sebaiknya dijalankan dalam build debug. Saya tahu bagi sebagian orang ini sering kali merupakan UX yang buruk karena kinerja debug build, jadi prasyarat di sini adalah build debug yang cepat. Ini sulit untuk diperbaiki tetapi memiliki build debug yang dapat digunakan akan berguna. Setelah berjalan, saya dapat menggunakan jeda dan langkah debugger jika perlu, dan jika saya mengalami kerusakan maka ada tumpukan panggilan yang bagus yang dapat saya lihat lebih detail.
Saya perhatikan bahwa sangat umum bagi insinyur perangkat lunak tingkat sarjana dan junior untuk tidak mempunyai pengetahuan atau pengalaman debugging. Ini bukan sesuatu yang sepertinya diajarkan di universitas dan saya juga pernah mendengar cerita tentang guru yang memaksakan penggunaan VIM dan strategi debugging esoterik pada siswa. Sebagai catatan saya bukan pengguna VIM (topik lain yang berakhir dengan perdebatan polarisasi). Menurut saya, penggunaan mouse dan pengetikan 2 jari berhasil untuk saya.
Saat ketika Anda menunjukkan kepada seseorang cara menggunakan breakpoint perangkat keras atau watchpoint dan segera menemukan bug adalah seperti melihat bola lampu muncul di atas kepala mereka, seluruh kemungkinan terbuka di hadapan mereka, atau kekecewaan atas waktu yang terbuang sia-sia. mencoba menangkap logika cerdik melalui lapisan demi lapisan spageti berorientasi objek.
Beberapa dari mereka berpendapat tentang hanya menggunakan ‘notepad’ dan tidak ada debugger karena mereka dapat mengeringkan kode mereka di atas kertas dan mereka “tidak menulis bug”, tetapi saya merasa sulit untuk memahami cara kerjanya dalam proyek tim atau basis kode yang lebih besar. Banyak bug dan masalah yang harus saya perbaiki bukan dalam kode yang saya tulis sendiri, melainkan dalam sistem lawas, kode kolega, atau dalam kode sumber terbuka (dan beberapa bug yang sulit dilacak juga!) yang baru saja terjadi diangkat ke dalam sebuah proyek. Jika Anda yakin akan kiamat pengkodean AI yang akan datang, maka insinyur manusia mungkin hanya ada untuk melakukan debug dan memperbaiki masalah dengan kode yang dihasilkan AI. Jadi ya, bisa menulis kode yang sempurna sendiri adalah satu hal, tetapi menggunakan debugger untuk men-debug kode yang ada dalam proyek besar yang kompleks bukanlah suatu hal yang memalukan dan kita mungkin memerlukan semua alat yang kita bisa untuk membantu.
Bersamaan dengan debugger, kita mendapatkan berbagai macam alat lainnya, yang juga harus digunakan saat kita membutuhkannya. Pembersih alamat dapat menangkap masalah memori dengan mudah, di mana di masa lalu kita akan mengalami 1 dari 1000 kerusakan di suatu tempat yang terbaca di luar batas array, kita dapat mengaktifkan ASan dan menangkapnya setiap saat tanpa lotere perilaku yang tidak ditentukan. Sama halnya dengan pembersih perilaku yang tidak terdefinisi, sekarang kita dapat menangkap UB ketika penyakitnya tidak berbahaya dan tidak hanya ketika terjadi efek samping yang nyata.
Saya tidak tahu apakah pembuat kode khusus notepad ini juga menghapus semua alat tersebut, tetapi ketika Anda memiliki sesuatu seperti ASan yang dapat mengatasi masalah Anda, saya tidak begitu tahu mengapa Anda tidak menggunakannya dia. Saya telah melihat banyak komentar yang sepertinya menyarankan debugger memperlambatnya, tetapi dalam kasus ini menurut saya debugger mempercepat Anda.
Jadi jika Anda membaca ini dan Anda tidak tahu tentang alat-alat ini, saya sarankan lihat dan lihat, alat-alat ini dapat berguna dan mungkin dapat menghemat banyak waktu Anda. Ada banyak sekali hal yang dapat Anda lakukan dan sulit untuk membahas semuanya di sini. Saya belajar banyak dari bekerja dengan orang lain dan secara berdampingan men-debug masalah-masalah sulit. Saya pikir harus ada lebih banyak sumber daya untuk mengajarkan keterampilan ini daripada sekedar memberikan informasi.
Proses debug printf baik-baik saja
Jadi bagi para pembenci ‘printf’ saya juga akan mengatakan bahwa saat menggunakan debugger sebagian besar waktu, terkadang saya kembali ke debugging ‘printf’. Ada beberapa situasi di mana tidak ada pilihan lain – di masa lalu saya harus men-debug rilis build di mana kami tidak dapat mereproduksi bug dalam debug. Bahkan menarik modul debug untuk mesin (untuk info debug di layar) mengubah file yang dapat dieksekusi sehingga kami tidak dapat mereproduksi masalah tersebut. Hal terakhir adalah memasukkan beberapa pernyataan print menggunakan ‘printf’ mentah dan menghapusnya serta menambahkan lebih banyak lagi saat kami mempersempit masalah dan pada akhirnya mengekstrak informasi yang cukup untuk memperbaiki masalah.
Saya juga memiliki kebutuhan untuk menggunakan ‘printf’ ketika men-debug perilaku tertentu dalam suatu aplikasi. Dalam kasus seperti pelacakan peristiwa sentuh untuk perangkat seluler, jika Anda mencoba men-debug masalah dengan breakpoint, Anda akan mengganggu perangkat keras dan menyulitkan untuk mereproduksi masalah dengan cara yang sama seperti yang muncul secara alami. Jadi di sini mencetak status peristiwa touch down, peristiwa touch up, dan kemampuan melihat aliran logis dapat mengidentifikasi masalah. Masih banyak lagi skenario yang mendapat manfaat dari jenis debugging ini. Masukkan saja cetakannya dan pastikan untuk menghapusnya setelahnya sehingga tidak ada yang tahu Anda pernah berada di sana, seperti seorang ninja.
Alat debugging berbasis UI khusus dapat melangkah lebih jauh daripada debugging printf, memberikan beberapa sifat serupa tetapi juga memungkinkan lebih banyak fleksibilitas dan pengendalian, saya berasumsi pengguna notepad yang tidak menggunakan debugger biasa harus memiliki beberapa alat khusus dan hal-hal untuk membantu mereka melacak masalah. Saya penggemar berat alat debugging dan pembuatan profil yang tertanam dalam suatu aplikasi. Anda tahu hal-hal seperti penghitung kinerja yang dapat saya munculkan di UI atau nilai yang dapat diubah untuk membantu menyempurnakan perilaku atau tampilan visual. Saya menemukan bahwa sejak ledakan ImGui, tingkat alat dan informasi debugging ad-hoc yang terintegrasi telah meningkat secara eksponensial.
Namun dengan alat khusus semacam ini, saya pribadi tidak akan mencoba dan menemukan kembali rodanya. Saya bertujuan untuk membuat barang-barang yang melengkapi alat-alat yang sudah ada yang dapat saya gunakan. Jadi misalnya saya ingin memiliki profiler sekilas untuk semua hotspot kinerja utama saya yang dapat saya periksa kapan pun saya melihat sesuatu. Namun untuk pembuatan profil yang lebih mendalam saya akan menggunakan profiler CPU atau GPU untuk menggali lebih dalam.
Hanya melakukan apa yang perlu dilakukan
Pada akhirnya, menemukan bug hanyalah sesuatu yang perlu kami selesaikan, apa pun yang membantu Anda menemukan dan memperbaiki masalah tidak mengganggu saya selama kami menyelesaikan pekerjaannya. Sebagai catatan penutup, saya melihat beberapa kode dalam permintaan tarik yang ditinggalkan secara tidak sengaja oleh orang lain:
if(some_condition) {
int x = 0;
}
Menurut saya ini menarik. Saya melakukan hal yang sama kecuali saya biasanya memberi nama variabel saya ‘a’. Ini untuk memasukkan beberapa kode di mana breakpoint dapat diletakkan pada baris ‘int x’ dan kemudian bertindak seperti breakpoint bersyarat ketika some_condition benar. Anda dapat menggunakan breakpoint bersyarat dalam debugger, namun bisa lambat dan bagi saya secara historis tidak dapat diandalkan, namun cuplikan kecil ini memberi Anda breakpoint bersyarat Anda sendiri yang berfungsi tanpa gagal.
Pastikan untuk menghapus kode sebelum PR lain kali!
