7 Teknik Debugging Untuk Mempercepat Pemecahan Masalah dalam Produksi

Menyediakan dukungan produksi untuk aplikasi adalah salah satu aspek yang paling menantang dari pengembangan perangkat lunak. Pengembang ditugaskan ke tim pemeliharaan dan bekerja untuk memperbaiki bug pada aplikasi. Namun, mereka juga tersedia sesuai panggilan jika terjadi pemadaman produksi, dalam hal ini mereka bekerja untuk mengembalikan aplikasi ke jalurnya secepat mungkin.

Artikel ini bertujuan untuk memberikan serangkaian rekomendasi yang dikurasi sehingga Anda dapat mencegah bug dalam produksi, dan menemukan masalah lebih cepat. Menangani aplikasi ini dalam produksi adalah tugas yang rumit: Seringkali, tidak ada dokumentasi yang tersedia, aplikasi telah ditulis dalam tumpukan teknologi lama, atau keduanya. Ada sangat sedikit sesi pelatihan, dan biasanya dipanggil untuk memberikan dukungan bagi aplikasi yang hanya sedikit Anda ketahui.

Banyak pengembang tidak memiliki pengalaman menangani aplikasi dalam produksi. Ada serangkaian masalah yang terjadi di lingkungan produksi yang menyebabkan bug dan pemadaman, umumnya menyebabkan ribuan dan terkadang jutaan dolar kehilangan pendapatan bagi perusahaan. Selain itu, karena sebagian besar pengembang tidak memiliki paparan lingkungan, mereka terus membuat beberapa kesalahan yang pada gilirannya akan menyebabkan masalah tersebut. Daftar tips ini akan membuat pekerjaan Anda tidak terlalu menyakitkan dengan mengajar dari pengalaman produksi.

Tip #1: Hapus atau otomatisasi semua konfigurasi yang diperlukan untuk menjalankan aplikasi.

Berapa banyak konfigurasi yang diperlukan untuk menginstal perangkat lunak di server baru? Di masa lalu, ini terkadang membutuhkan waktu tiga hari untuk diselesaikan setiap kali ada pengembang baru dalam tim. Menginstal aplikasi akan membutuhkan banyak langkah yang harus dilakukan secara manual. Seiring waktu, perangkat lunak berkembang ke versi baru yang menjadi tidak kompatibel dengan instruksi tersebut, dan tentu saja, instruksi biasanya tidak diperbarui. Tiba-tiba, Anda menghabiskan lebih banyak waktu daripada yang diperlukan hanya untuk menjalankan dan menjalankan aplikasi.

Dengan munculnya containerization, menyediakan cara untuk menjalankan dan menjalankan aplikasi dalam waktu singkat, dengan nol konfigurasi dan dengan manfaat tambahan, karena image Docker mandiri, Anda menjalankan jauh lebih rendah risiko mengalami masalah dengan berbagai versi sistem operasi, bahasa, dan kerangka kerja yang digunakan.

Demikian juga, sederhanakan pengaturan pengembang, sehingga tidak membutuhkan banyak waktu untuk aktif dan berjalan, termasuk pengaturan IDE. Seorang pengembang harus dapat beralih dari nol menjadi pahlawan dalam waktu kurang dari 30 menit.

Ketika masalah produksi terjadi, terkadang ahli terbaik Anda mungkin tidak tersedia (misalnya, liburan atau sakit) dan Anda ingin siapa pun yang Anda lempar untuk mengatasi masalah tersebut, dan dengan cepat.

Tip #2: Jangan jatuh ke dalam perangkap sup tumpukan teknologi.

Semakin sedikit teknologi yang digunakan, semakin baik. Tentu saja, terkadang, Anda harus menggunakan alat yang tepat untuk pekerjaan itu. Namun, berhati-hatilah untuk tidak membebani "alat yang tepat." Bahkan air minum dapat menyebabkan masalah kesehatan yang serius jika Anda melakukannya terlalu banyak. Setiap bahasa dan kerangka kerja baru yang ditambahkan ke tumpukan teknologi harus melalui proses pengambilan keputusan yang jelas dengan mempertimbangkan dampaknya secara cermat.

• Jangan menambahkan dependensi kerangka kerja baru hanya karena Anda memerlukan kelas StringUtils .
• Jangan menambahkan bahasa yang sama sekali baru hanya karena Anda perlu menulis skrip cepat untuk memindahkan file.

Tumpukan ketergantungan yang besar dapat membuat hidup Anda sengsara ketika perpustakaan menjadi tidak kompatibel atau ketika ancaman keamanan ditemukan baik pada kerangka kerja itu sendiri atau pada ketergantungan transitifnya.

Selain itu, ingat, kompleksitas tumpukan yang ditambahkan membuatnya sulit untuk menemukan dan melatih pengembang baru untuk tim. Orang-orang beralih ke peran baru di perusahaan lain, dan Anda harus menemukan yang baru. Perputaran sangat tinggi di tim teknik, bahkan di perusahaan yang diakui memiliki fasilitas yang bagus dan keseimbangan kehidupan kerja. Anda ingin menemukan anggota tim baru secepat mungkin. Setiap teknologi baru yang ditambahkan di atas tumpukan teknologi meningkatkan waktu untuk menemukan kandidat baru dan berpotensi membuat karyawan baru semakin mahal.

Tip #3: Logging harus memandu Anda untuk menemukan masalahnya, bukan menenggelamkan Anda dengan detail yang tidak berguna.

