Berhentilah Membuang Waktu untuk Kesalahan Pengkodean. Perbaiki Sekarang.

Saya masih ingat perasaan itu. Proyek yang bersih dapat berubah menjadi berantakan dalam beberapa detik ketika satu kesalahan pengkodean kecil merusak keseluruhan alur. Halaman berhenti memuat. Aplikasi mogok. Sebuah tombol tidak melakukan apa pun. Bugnya mungkin terlihat kecil, namun mencuri fokus dan memperlambat segalanya. Ketika itu terjadi, saya tidak mencoba menebak-nebak. Saya memperlambat, melihat kode dengan jelas, dan memperbaiki sumbernya selangkah demi selangkah. 1. Saya membaca pesan kesalahan sebelum saya menyentuh kodenya. Banyak orang melewatkan pesan tersebut dan langsung mengedit. Saya juga pernah melakukan hal itu. Hal itu biasanya memperburuk keadaan. Pesan kesalahan yang bagus sudah memberikan petunjuk. Ini mungkin menunjuk ke nama file, nomor baris, atau nilai buruk. Jika pesan mengatakan suatu variabel tidak terdefinisi, saya memeriksa nama itu sebelum yang lainnya. Jika dikatakan suatu fungsi tidak ditemukan, saya mencari kesalahan ejaan atau impor yang hilang. Contoh kecil: Saya pernah menghabiskan dua puluh menit untuk mengejar bug di JavaScript. Halaman tersebut terus gagal, dan saya pikir masalahnya ada di dalam panggilan API saya. Masalah sebenarnya adalah kesalahan ketik sederhana. Saya menulis userNmae alih-alih userName. Pesan kesalahan telah mengisyaratkan masalahnya. Saya hanya mengabaikannya di awal. Kesalahan itu mengajari saya sebuah aturan sederhana: baca pesannya, lalu bertindak. 2. Saya memeriksa perubahan terakhir yang saya buat. Kebanyakan bug muncul tepat setelah perubahan. Baris kode baru. File yang diganti namanya. Suatu kondisi yang tampaknya tidak berbahaya. Saya bertanya pada diri sendiri, “Apa yang saya sentuh sebelum ini pecah?” Pertanyaan itu menghemat banyak waktu saya. Jika kodenya berfungsi sebelumnya, saya membandingkan versi lama dengan yang baru. Saya mencari: - nama variabel berubah - tanda kurung hilang - tanda kutip rusak - jalur file salah - logika tidak lagi sesuai dengan tujuan Langkah ini berfungsi dengan baik karena mempersempit pencarian. Saya tidak perlu memeriksa setiap baris dalam proyek. Saya hanya perlu fokus pada bagian yang berubah. 3. Saya menguji bagian-bagian kecil, bukan keseluruhan sistem. Blok kode yang besar dapat menyembunyikan masalah sebenarnya. Ketika saya membagi masalah menjadi beberapa bagian yang lebih kecil, saya dapat melihat di mana kesalahannya dimulai. Saya menguji satu fungsi. Saya mencatat satu nilai. Saya memeriksa satu permintaan. Itu memberi saya pandangan yang lebih bersih. Misalnya, jika suatu formulir tidak dikirimkan, saya tidak berasumsi seluruh formulir rusak. Saya menguji nilai input terlebih dahulu. Lalu saya memeriksa pengendali kirim. Lalu saya melihat permintaan jaringan. Sangat sering, serangga itu berada di satu tempat kecil. Pendekatan ini terasa lebih lambat pada awalnya, namun biasanya menghemat lebih banyak waktu. Aku berhenti mengejar bayangan. 4. Saya menggunakan log seperti senter Log konsol sederhana, namun sangat membantu. Saya mencetak nilai pada titik-titik penting sehingga saya dapat melihat apa yang dilakukan kode tersebut. Saya menggunakannya untuk memeriksa: - data apa yang masuk - perubahan apa setelah fungsi berjalan - apa yang keluar dari komponen atau titik akhir - di mana nilainya berhenti sesuai dengan rencana saya Kasus nyata dari pekerjaan saya: Saya membantu dengan aplikasi React yang memperlihatkan kartu pengguna kosong. Panggilan data berhasil, sehingga tim mengira masalahnya ada di API. Saya menambahkan beberapa log dan menemukan bahwa bentuk responsnya berbeda dari yang diharapkan UI. Aplikasi menginginkan data.user.name, tetapi API mengirimkan data.profile.name. Satu ketidakcocokan kecil, satu layar kosong. Log mengubah bug yang tidak jelas menjadi perbaikan yang jelas. 5. Saya membandingkan keluaran yang diharapkan dengan keluaran aktual. Kebiasaan ini membuat saya tetap membumi. Saya menuliskan apa yang saya harapkan dari kode tersebut, lalu saya memeriksa apa yang sebenarnya dilakukannya. Kesenjangan itu sering kali mengungkapkan kesalahannya. Jika saya mengharapkan klik tombol untuk membuka modal, saya memeriksa tiga hal: - apakah peristiwa klik menyala - apakah status diperbarui - apakah modal menerima status baru Jika satu bagian gagal, saya tahu ke mana harus mencari selanjutnya. Saya tidak memperlakukan bug itu seperti novel misteri. Saya memperlakukannya seperti sebuah rangkaian. 6. Saya juga memeriksa hal-hal yang mudah. ​​Beberapa bug bersembunyi di depan mata. Koma yang hilang. Spasi di dalam jalur file. Kunci API yang salah dalam penyiapan lokal. Masalah cache browser. Masalah-masalah tersebut dapat membuang banyak energi karena terlihat terlalu sederhana untuk menjadi penyebabnya. Saya pernah memperbaiki unggahan gambar yang rusak dengan mengubah satu jalur folder. Kode itu sendiri baik-baik saja. Jalur menunjuk ke direktori yang salah setelah penerapan. Saya telah memeriksa logikanya dua kali, namun jawabannya ada di nama file. Cek sederhana bukanlah cek kecil. Mereka adalah bagian dari pekerjaan. 7. Saya membuat daftar singkat penyebab umum Seiring berjalannya waktu, saya melihat jenis kesalahan yang sama muncul berulang kali. Inilah yang paling sering saya perhatikan: - kesalahan ejaan dalam nama variabel atau fungsi - impor hilang - tipe data salah - logika perulangan tidak satu per satu - jalur file buruk - respons API tidak cocok - status tidak diperbarui saat diharapkan - kondisi ditulis dengan cara yang salah Saya tidak mengandalkan memori saja. Saya menyimpan daftar ini di dekat ruang kerja saya. Ini membantu saya tetap tenang ketika kode mulai bermasalah. 8. Saya meminta bantuan setelah saya memeriksa dasar-dasarnya. Saya tidak menganggap bantuan sebagai pilihan terakhir. Saya menganggapnya sebagai langkah cerdas setelah saya mengesampingkan penyebab sederhananya. Jika saya mengalami kebuntuan terlalu lama, saya menunjukkan kode tersebut kepada rekan satu tim atau membandingkannya dengan dokumen tepercaya. Sepasang mata yang segar dapat melihat apa yang saya lewatkan dalam hitungan menit. Karena itu, saya mencoba mengajukan pertanyaan yang jelas. Saya menjelaskan apa yang saya harapkan, apa yang saya lihat, dan apa yang sudah saya periksa. Itu membuat percakapan itu bermanfaat. Itu juga menghormati waktu semua orang. Saya percaya proses debug yang baik adalah keterampilan, bukan tebakan. Perbaikan tercepat tidak selalu merupakan solusi terpintar. Biasanya ini dibangun berdasarkan langkah-langkah yang tenang, pemeriksaan yang jelas, dan pembacaan kode yang jujur. Ketika saya bekerja dengan cara ini, saya membuang lebih sedikit energi, membuat lebih sedikit kesalahan berulang, dan belajar lebih banyak dari setiap bug. Jika kode Anda rusak hari ini, mulailah dari yang kecil. Baca pesannya. Periksa perubahan terakhir. Uji satu per satu. Jawabannya seringkali lebih dekat daripada yang terlihat.

