4. kalau programming, kecenderungannya trial and error. Programming itu
biasanya pasti ada masalah. Solusinya? cari code snippet pake google, coba
gabungkan dgn program, kalau jalan ayo teruskan, kalau gak jalan, coba cari
lagi yg lain. Gak tau kenapa kecenderungannya kalau di depan komputer itu
trial and error. Seolah2 tujuan itu hanya supaya program jalan. Apalagi
kalau udah di kejar2 deadline.
Ini lama-lama jadi seperti sebuah mitos, bahwa keberadaan Internet dan
Google akan menyelesaikan semua masalah, termasuk masalah programming.
Padahal, justru itu hanya salah satu faktor saja (dianggap sebagai
infrastrukur). Kemudahan mencari informasi malah dapat menjerumuskan
sehingga orang berpikir secara instant.
Akhir dgn kecenderungan tadi, aku kehilangan kontrol sama codeku. And
kemudian aku butuh bug tracking seperti fogbuzz nya joel on software. I
don't really agree with bug tracking. Dengan bug tracking kelihatannya
developer udah kehilangan kontrol (seolah2 ada ribuan bug). Akhirnya mulai
lah bug development cycle.
Bug tracking itu penting sekali karena programer tidak bisa mengingat
semua bug di kepalanya. Catatan yang ada di dalam bug tracker juga
pantas digunakan untuk merancang pengembangan ke arah masa depan.
Dalam kasus open-source, bug tracker juga merangkap sebagai buku
komunikasi karena patch, komentar, screenshot, dokumen tes, dan
semacamnya bisa ditempelkan ke dalam bug tersebut sehingga tidak mudah
hilang.
Tapi realita adalah kita gak nulis OS sendiri, compiler sendiri. Belum
lagi kebergantungan sama API (API programmer :). Kalau ada masalah sama API
cuman bisa nangis. Ini mungkin menghasilkan bug. Untuk kasus ini, mungkin
perlu bug tracking.
Kalau belum betul-betul fatal, biasanya selalu ada workaround untuk
problem semacam ini. Makanya terkadang bekerja dengan toolkit (Qt,
GTK+, wxWidgets) lebih menguntungkan di sini karena banyak workaround
untuk bug-bug dari layanan OS-nya sudah ditangani (tentu, selama
toolkitnya sendiri tidak mengandung bug lain lagi).
Contoh kasus favorit saya adalah listview control di Win32. Normalnya,
kalau listview ini dibuang dari memori, akan ada message
LVN_DELETEALLITEMS sehingga si program bisa juga menghapus data-data
yang terkait dengan masing-masing item di listview tersebut. Menurut
dokumentasi MSDN, setelah LVN_DELETEALLITEMS ini, tidak akan ada lagi
message LVN_DELETEITEM (yang hanya menghapus satu item). Tetapi
nyatanya dalam beberapa versi comctl32.dll, ada bug sehingga setelah
mengirim LVN_DELETEALLITEMS, Windows masih mengirim LVN_DELETEITEM
sehingga program bisa crash karena double deletion.
Nah, untuk ngambil kontrol itu, makanya aku pilih gontok2an, pilih nulis
dokumen detail, dan kalau bisa pilih nulis code di kertas bukan di
computer. Ini kebalikan dari bug tracking, yaitu ngetrack gimana program
jalan.
Tidak sama karena bug tracker untuk (mayoritas) menyimpan bug-bug
karena perilaku program tidak sesuai dengan implementasinya, bukan
karena gagasan untuk implementasi (alias desain utama) yang salah.
Menulis dan merancang desain di awal-awal hanya menentukan arah jalan
yang dituju adalah benar, tetapi tidak tidak menjamin bahwa nanti
tidak akan terjadi jatuh-bangun selama jalan tersebut dilewati. Lihat
contoh bug listview di atas.
Test Driven kelemahannya, hampir gak mungkin nulis semua test. Dan dengan
test driven, sebenarnya kontrol udah kita kasih ke test code yg kita tulis.
Kembali seperti yg dikatakan Djikstra bahwa test itu bagus untuk menemukan
bug, tapi tidak bisa memastikan bahwa gak ada bug. Dia berpendapat bahwa
sebaiknya programming itu di kembalikan ke math. Cuman gak terlalu ngerti
maksudnya, apakah berarti lisp? :)
Mungkin maksudnya menggunakan metoda formal untuk analisis programnya.
Tentang regression test, memang tidak ada jaminan (dan memang tidak
akan pernah ada) bahwa programnya bug-free. Tetapi tetap saja lebih
baik ada test daripada tidak ada. Seperti sudah saya tulis, kelebihan
regression test itu adalah karena otomatisasinya: sekali dijalankan,
banyak test. Bandingkan kalau semuanya harus satu per satu.
Let me admit again, i am fan of Djikstra. :) dia bisa nulis OS di kertas
untuk suatu mesin, padahal mesinnya belum ada. Dan ketika mesinnya jadi, OS
nya jalan perfectly.
Tapi nggak semua orang seperti Djikstra :-P
--
http://www.google.com/search?q=ariya+hidayatbtnI