Logging sangat mirip dengan komentar. Penting untuk mendokumentasikan semua keputusan penting yang diambil ditambah semua informasi untuk digunakan dalam teknik debugging Anda. Ini tidak sederhana, tetapi dengan sedikit pengalaman, dimungkinkan untuk memetakan beberapa kemungkinan skenario penghentian produksi dan kemudian memasukkan logging yang diperlukan untuk menyelesaikan setidaknya itu. Tentu saja, logging berkembang bersama dengan basis kode tergantung pada jenis masalah yang muncul. Secara umum, Anda harus memiliki 80% dari pencatatan Anda pada 20% yang paling penting dari kode Anda—bagian yang akan paling banyak digunakan. Informasi penting, misalnya, adalah nilai dari argumen yang diteruskan ke metode, jenis runtime dari kelas anak-anak, dan keputusan penting yang diambil oleh perangkat lunak—yaitu, waktu ketika berada di persimpangan jalan, dan memilih kiri atau kanan.

Tip #4: Tangani situasi yang tidak terduga.

Petakan dengan sangat jelas apa asumsi dari kode tersebut. Jika variabel tertentu harus selalu berisi nilai 2, 5, atau 7, pastikan itu bertipe enum, bukan int. Sumber nomor satu dari pemadaman produksi besar adalah ketika asumsi tertentu gagal. Semua orang mencari masalah di tempat yang salah karena mereka menganggap remeh beberapa hal.

Asumsi harus didokumentasikan secara eksplisit, dan setiap kegagalan asumsi tersebut harus menimbulkan peringatan yang cukup sehingga tim pendukung produksi dapat dengan cepat memperbaiki situasi. Juga harus ada kode untuk mencegah data masuk ke status tidak valid, atau setidaknya membuat semacam peringatan dalam kasus itu. Jika informasi tertentu harus disimpan dalam satu catatan, dan tiba-tiba ada dua catatan, peringatan harus dikeluarkan.

Tip #5: Seharusnya mudah untuk mereplikasi masalah yang terjadi pada pelanggan.

Salah satu langkah tersulit adalah selalu meniru masalah yang dihadapi pelanggan. Sering kali, Anda akan menghabiskan 95% waktu untuk mencoba mereplikasi masalah, dan saat Anda dapat mereplikasinya, hanya beberapa menit untuk menambal, menguji, dan menerapkan. Dengan demikian, arsitek aplikasi harus memastikan bahwa itu sangat sederhana dan cepat untuk mereplikasi masalah. Banyak dari ini terjadi karena, untuk mendapatkan situasi yang sama dengan pelanggan, pengembang harus melakukan banyak konfigurasi aplikasi. Ada banyak catatan yang disimpan yang secara bersama-sama memperumit situasi yang dialami pelanggan—masalahnya adalah Anda sebagai pengembang harus menebak dengan tepat apa yang dilakukan pelanggan. Dan terkadang, mereka telah melakukan serangkaian langkah, di mana mereka hanya mengingat yang terakhir.

Selain itu, pelanggan akan menjelaskan masalah tersebut dalam istilah bisnis, yang kemudian harus diterjemahkan oleh pengembang ke dalam istilah teknis. Dan jika pengembang kurang berpengalaman dengan aplikasi, mereka tidak akan tahu untuk menanyakan detail yang hilang, karena mereka bahkan belum mengetahui detail yang hilang. Menyalin seluruh basis data produksi ke mesin Anda tidak mungkin dilakukan. Jadi harus ada alat untuk dengan cepat mengimpor dari database produksi hanya beberapa catatan yang diperlukan untuk mensimulasikan situasi.

Katakanlah pelanggan memiliki masalah dengan layar Pesanan. Anda mungkin harus mengimpor beberapa pesanan mereka, catatan pelanggan mereka, beberapa catatan detail pesanan, catatan konfigurasi pesanan, dll. Kemudian Anda dapat mengekspornya ke database dalam instance Docker, meluncurkan instance itu, dan begitu saja, Anda melihat hal yang sama yang dilihat pelanggan. Semua ini, tentu saja, harus dilakukan dengan hati-hati untuk memastikan tidak ada pengembang yang memiliki akses ke data sensitif.

Tip #6: Harus jelas di mana menempatkan breakpoint dalam aplikasi.

Jika Anda memiliki layar Pelanggan, harus ada beberapa objek Pelanggan tempat Anda dapat menempatkan titik henti sementara untuk men-debug masalah di layar itu. Terkadang pengembang jatuh ke dalam demam abstraksi dan muncul dengan beberapa konsep yang sangat cerdas tentang cara menangani peristiwa antarmuka pengguna. Sebaliknya, kita harus selalu mengandalkan prinsip KISS (Keep it Simple, St— er, Konyol) dan memiliki satu metode yang mudah ditemukan per peristiwa UI. Demikian juga, untuk pekerjaan pemrosesan batch dan tugas terjadwal—seharusnya ada cara mudah untuk mengetahui di mana breakpoint tempat untuk menilai apakah kode itu berfungsi atau tidak.

Tip #7: Pastikan semua dependensi eksternal didokumentasikan secara eksplisit.

Idealnya, lakukan ini di file README di dalam sistem kontrol sumber sehingga dokumentasi tidak dapat hilang. Dokumentasikan sistem eksternal, database, atau sumber daya apa pun yang harus tersedia agar aplikasi dapat berjalan dengan benar. Juga, perhatikan mana yang opsional dan tambahkan instruksi tentang cara menangani saat opsional dan tidak tersedia.

Di luar Teknik Debugging

Setelah rekomendasi ini diikuti saat membuat fitur baru atau menyediakan pemeliharaan sistem, dukungan produksi akan menjadi jauh lebih mudah, dan perusahaan Anda akan menghabiskan lebih sedikit waktu (dan uang). Seperti yang sudah Anda ketahui, waktu sangat penting saat memecahkan masalah bug dan kerusakan produksi—setiap menit yang dapat dihemat membuat perbedaan besar pada intinya. Selamat mengkode!