Saya tahu seperti apa rasanya suara serangga. Kesalahan kecil muncul, dan seluruh alur kerja melambat. Sebuah tombol berhenti bekerja. Formulir menolak masukan yang valid. Sebuah laporan menunjukkan nomor yang salah. Saya telah melihat tim kehilangan fokus berulang kali karena mereka terus mengejar masalah yang sama dari sudut pandang yang berbeda. Yang biasanya paling menyakitkan bukanlah bug itu sendiri. Itu adalah bolak-balik. Pengembang menebak. Penguji menguji ulang. Tim dukungan mendengarkan keluhan tersebut. Pengguna menunggu. Semua orang tetap sibuk, namun masalahnya tetap terbuka. Pandangan saya sederhana: bug seharusnya tidak mengontrol hari kerja. Saya fokus pada proses perbaikan bug yang membantu tim bergerak dengan lebih sedikit stres dan lebih sedikit masalah yang berulang. Saya mulai dengan jalur pengguna. Saya mengajukan satu pertanyaan: di manakah kegagalan muncul pada orang yang menggunakan produk? Formulir pembayaran mungkin berfungsi di desktop dan gagal di seluler. Halaman login mungkin menerima kata sandi yang benar dan masih memblokir akses karena masalah bidang tersembunyi. Dasbor mungkin dimuat, namun nomor kunci mungkin tidak diperbarui setelah penyegaran. Ini adalah masalah yang menguras tenaga, karena tersembunyi dalam penggunaan normal. Lalu aku mempersempit pelatuknya. Saya memeriksa browser, perangkat, jenis input, peran pengguna, dan status halaman. Saya membandingkan apa yang berhasil dengan apa yang rusak. Langkah ini menghemat banyak tebakan. Sebuah tim e-commerce kecil pernah menghadapi masalah checkout yang hanya muncul di satu browser Android. Tombol pembayaran terlihat baik-baik saja, tetapi formulir pengiriman mengalami masalah validasi diam-diam. Kotak masuk dukungan mereka dipenuhi dengan pesan “Saya tidak dapat membayar”. Setelah mereka menelusuri masalahnya ke satu aturan lapangan, perbaikannya cepat. Bagian tersulitnya adalah menemukan penyebab sebenarnya. Cerita itu biasa terjadi. Banyak masalah bug yang berkembang karena orang-orang menangani gejalanya dan mengabaikan sumbernya. Proses saya tetap praktis: - Reproduksi masalah dalam pengaturan yang bersih - Tuliskan langkah-langkah tepat yang memicunya - Periksa log, kesalahan, dan perilaku browser - Bandingkan jalur yang berfungsi dan jalur yang rusak - Perbaiki satu akar permasalahan dalam satu waktu - Uji kembali jalur yang sama setelah perbaikan - Buat catatan singkat agar masalah yang sama tidak kembali Saya suka pendekatan ini karena membuat pekerjaan tetap sederhana. Tidak ada suara. Tidak ada lingkaran dugaan. Saya juga memperhatikan komunikasi. Jika saya menemukan bug, saya menjelaskannya dengan kata-kata sederhana: apa yang dilakukan pengguna apa yang dilakukan sistem apa yang seharusnya terjadi apa yang terjadi? Kebiasaan kecil itu membantu tim bergerak lebih cepat. Catatan bug yang jelas dapat menyelamatkan pengembang dari membaca sepuluh pesan dan lima tangkapan layar hanya untuk memahami masalahnya. Saya juga berpikir pencegahan itu penting. Daftar periksa yang baik sebelum rilis dapat mendeteksi masalah kecil sebelum pengguna melihatnya. Saya memeriksa formulir, kasus tepi, pesan kesalahan, tampilan seluler, tautan rusak, dan perilaku pemuatan dasar. Saya mencari tempat di mana pengguna dapat mengeklik, mengetik, menyegarkan, mundur, atau berpindah layar. Di situlah banyak bug bersembunyi. Pendapat saya sederhana: suatu produk terasa lebih dapat diandalkan ketika tim menghormati pemeriksaan kecil ini. Pekerjaan itu tidak membutuhkan drama. Perlu konsistensi. Jika bug terus membuat tim Anda keluar jalur, saya akan mulai dengan jalur pengguna, pemicu, dan pencatatan. Itu saja dapat mengurangi banyak usaha yang sia-sia. Hal ini juga membuat perbaikan berikutnya lebih mudah, karena tim tidak memulai dari nol. Saya suka perangkat lunak yang terasa stabil. Pengguna juga merasakannya. Ketika sistem bekerja sesuai harapan orang, tiket dukungan berkurang, tim tetap lebih tenang, dan produk mendapatkan lebih banyak kepercayaan dengan perbaikan yang bersih dalam satu waktu.

