Halo dan selamat datang.
Dalam kuliah ini saya ingin berbicara tentang debugging.
Ini adalah konsep yang sangat penting yang perlu Anda pahami secara khusus, Anda perlu memahami beberapa alat
dan beberapa metode yang dapat Anda terapkan untuk menemukan dan memperbaiki bug.
Jadi, debugging adalah proses menemukan dan memperbaiki kesalahan dalam program.
Biasanya kesalahan logika.
Dan saya akan memberi tahu Anda perbedaan antara kesalahan logika dan sintaksis, tetapi juga dapat mencakup kesalahan
sintaksis kompiler.
Ini adalah keseluruhan proses untuk kesalahan sintaksis.
Debugging adalah memahami apa yang dikatakan oleh kompiler kepada Anda.
Anda selalu ingin fokus untuk memperbaiki masalah pertama yang terdeteksi.
Saya ingin membahas beberapa kesalahan dan peringatan kompiler umum yang mungkin Anda dapatkan, tetapi salah
satu hal yang selalu ingin Anda ketahui tentang kompiler adalah bahwa kompiler dapat memberikan sejumlah
kesalahan.
Anda harus selalu fokus pada kesalahan pertama karena kesalahan pertama tersebut dapat mengakibatkan kesalahan lainnya.
Jadi, bisa sangat menyesatkan jika Anda melihat lima kesalahan dalam sebuah program yang diberitahukan oleh kompiler, Anda mungkin hanya memiliki satu
kesalahan dan kesalahan pertama mungkin menyebabkan kesalahan lainnya.
Jadi, penting untuk selalu melihat kesalahan teratas pertama dan memperbaikinya terlebih dahulu.
Dalam contoh yang sangat sederhana ini, kami memiliki beberapa kesalahan dalam kode ini.
Kami tidak punya.
Kami tidak memiliki kurung kurawal kiri awal, kurung kurawal keriting.
Kami tidak memiliki titik koma.
Kami mengembalikan sebuah string.
Jadi, ketika kita menyimpan ini dan kita pergi untuk mengkompilasinya dan Anda benar-benar melihat beberapa kesalahan berwarna
merah, ketika kita pergi untuk mengkompilasinya, itu sebenarnya memberi tahu kita bahwa kita memiliki tiga kesalahan.
Anda tidak akan pernah ingin hanya memilih kesalahan terakhir pada baris ketujuh, meskipun dalam kasus ini adalah kesalahan yang sebenarnya.
Anda selalu ingin memperbaiki kesalahan pertama.
Jadi, Anda melihat kesalahan pertama yang tercantum di sini dan Anda memperbaiki kesalahan pertama tersebut, lalu Anda mengkompilasi ulang dan menjalankannya
lagi.
Tetapi alasan untuk melakukan hal ini hanya untuk memperbaiki kesalahan tingkat atas adalah karena kesalahan tersebut dapat menyebabkan
masalah lain.
Jadi, selalu fokuslah untuk memperbaiki kesalahan pertama debugging dan proses menemukan dan memperbaiki bug bisa menjadi sangat kompleks
mulai dari menemukan kesalahan sederhana hingga mengumpulkan data dalam jumlah besar untuk dianalisis.
Itu semua tergantung.
Terkadang Anda tidak memiliki informasi apa pun yang diberikan kepada Anda kecuali logging, dan dalam hal ini Anda harus menganalisis
berbagai hal.
Terkadang Anda akan mengalami bug yang tidak dapat diulang.
Anda tidak dapat mereproduksinya, karena ini merupakan peristiwa yang jarang terjadi.
Itu biasanya terjadi ketika Anda harus menganalisis log atau beberapa variasi dari itu.
Kemampuan untuk melakukan debug oleh seorang programmer adalah keterampilan yang penting.
Ini benar-benar merupakan keterampilan pemecahan masalah yang dapat menghemat banyak waktu dan uang.
Jadi, ini adalah keterampilan yang penting untuk dipelajari.
Ini adalah keterampilan yang penting untuk dikembangkan.
Dibutuhkan latihan.
Anda tidak hanya pergi ke sana, tetapi juga tidak hanya datang kepada Anda.
Ada beberapa teknik tertentu yang bisa Anda terapkan dan metode yang bisa Anda terapkan untuk membuat Anda lebih baik
dalam melakukan debug.
Saya mengenal beberapa pengembang yang sangat ahli dalam menulis kode perangkat lunak.
Mereka memahami bahasa dengan sangat baik, tetapi keterampilan debugging mereka sangat buruk.
Mereka mungkin mendapatkan bug dan kecenderungan pertama mereka untuk memecahkan bug itu benar-benar keluar jalur.
Dan sekali lagi, hal ini datang dengan latihan.
Anda akan menjadi lebih baik dan lebih baik lagi dalam melakukan debug dan memahami cara menemukan dan memperbaiki masalah, tetapi
itu adalah sesuatu yang harus Anda pelajari juga.
Fase pemeliharaan adalah fase yang paling mahal dalam siklus hidup perangkat lunak.
Fase pemeliharaan adalah setelah Anda merilis produk Anda dan sekarang Anda harus memeliharanya.
Memeliharanya berarti memperbaiki bug baru yang muncul dan juga menambahkan fitur baru.
Jadi, misalnya, ketika Windows merilis sistem operasi baru seperti Windows 10, mereka belum selesai memproduksi
perangkat lunak itu.
Kamera ini akan berada di lapangan selama mungkin sepuluh tahun.
Dan masih menjadi tanggung jawab Microsoft ketika ada bug baru yang masuk atau mereka menemukan bug baru untuk perangkat lunak tersebut untuk memperbaikinya.
Dan itulah mengapa mereka mendorong pembaruan otomatis dan melakukan hal-hal seperti itu.
Dan kemudian mereka juga akan menyadari bahwa sistem operasi akan mengeluarkan fitur-fitur baru seiring dengan perubahan
pasar dan perubahan teknologi.
Oleh karena itu, pemeliharaan sangatlah penting.
Dan sebagai hasilnya, menemukan dan memperbaiki bug Anda sangatlah penting.
Namun, pahamilah bahwa bug tidak dapat dihindari.
Semua perangkat lunak memiliki bug.
Tidak ada yang bisa menulis kode yang sempurna dan ini bukan tentang menulis kode yang sempurna.
Hanya saja, banyak hal berubah seiring berjalannya waktu.
Jadi, hal itu juga dapat mengakibatkan bug.
Anda harus memahami bahwa hanya karena perangkat lunak memiliki bug, bukan berarti itu adalah kode yang ditulis dengan buruk.
Hal ini tidak dapat dihindari.
Jadi, tidak masalah jika ada bug, Anda tahu, ketika Anda menemukan dan memperbaikinya, itu bahkan lebih hebat karena Anda benar-benar merasa
seperti sedang menyelesaikan sesuatu.
Masalah umum.
Dan kita akan membahas lebih lanjut mengenai masalah spesifik yang terkait dengan melihat.
Tetapi masalah umum ketika Anda mencoba melakukan debug adalah kesalahan logika.
Kesalahan logika tidak ada hubungannya dengan jenis kesalahan sintaks yang sebenarnya dikompilasi oleh kode Anda.
Ini berfungsi, tetapi tidak melakukan apa yang seharusnya dilakukan.
Jadi, ada semacam logika atau fungsi yang dimaksudkan yang salah.
Mungkin Anda memiliki pernyataan IF dan Anda melompat ke dalam pernyataan if pada kondisi yang salah.
Mungkin Anda memiliki perulangan dan perulangan tersebut tidak dieksekusi dalam jumlah yang tepat atau Anda tidak menyortir dengan
benar.
Fungsionalitasnya rusak, tetapi kompiler mengatakan, Hei, semuanya terlihat bagus.
Berikut adalah contoh kesalahan logika.
Kesalahan logika adalah ketika sintaksnya benar, tetapi hasil yang diinginkan tidak benar karena suatu masalah
logika.
Jadi, dalam kode ini Anda melihat perulangan for memiliki titik koma di bagian akhir yang secara sintaksis benar.
Tetapi Anda mengharapkan perulangan for ini berjalan lima kali.
Tapi sebenarnya tidak.
Ini hanya akan berjalan satu kali saja.
Jadi, jika kita mengatakan build dan kita membangun proyek ini, kita akan melihat peringatan, dan itu bagus dan Anda harus selalu memperbaiki semua peringatan
Anda.
Tetapi berhasil dikompilasi dengan baik.
Jadi, ketika kita menjalankan proyek ini, Anda akan melihat bahwa proyek ini sebenarnya hanya berjalan satu kali dan
mencetak Hello World satu kali.
Jadi, ini adalah contoh kesalahan logika.
Kesalahan sintaksis secara langsung terkait dengan kompiler.
Ini adalah hal-hal yang tidak mengikuti aturan bahasa.
Anda tidak perlu menggunakan titik koma di akhir pernyataan.
Anda tidak memiliki akhir cerita, bukan?
Tanda kurung dengan tanda kurung kiri.
Anda kehilangan satu braket.
Anda tidak menggunakan kata kunci yang tepat, hal-hal seperti itu.
Kesalahan sintaks biasanya disebabkan oleh kompiler Kesalahan Logika akan disebabkan oleh programmer
selama fase pengujian.
Kerusakan memori juga merupakan masalah yang umum terjadi, terutama di C.
Jika Anda tidak mengosongkan memori setelah mengalokasikannya dengan benar, Anda dapat
mengalami hal-hal seperti referensi yang menggantung dan Anda juga dapat mengalami masalah memori yang terkait dengan memori yang tidak digunakan.
Anda dapat mengalami kebocoran memori.
Berikut ini contoh kesalahan memori.
Pada kode khusus ini, kita sebenarnya mengalami kebocoran memori, jadi kita belum membicarakan tentang pointer.
Kami belum membicarakan tentang alokasi memori dinamis.
Tetapi dalam C Anda dapat mengalokasikan memori saat program Anda berjalan.
Anda dapat menggunakan fungsi malloc.
Jadi, di sini kita menandai, kita mengalokasikan memori, tetapi kita tidak pernah membebaskannya.
Jadi kita dapat membuat kode ini dan menjalankannya dan semuanya berjalan dengan baik, tetapi kita tidak benar-benar membebaskan kesalahan
ini.
Jadi, apa yang harus kita lakukan untuk memperbaiki kesalahan memori ini adalah kita harus mengatakan free dan kemudian kita harus mengatakan
free dan X untuk membebaskan penunjuk tersebut.
Namun, setiap kali Anda mengalokasikan memori, Anda tidak membebaskannya.
Itu adalah kebocoran memori.
Contoh lainnya adalah jika kita tidak mengalokasikan memori, jika kita membuat penunjuk dan kemudian kita mencoba menetapkannya,
kita akan mengalami kerusakan memori karena memori tersebut tidak memiliki alokasi apa pun untuk itu dan kita
mencoba menetapkan nilai padanya.
Jadi, itu hanya sedikit, sedikit informasi tentang beberapa contoh untuk memori, korupsi, kinerja, dan skalabilitas.
Ini bisa menjadi masalah ketika fungsionalitas Anda dimaksudkan sebagaimana adanya dan kode Anda secara sintaksis sudah benar,
tetapi tidak terlalu efisien atau Anda tidak memiliki perangkat keras untuk mendukungnya.
Jadi, jika Anda menjalankan server dan Anda tidak memiliki perangkat keras yang cukup untuk mendukung semua permintaan, maka server
akan berjalan sangat, sangat lambat.
Atau jika Anda menulis program untuk bekerja dengan sepuluh pengguna, tetapi ketika ada banyak pengguna, mungkin program
tersebut tidak berjalan dengan cepat karena database macet atau apa pun masalahnya.
Kode berfungsi, tetapi tidak dirancang dengan benar untuk menangani banyak, banyak sekali pengguna atau
apa pun itu.
Kurangnya kohesi.
Ini bisa menjadi masalah dalam kode Anda yang mengurangi kualitas yang terkait dengan kode Anda yang melakukan terlalu banyak hal atau fungsi
yang melakukan terlalu banyak hal.
Tidak memiliki fokus tunggal atau bahkan aplikasi memiliki terlalu banyak fungsi, memiliki fitur
yang tidak pernah digunakan, sehingga ini mungkin memerlukan desain ulang.
Berikut ini adalah contoh program yang tidak termodulasi, yang tidak kohesif.
Anda memiliki satu fungsi besar yang melakukan terlalu banyak hal, ratusan baris kode, ribuan
baris kode.
Anda ingin memecah suatu fungsi menjadi fungsi-fungsi pembantu, modul-modul yang terpisah.
Hal ini membuat program Anda jauh lebih kohesif dan lebih mudah dikelola.
Jadi, alih-alih memiliki metode utama yang besar yang melakukan inisialisasi membaca input, mencari beberapa, mencari
selisih, mencari hasil kali, mencari hasil bagi, Anda dapat membuat semua kode ini dan memasukkannya ke dalam modul-modul
pembantu dan memisahkan kode tersebut sehingga pemisahan ini dapat membantu menemukan dan memperbaiki bug Anda dengan lebih mudah.
Kekompakan selalu penting dalam C dan biasanya diselesaikan jika Anda memiliki kohesi yang tinggi dengan menyediakan
metode pembantu.
Kopling yang kencang.
Hal ini juga berkaitan dengan kualitas kode.
Di sinilah Anda memiliki banyak ketergantungan.
Kopling berbeda dengan kohesi.
Kohesi adalah fokus tunggal Anda.
Coupling adalah di mana Anda memiliki ketergantungan antara fungsi-fungsi yang mungkin atau antar objek.
Kami berbicara tentang kopling, kami berbicara tentang variabel global.
Jika sebuah variabel variabel global digunakan dalam banyak fungsi yang berbeda, hal ini dapat menyebabkan ketergantungan di antara
fungsi-fungsi tersebut.
Jadi, apa yang ingin Anda perjuangkan ketika Anda menulis kode dan Anda menulis kode berkualitas tinggi adalah
Anda ingin memiliki kohesi yang sangat tinggi dan kopling yang sangat rendah.
Proses debugging.
Hal pertama yang harus Anda lakukan sebelum Anda dapat menemukan dan memperbaiki kesalahan apa pun adalah Anda harus memahami
masalahnya.
Hal ini berkaitan dengan jangan langsung terjun dan mulai melihat kode, duduklah bersama penguji, pahami
persyaratannya, pahami apa yang sedang terjadi.
Karena jika Anda tidak memahami apa yang sedang terjadi, Anda bahkan tidak akan bisa.
Anda bahkan tidak boleh mencoba memecahkannya.
Setelah Anda memahami bug, cobalah untuk mereproduksinya karena mereproduksi bug dapat membantu Anda mengumpulkan lebih
banyak informasi.
Tidak selalu memungkinkan untuk mereproduksi bug karena bug dapat muncul dalam keadaan yang sangat jarang.
Jadi, misalnya, bug yang memiliki kondisi seperti race atau bahkan kerusakan memori mungkin hanya terjadi pada kasus penggunaan
yang sangat spesifik dan mungkin merupakan masalah yang terputus-putus.
Dan apakah memang demikian?
Dan Anda tidak dapat mereproduksinya.
Ini akan menjadi semakin sulit untuk melakukan debug.
Jika Anda dapat mereproduksinya, biasanya Anda dapat mengumpulkan informasi yang cukup untuk memperbaikinya.
Sebagian besar masalah dapat diperbaiki.
Selain itu, Anda juga dapat mengalami masalah dengan tidak dapat mereproduksi masalah jika Anda berada di lingkungan multithreaded,
proses paralel, atau masalah threading.
Itu juga sangat sulit untuk di-debug, tetapi cobalah untuk mereproduksinya setelah Anda mengetahui
apa masalah sebenarnya dalam hal Anda dapat memahami setelah Anda dapat mereproduksinya, jika tidak, maka Anda
harus mencoba melakukan pendekatan dengan menerapkan semacam divide and conquer.
Anda ingin mencoba mengisolasi bug, menyederhanakan masalah, karena mampu mengurangi akan memberi Anda informasi kembali,
tetapi mungkin tidak selalu memberi tahu Anda di bagian mana dari kode yang terdapat bug.
Jadi, apa yang dapat Anda lakukan untuk mencoba menyederhanakan masalah adalah menghapus bagian dari kasus uji asli sehingga Anda
tidak menguji terlalu banyak.
Anda bisa mengisolasi masalahnya lebih kecil lagi dengan mengatakan, Oh, ini hanya terjadi pada situasi tertentu.
Anda juga dapat mengomentari kode.
Kami berbicara tentang fungsi yang hanya memiliki rintisan dan tidak memiliki implementasi.
Kadang-kadang, hal ini digunakan dalam pengujian sehingga dapat membatasi masalah yang ditetapkan.
Selain itu, jika Anda mengomentari kode, Anda akan memiliki lebih sedikit kode di mana bug dapat terjadi.
Jadi, ketika Anda mengomentari kode atau membatalkan perubahan, bug bisa saja hilang dan jika bug tersebut hilang, hal ini menunjukkan
bahwa kode yang Anda komentari mungkin menjadi penyebabnya.
Apa yang pada dasarnya ingin Anda lakukan adalah mengubah sebuah program besar menjadi banyak program kecil, baik melalui
pengujian atau memberikan komentar.
Teknik umum lainnya adalah dengan melakukan tes unit di sekitar kode Anda.
Jika unit test gagal, hal itu dapat memberi tahu Anda dengan tepat di mana letak logika atau masalahnya dalam kode Anda.
Setelah Anda mengisolasi bug, Anda akan menemukan asal masalah dalam kode, yaitu kode spesifik yang
menyebabkan masalah.
Kadang-kadang hal ini akan menggunakan alat debugging seperti debugger.
Kita akan membahas tentang debugger secara spesifik, tetapi biasanya tergantung pada IDE pengembangan terintegrasi
yang Anda gunakan, ada debugger yang disertakan dengan IDE.
Ada juga debugger yang dapat berjalan secara mandiri.
Debugger penting yang akan kita gunakan untuk pemrograman C disebut GDB.
Ini adalah debugger GNU, jadi ini adalah alat yang bagus yang sebenarnya adalah alat grafis di mana Anda dapat menghentikan
eksekusi program Anda dan menambahkan breakpoint.
Kemudian saat Anda menghentikan eksekusi, Anda dapat membuka baris demi baris dalam kode Anda dan melihat nilai variabel.
Jadi, Anda dapat melihat dengan tepat apa yang terjadi di dalam kode Anda ketika kode tersebut berjalan.
Ini adalah alat yang tak ternilai harganya.
Hanya saja, ini sangat berguna.
Kita akan menjalankan debugger.
Saya akan menunjukkan kepada Anda bagaimana cara menambahkan breakpoint.
Saya akan menunjukkan kepada Anda cara mengatur jam tangan sehingga Anda dapat melihat variabel saat mereka berubah dan juga melangkah
melalui kode.
Setelah Anda mengidentifikasi asal mula masalahnya, Anda harus memperbaikinya.
Hal ini membutuhkan banyak pengalaman dan latihan.
Hanya karena Anda menemukan asal mula masalahnya, Anda masih belum tentu dapat memperbaikinya hanya
berdasarkan pengalaman Anda.
Hal ini terkadang termasuk mendesain ulang atau refactoring kode lain yang terutama dengan masalah skalabilitas
atau masalah kinerja, Anda mungkin harus mendesain ulang agar perangkat lunak Anda lebih skalabel.
Jadi, tidak selalu mudah untuk menemukan masalah dan kemudian memperbaikinya.
Masalahnya terkadang, terutama masalah yang lebih sulit lagi seperti threading atau pemrosesan paralel,
itu bahkan lebih sulit untuk diperbaiki.
Namun, seiring dengan semakin banyaknya kode yang Anda tulis, hal ini akan semakin mudah dilakukan.
Dan yang terakhir, Anda harus mengujinya seperti orang gila.
Selalu uji coba berbagai batasan yang berbeda.
Kasus yang baik, kasus yang buruk di antara kasus-kasus tersebut untuk memverifikasi bahwa Anda memang telah memperbaiki masalahnya.
Beberapa teknik dan alat bantu yang tersedia.
Salah satu alat yang umum dan sangat sering digunakan adalah dengan menggunakan laporan cetak.
Anda dapat menggunakan laporan cetak untuk melacak kode Anda pada dasarnya.
Jadi dalam C Anda dapat menggunakan pernyataan print F dan Anda dapat meletakkannya di beberapa baris dalam kode Anda untuk menandakan
di mana Anda berada.
Hal ini juga berguna, sangat berguna ketika program Anda mengalami kerusakan.
Hal ini dapat membantu mengidentifikasi di mana ia jatuh.
Saat Anda menambahkan pernyataan cetak ini menelusuri kode Anda, Anda dapat menambahkan output dalam
pernyataan cetak untuk melihat nilai variabel karena nilai variabel dapat mempengaruhi status dan dapat
menyebabkan masalah logika.
Jadi, hanya dengan menambahkan laporan cetak saja sudah sangat, sangat berguna.
Ini dapat menunjukkan alur eksekusi dan dapat membantu mengisolasi kesalahan.
Debugger seperti yang saya sebutkan di GDB, yang dapat memantau eksekusi program.
Anda dapat menghentikannya, Anda dapat menjalankan baris demi baris, memulai ulang, mengatur breakpoint, melihat variabel dan memori.
Sangat, sangat membantu ketika mencoba mendiagnosis di mana letak masalah berada.
File log.
File log juga sangat berguna, terutama untuk bug yang tidak dapat dibuat ulang.
Anda dapat menganalisisnya di kemudian hari untuk mengetahui dengan tepat apa yang terjadi saat bug terjadi.
Jadi, ini berarti Anda harus menyediakan pernyataan pencatatan yang baik dalam kode Anda sendiri
agar dapat berguna.
Jadi, Anda dapat membuat file log Anda sendiri dan kemudian menulis ke log tersebut saat program berjalan sehingga jika Anda mengalami kesalahan,
Anda dapat mengirimkan log tersebut ke pengembang.
Kami menerapkan hal ini cukup banyak di Xerox, karena ketika kami menemukan masalah, kami tidak selalu dapat mereproduksinya atau masalah
tersebut mungkin ditemui di lapangan.
Kita harus bisa mengakses log tersebut untuk melihat apa yang terjadi saat bug itu terjadi.
Perangkat lunak pemantauan.
Ada perangkat lunak yang dapat memantau dan memiliki analisis runtime penggunaan memori, ancaman lalu lintas jaringan,
dan informasi objek.
Hal ini dapat memberi tahu Anda jika mungkin Anda mengalokasikan terlalu banyak memori dan tidak menghapusnya.
Jika Anda memiliki alat untuk lalu lintas jaringan penggunaan memori yang dapat memberi tahu Anda apakah Anda mengirim
terlalu banyak paket atau tidak atau apakah perangkat lunak Anda dapat diskalakan atau tidak, jika Anda mengalami peningkatan
lalu lintas jaringan dan Anda melihat waktu respons Anda menurun.
Anda juga dapat memantau informasi thread dan objek untuk pemrosesan paralel untuk melihat apa yang terjadi di thread
tertentu dan apa yang terjadi di thread lain.
Hal itu akan membantu Anda mendiagnosis segala jenis masalah benang.
Beberapa alat debug umum lainnya yang dapat Anda gunakan untuk menemukan dan memperbaiki kesalahan Anda.
Anda dapat menggunakan penanganan pengecualian.
Banyak bahasa pemrograman memiliki penanganan pengecualian.
Sayangnya, C tidak memiliki penangan pengecualian yang benar-benar akan mencegah crash dan melakukan banyak hal pada
saat runtime.
Ini tidak berlaku untuk dilihat, tetapi tetap merupakan hal yang baik untuk dipahami.
Blok trycatch, hal-hal seperti itu.
Analisis statis.
Ada banyak penganalisis statis yang tersedia untuk penganalisis statis C.
Menganalisis kode sumber tanpa eksekusi yang sebenarnya.
Menjalankan program tidak perlu dijalankan.
Ini berjalan baris demi baris dan melihat kode sumber.
Dan saat mengurai kode sumber, ia mencari masalah yang diketahui.
Jadi, ini dapat memeriksa semantik.
Ini dapat memastikan hal tersebut.
Itu saja.
Anda tidak akan memiliki variabel yang tidak diinisialisasi jika Anda mengalokasikan memori baru dan menghapusnya.
Jika Anda memiliki kode mati di mana kode tidak benar-benar dieksekusi, Anda dapat menghapus kode tersebut.
Ini juga menganalisis hal-hal seperti kondisi balapan dan kebuntuan.
Kami menggunakan beberapa penganalisis statis di tempat saya bekerja.
Kami memiliki satu yang disebut Coverity, yang cukup populer, dan ada alat sonar kode yang kami gunakan juga, dan kami akan menjalankannya
pada seluruh baseline kami, seluruh kumpulan sumber kami.
Dan setiap kali kita memperkenalkan file baru dan kode baru, alat tersebut akan dijalankan pada kode tersebut dan akan dapat mengidentifikasi
masalah langsung dengan kode tersebut seperti variabel yang tidak diinisialisasi, kebocoran memori, dan sebagainya.
Ini tidak menganalisis sintaksis.
Itulah gunanya kompiler.
Ada juga sejumlah rangkaian pengujian yang menjalankan serangkaian pengujian sistem menyeluruh yang komprehensif yang dapat Anda
jalankan pada perangkat lunak Anda.
Pengujian selalu penting, tetapi jika Anda dapat mengotomatiskannya untuk menjalankan pengujian tertentu setiap kali
Anda melakukan build baru, misalnya, hal itu bisa sangat membantu dan ini benar-benar dapat mencegah kesalahan,
tetapi juga membantu mendiagnosis kesalahan.
Melakukan debug pada program setelah program tersebut mengalami crash.
Kita akan membahas tentang sesuatu yang disebut call stack.
Ini adalah mekanisme yang sangat berguna untuk dilihat, terutama dalam bahasa seperti C, di mana Anda mengalami crash dan satu-satunya
informasi yang Anda dapatkan adalah kesalahan segmentasi.
Ketika Anda mengalami crash, apa yang sering terjadi, tergantung pada bagaimana crash itu terjadi, file inti akan
dibuat dan Anda dapat menganalisis file inti untuk melihat tumpukan panggilan untuk melihat dengan tepat di mana program
itu mati.
Ini akan memberi tahu Anda baris kode di mana program mati.
Jadi kita akan belajar tentang call stack.
Dan sejauh menganalisis file inti, itu lebih merupakan teknik tingkat lanjut.
Tetapi dalam C, file inti dapat dihasilkan dan Anda dapat menganalisisnya.
Itu adalah teknik yang sedikit lebih canggih, tetapi itu adalah cara lain yang dapat Anda lakukan untuk melakukan debugging pada perangkat lunak Anda.
Bagaimana dengan mencegah kesalahan?
Kita tahu bahwa debugging adalah menemukan dan memperbaiki kesalahan, tetapi jika Anda dapat mencegah kesalahan, itu lebih baik lagi.
Salah satu cara untuk mencegah kesalahan adalah dengan menulis kode berkualitas tinggi.
Hal ini sebenarnya tidak menjadi fokus bagi banyak insinyur perangkat lunak.
Banyak insinyur perangkat lunak yang menulis kode, dan selama kode tersebut berfungsi, hanya itu
yang mereka pedulikan atau selama outputnya benar, maka mereka menganggap diri mereka sudah selesai.
Tetapi ada yang namanya kode berkualitas buruk dan Anda tidak ingin menulisnya.
Saya telah mendemonstrasikan beberapa hal ini selama kuliah, tetapi hal-hal seperti menggunakan nama variabel yang bermakna
sangat penting.
Atau jika Anda menulis kode yang tidak efisien di mana Anda menggunakan perulangan mungkin lebih banyak dari yang seharusnya, atau menggunakan
pernyataan if atau Anda tidak perlu melakukan itu.
Semua jenis hal ini merupakan kode berkualitas buruk.
Jika Anda memiliki fungsi yang melakukan 100 hal lain dan tidak kohesif, jika Anda memiliki 5000 baris dalam sebuah
fungsi, jika kode Anda tidak diatur secara modular atau jika Anda memiliki banyak ketergantungan
antar fungsi, sekali lagi, semua ini adalah kode yang berkualitas buruk dan Anda harus berusaha untuk tidak melakukan hal ini.
Anda ingin menggunakan teknik-teknik di mana program Anda terorganisir.
Mudah dipelihara, sangat kohesif, memiliki kopling yang rendah, dan Anda menggunakan nama variabel yang
bermakna.
Sangat, sangat penting.
Sekali lagi, hal ini sangat penting juga karena fase perawatannya sangat, sangat mahal.
Jika Anda menulis kode berkualitas buruk, maka akan lebih sulit untuk memeliharanya.
Lebih sulit untuk mengisolasi kesalahan dan lebih sulit untuk menambahkan fitur baru.
Jadi, karyawan harus memiliki teknik berkualitas tinggi yang baik saat menulis kode Anda.
Tes unit.
Unit test sangat membantu mencegah kesalahan.
Unit test yang dieksekusi secara otomatis ketika Anda mengkompilasi unit test dapat membantu menghindari regresi.
Itulah salah satu faktor yang paling penting.
Regresi adalah ketika Anda menulis kode baru dan Anda memperkenalkan bug pada sesuatu yang sebelumnya berfungsi.
Anda melanggar kode lama.
Anda tidak ingin melakukan hal itu.
Jika beberapa perangkat lunak berfungsi dan kemudian sesuatu yang baru yang Anda lakukan merusaknya, Anda ingin segera
diberitahu dan unit test dapat membantu melakukannya karena unit test akan berjalan pada kode lama tersebut dan akan mengatakan,
Hei, ini berfungsi, sekarang gagal.
Ini juga dapat menemukan kesalahan dalam kode baru sebelum dikirimkan, karena sekali lagi, mereka berjalan setelah Anda membangun dan akan
segera memberi tahu Anda ada sesuatu yang salah.
Ada konsep pengembangan berbasis uji coba yang semakin populer.
Di sinilah Anda menulis tes Anda terlebih dahulu dan kemudian mengembangkan kode Anda setelahnya.
Dan tujuannya di sini adalah ketika Anda menulis tes pertama Anda, tes Anda gagal dan kemudian Anda menulis kode untuk
membuatnya lulus.
Ada banyak keuntungan dari TDD dan ini adalah cara berpikir yang terbalik.
Biasanya orang ketika mereka menulis kode, mereka menulis kodenya terlebih dahulu dan kemudian mereka menulis tesnya.
Tetapi dengan TDD, ini benar-benar memberi Anda cara berpikir yang berbeda sehingga Anda bekerja dalam potongan-potongan
yang sangat kecil dan Anda cenderung menulis kode yang sangat kohesif dan Anda tidak memiliki kode, tidak memiliki
banyak ketergantungan karena coba tebak?
Jika Anda dapat menguji kode, artinya kode tersebut tidak memiliki banyak ketergantungan.
Jika unit test Anda sangat, sangat besar dan Anda mengejek semua hal yang berbeda ini, biasanya
ini merupakan indikator besar bahwa kode Anda sangat, sangat bergantung pada hal-hal lain.
Jadi dengan menggunakan TDD, ini memaksa Anda untuk menulis kode yang digabungkan dengan sangat longgar yang tidak memiliki ketergantungan dan memaksa
Anda untuk membuat fungsi-fungsi Anda menjadi sangat kohesif.
Ada banyak sekali keuntungan dari TDD.
Anda juga ingin memberikan dokumentasi yang baik dan Anda ingin melakukan perencanaan yang tepat.
Jangan hanya menyelami kode dan mulai mengimplementasikannya.
Tuliskan desain Anda di atas kertas.
Memanfaatkan pseudocode.
Benar.
Rencanakan kode Anda.
Jika Anda merencanakan kode Anda, Anda memahami persyaratannya dan Anda memiliki desain yang baik, Anda dapat
mencegah banyak sekali kesalahan.
Dan saya telah menyebutkan hal ini di seluruh kursus, tetapi sangat, sangat penting untuk memiliki pendekatan
tipe divide and conquer, bekerja dalam langkah-langkah kecil dan terus-menerus menguji setelah setiap langkah, jangan menulis 1000 baris
kode dan kemudian berkata, oke, kompilasi dan uji.
Itu bukan pendekatan yang baik.
Hindari terlalu banyak perubahan sekaligus.
Ketika membuat perubahan, terapkan secara bertahap, tambahkan satu perubahan, lalu uji secara menyeluruh sebelum memulai
langkah berikutnya.
Hal ini dapat membantu mengurangi semua jenis bug dan juga membatasi kumpulan masalah Anda.
Jadi, jika Anda memiliki bug, Anda akan langsung tahu di mana letaknya di dalam kode karena Anda baru saja meng-compile
dan baru saja menambahkan baris atau jumlah baris tersebut.
Sekali lagi, saya tidak dapat menekankan pentingnya debugging menulis kode berkualitas tinggi, mencegah kesalahan.
Teknik-teknik pemecahan masalah ini akan menghemat banyak waktu dan membuat Anda menjadi programmer yang jauh
lebih baik.
Jadi dalam beberapa kuliah berikutnya, saya ingin berbicara tentang beberapa kesalahan umum yang kita lihat dalam bahasa
pemrograman c.
Selain itu, saya juga ingin membahas sedikit tentang tumpukan panggilan.
Saya ingin membahas debugger yang memperkenalkan Anda pada opsi menu dan bagaimana Anda dapat menghentikan dan menjalankan jam
tangan dan sebagainya.
Dan saya juga ingin membantu mengidentifikasi beberapa kesalahan kompiler yang umum terjadi sehingga Anda dapat melihat bagaimana menafsirkan kompiler, peringatan
dan kesalahan kompiler.
Apa artinya jika penyusun mengatakan ini?
Apa artinya jika kompiler memberi Anda peringatan ini?
Terima kasih.