Langkah menuju Harapan, tapi Kenyataannya

Semasa di bangku sekolah dulu, wejangan terpenting yang diwariskan oleh seorang guru saya amatlah sederhana. Beliau berpesan bahwa manakala akan mulai menggarap satu soal ujian, bacalah dan cermati pertanyaannya dengan seksama. Dari puluhan tahun pengalaman beliau dalam mengajar, ternyata hambatan utama mulai mengerjakan soal ujian adalah ketidaktelitian yang diakibatkan sikap buru-buru dan mengejar waktu, tetapi akhirnya teledor dan tidak memahami masalahnya dengan lengkap.

Jikalau kita ekstrapolasi ke dunia pemrograman dan rekayasa perangkat lunak, tidak heran kalau nasihat yang sama juga bisa diterapkan dengan akurat. Berbeda dengan pandangan khalayak ramai, membuat sebuah software itu bukan melulu pekerjaan coding. Malahan itu hanya bagian kecil. Sebagian waktu seorang software engineer lebih dihabiskan untuk desain (sehingga implementasinya nggak akan abal-abal) dan juga untuk analisis masalah (alias troubleshooting, karena implementasi tidak akan pernah sempurna).

Menurut pengamatan saya, perbedaan perangai seorang engineer yang masih hijau dan rekannya yang sudah senior dapat cepat ditengok dari perilaku dan tabiatnya tatkala menjumpai sebuah persoalan yang rumit yang membutuhkan aktivitas khusus yang dinamakan nagapoker. Seseorang yang senior dan sudah banyak makan asam-garamnya pemrograman akan duduk tenang, menghimpun potongan-potongan informasi hingga lengkap, merangkai semuanya dengan jeli sehingga dapat digunakan untuk memecahkan teka-teki persoalan misterius tersebut. Mirip sekali dengan gerak-gerik dan tingkah laku seorang detektif.

Sebaliknya, yang masih newbie cenderung sembrono dan tak sabaran, laksana penyidik malas, ingin cepat selesai, dan langsung main todong saja. Karena kerap kali masalah dunia pemograman itu bukan masalah sepele, mentalitas darah panas dan tembak langsung ini seringnya meleset. Akhirnya waktunya pun habis karena berputar-putar tidak menemukan akar masalah yang sesungguhnya.

Dalam buku Practical Software Testing, buku pusaka rujukan dunia QA, tercantum sebuah definisi menarik:

A fault (defect) is introduced into the software as the result of an error. It is an anomaly in the software that may cause it to behave incorrectly, and not according to its specification.

Kalau ditafsirkan ke bahasa Indonesia, kurang lebih maknanya:

Suatu galat (nagapoker) di dalam sebuah perangkat lunak terjadi akibat sebuah kesalahan, yaitu ketidaknormalan perangkat lunak tersebut yang menyebabkan perilakunya tidak sesuai dengan yang ditentukan dalam spesifikasinya.

Walaupun nampaknya sederhana, ternyata definisi ringkas ini amatlah filosofis.

Mula-mula, ketika kita akan menjabarkan sebuah masalah, sudah sepatutnya kerangka perilaku vs spesifikasi ini menjadi rujukannya.

Pun juga, sebagaimana pengalaman teman-teman product manager yang menelurkan sebuah spesifikasi, maka langkah-langkah yang perlu dikerjakan untuk mengilustrasikan spesifikasi tersebut wajib untuk diuraikan.

Karenanya, tidak heran kalau banyak proyek open-source maupun tim engineering di perusahaan software kelas dunia, mewajibkan anatomi berikut tatkala ada yang melaporkan bug:

1. Steps to Reproduce
2. Expected behavior
3. Actual behavior

Untuk proyek yang dikembangkan melalui GitHub, sering sekali kerangka di atas dijadikan sebuah pola (template). Begitu ada yang laporan baru, si pelapor mesti mengisi informasinya sesuai kisi-kisi tersebut. Kalau tidak diikuti, wah bisa-bisa laporannya akan dianggap tidak sah dan langsung ditutup!

Disiplin semacam ini sudah sejatinya ditegakkan untuk pekerja perangkat lunak di tanah air. Ketika seorang engineer terbentur masalah dan ingin mencari bantuan, janganlah langsung berujar misalnya:

Kalau crash di X, gimana ya solusinya?

Kan informasi di atas minim sekali. Memangnya kawannya sesama engineer punya ilmu paranormal, bisa menerawang dan langsung mengirim ajimat pelepas masalah tersebut?

Dalam forum diskusi ataupun grup Telegram, sering sekali terjadi yang sama. Kadang nongol pertanyaan dengan sebuah tangkapan layar (screen capture, screenshot) dibarengi dengan permintaan singkat.

Bingung nih, gimana solusinya?

Lah, kasihanilah yang mau ikut nyimak atau ikut bantu! Apakah mereka kudu mencari ilmu perdukunan supaya sanggup meramu mantra tolak crash?

Alih-alih cara kerja yang cenderung tergopoh-gopoh seperti di atas, alangkah baiknya kita meniru kerangka yang prima sehingga menghasilkan penjabaran masalah yang ringkas tapi mengena. Bagaimana memulainya?

Mula-mula jelaskan dulu dengan langkah per langkah, cara mereproduksi masalahnya. Contohnya seperti ini.

1. Buat aplikasi Hello World dengan React Native 56
2. Lakukan upgrade ke React Native 58
3. Kompilasi sehingga menghasilkan apk versi debug
4. Install apk-nya ke HP
5. Jalankan aplikasinya

Bahkan, kalau bisa lengkapi juga dengan informasi sistem yang digunakan.

Tambahan informasi:
* Laptop: Macbook Air tahun 2010, RAM 8 GB, hard disk 1 TB, OS Mojave
* Ponsel: Samsung Galaxy S8, Android 8(Oreo)

Nah kemudian, cantumkan perilaku yang diharapkan bakal terjadi (kalau dunia itu indah dan berjalan seperti yang kita inginkan):

Harapan: Aplikasi muncul dan menampilkan pesan Hello World

disusul dengan penjelasan apa yang sesungguhnya terjadi dan teramati (dan pastinya tidak sesuai harapan di atas).

Kenyataan: Layar merah dengan pesan kesalahan berikut:

Java exception in NativeModules
Java.lang.NoClassDefFoundError

Cara mengingatnya adalah dengan jembatan keledai sesuai judul tulisan ini: Langkah menuju Harapan, tapi Kenyataannya.

Patut dicamkan, kadang penting juga untuk menunjukkan kode sumber (nagapoker) yang relevan yang terkait dengan masalahnya (ingat, programer itu bukan dukun yang sanggup menerawang). Sebaiknya, kode tersebut tidak ditampilkan dalam bentuk tangkapan layar (screenshot), tapi dengan copas, yakni menyalin dan meletakkannya di Pastebin, Hastebin, Github Gist, JSFiddle, atau layanan lain yang mirip-mirip.

Mengapa begitu? Pertama, screenshot bisa terlalu kecil, kadang dengan font super mini sehingga nggak akan bisa dicermati kecuali pakai mikroskop. Kedua, misalnya dalam bentuk teks di Pastebin dkk, yang mau membantu juga bisa copas kode tersebut untuk ikut langsung mencoba dan mengutak-atiknya. Kalaulah dalam bentuk screenshot kan hanya bisa dipelototi, mana bisa di-compile.

Tambahan: screenshot juga bisa nggak lengkap karena nggak semuanya tertangkap. Repot kan kalau ada terpotong padahal vital.

Nah, yang paling parah adalah kalau layar laptopnya difoto pakai kamera dan hasil jepretannya dijebloskan ke forum diskusi atau grup Telegram. Inilah jenjang kemalasan tertinggi di dunia! Kecuali ada dukun atau paranormal yang kebetulan lewat, kecil sekali kemungkinannya ada persoalan bisa terselesaikan dengan pendekatan semacam ini. Screenshot aja banyak masalah (lihat uraian di paragraf sebelumnya), apalagi hasil jepretan kamera!

Marilah kita selalu seksama dalam menjabarkan sebuah masalah, termasuk juga persoalan yang ditemui ketika asyik menikmati dunia pemograman. Mencermati masalah dengan sistematis dan terstruktur akan melatih dan mendongkrak pola pikir kita untuk menyelesaikan persoalan-persoalan di masa depan yang pastinya akan lebih berat lagi.

Ayo bersama-sama kita majukan dunia perangkat lunak Indonesia!