Saya dulu berpikir kode bersih adalah pilihan gaya. Saya tidak melihatnya seperti itu lagi. Ketika kode menjadi berantakan, setiap perubahan kecil berubah menjadi pencarian tanda kurung yang hilang, logika tersembunyi, dan perbaikan lama yang tidak diingat oleh siapa pun. Rasa sakitnya muncul dalam pekerjaan sehari-hari. Seorang rekan satu tim meminta pembaruan sederhana, dan tugas tersebut berkembang menjadi pekerjaan perbaikan yang lambat. Ada bug yang masuk. Peninjauan memakan waktu terlalu lama karena pembaca harus menebak maksudnya. Saya peduli dengan kode bersih karena melindungi waktu dan kepercayaan. Saya ingin kode yang dapat dibaca orang lain tanpa menebak-nebak. Saya ingin kode yang menceritakan kisah fitur tersebut dari atas ke bawah. Saya juga ingin lebih sedikit kejutan ketika produk berubah. Inilah cara saya menanganinya: - Saya menyebutkan hal-hal seperti saya sedang berbicara dengan rekan satu tim. Jika suatu variabel menampung jumlah item dalam keranjang, saya menyebutnya cartItemCount. Saya tidak menyembunyikan makna di balik jalan pintas yang hanya masuk akal bagi saya. - Saya menyimpan satu fungsi pada satu pekerjaan. Fungsi panjang yang memeriksa pembayaran, menghitung pajak, mengirim email, dan menulis log sulit dipercaya. Saya membaginya. Setiap bagian mempunyai tujuan yang jelas. - Saya menghapus kode yang tidak lagi sesuai dengan produk. Logika lama mungkin terlihat tidak berbahaya. Seringkali hal ini menimbulkan keraguan. Jika suatu aturan hilang, saya mengambil cabang lama sehingga tidak ada yang perlu menguji jalur hantu nanti. - Saya menulis komentar karena alasan, bukan karena kode yang jelas. Saya tidak menjelaskan apa yang sudah dikatakan dalam sebuah baris. Saya menjelaskan mengapa ada pilihan. Itu membantu ketika aturan bisnis berubah. - Saya menguji bagian yang bisa pecah. Saya melihat halaman checkout gagal karena aturan kupon dan aturan pengiriman menggunakan bidang yang sama dengan cara yang berbeda. Sebuah rangkaian pengujian kecil mengungkap masalah tersebut sebelum lebih banyak pengguna yang menemukannya. Setelah itu, tim dapat mengubah kode dengan lebih sedikit rasa takut. Saya juga membaca kode saya sendiri seperti yang dilakukan orang asing. Kebiasaan itu mengubah pekerjaan saya. Jika saya perlu menjeda dan memecahkan kode sebuah blok, saya tahu kode tersebut meminta bentuk yang lebih bersih. Saya menulis ulang sebelum orang berikutnya membayar biayanya. Kode yang bersih bukan tentang membuat setiap file terlihat sempurna. Saya lebih mementingkan kejelasan daripada polesan. Struktur sederhana membantu saya bergerak lebih cepat nantinya. Pintasan yang berantakan sekarang mungkin menghemat sepuluh menit, lalu memerlukan waktu satu jam dari perubahan berikutnya. Saya telah merasakan perdagangan itu berkali-kali. Aturan saya sederhana. Jika rekan satu tim membuka file saya, saya ingin langkah selanjutnya terasa alami tanpa perlu ditebak. Pola pikir itu membuat pekerjaan tetap stabil. Hal ini juga membuat peninjauan kode menjadi lebih mudah, perbaikan bug menjadi lebih tenang, dan fitur baru bekerja lebih ringan. Kode bersih dimulai sekarang, bukan setelah rilis berikutnya, dan bukan setelah sprint pembersihan berikutnya. Saya mulai dengan satu fungsi, satu nama, satu tes, satu perbaikan kecil. Itu cukup untuk mengubah bentuk basis kode. Tertarik untuk mempelajari lebih lanjut tentang tren dan solusi industri? Hubungi wzsanying: 780877550@qq.com/WhatsApp 13858841904.

Robert C Martin 2008 Clean Code Buku Pegangan Keahlian Perangkat Lunak Agile Andrew Hunt dan David Thomas 1999 Pemrogram Pragmatis Dari Journeyman hingga Master Martin Fowler 2018 Refactoring Meningkatkan Desain Kode yang Ada John Sonmez 2015 Panduan Karir Pengembang Perangkat Lunak Lengkap Kent Beck 2002 Test Driven Development By Contoh Steve McConnell 2004 Code Complete Buku Pegangan Praktis Konstruksi Perangkat Lunak