Sepertinya paradigma yang dianut insinyur dan peneliti itu berbeda. Dalam bidang saya, Ilmu Komputer, misalnya. Di tim saya ada beberapa insinyur dan beberapa peneliti. Insinyur menekankan pentingnya kerapian, manajemen kode yang bagus, serta arsitektur yang efektif. Namun, di sisi lain, kadar kebaruannya rendah. Sementara, peneliti seperti Koh Eon cenderung tidak peduli terhadap hal-hal remeh temeh seperti ini, dan bahkan tidak suka menggunakan kaidah-kaidah pemrograman. Yang penting riset terus jalan, yang diinginkan bisa dicapai, dan paper terpublikasi. Hal ini juga saya lihat di kode sumber bikinan peneliti-peneliti lain di sekitar saya. Semuanya sama: berantakan. Saya pernah dimintai tolong seseorang dari lab sebelahnya lab saya yang dulu, dan saya kelabakan memahami kode sumber bikinannya. Nama-nama variabelnya mirip, kode sendiri disatukan dengan pustaka pihak ketiga, dan sebagainya.
Bagaimana dengan saya? Saya terjebak di antara keduanya. Saya sih mencoba untuk mengambil jalan tengah, yaitu dengan mengalokasikan waktu untuk mendesain arsitektur program implementasi riset saya yang ga berjalan mulus. Saya barusan, dengan kode yang halus mulus (yah barangkali > 90% sesuai dengan standar penulisan kode tim), menulis pembungkus untuk fitur graf dari sebuah pustaka pemrograman. Ini dikarenakan aturan dalam tim yang tidak mengizinkan penggunaan pustaka pihak ketiga secara langsung, karena kami menargetkan interoperabilitas yang mudah, dan kode harus terangkai selonggar mungkin. Untuk itulah ada kelas pembungkus tipis yang perlu dibuat. Setelah ini saya akan melakukan tes unit menggunakan Google Test. Barangkali proses ini tidak menyamai level pengujian yang dilakukan para pengembang perangkat lunak di industri, tapi ini sudah lumayan lah. Tentu saja ada kelemahan dari pilihan ini: lama. Ya maklumlah, saya perfeksionis. Bagaimanapun, saya tetap aja malas kalau musti mengatur file dan direktori di server SVN.
Akhirul kalam, tentu saja yang seperti ini tidak mutlak. Pustaka pemrograman seperti Boost dan CGAL berawal dari inisiatif para peneliti di akademia, dan tentu saja kode yang mereka tulis rapi jali. Dan tentunya dalam pembuatan konsep-konsep pemrograman seperti pemrograman generik, yang digunakan dalam STL, serta standar berikut C++, yaitu C++0x, peneliti-peneliti dari akademia berandil sangat besar. Walaupun, tentu, di halaman utama webpage pustaka SpharmonicKit, ada tertulis: (credit to EonStrife)
this is research code only and has not been hardened
Dilanjutkan kapan-kapan, kalau saya sudah mencapi seperempat status Donald Knuth.
PS: kalau boleh, saya meminta pendapat teman-teman programmer di industri seperti dnial dan yud1. Terima kasih ^:)^
PPS: Komik setopik dari xkcd.
Source: http://xkcd.com/844/
*puyeng sendiri bacanya…*
Dan yang komentar cuma 1 😦 (dua termasuk saya)
Code biasanya punya 2 tahap: Experimental, Prototyping, Coba-coba, proof-of-concept; dan kode dalam produksi, in real world, workable. Researcher biasanya hanya memproduksi kode-kode prototype, tidak perlu testing aneh2, cukup membuktikan bahwa konsep jalan (thus, proof of concept), sementara para progammer seperti aku kudu memastikan bahwa kode itu benar-benar jalan in real world.
Tugas programmer untuk memastikan bahwa kode itu jalan. Software Engineering diciptakan spesifik untuk memastikan hal itu. Ada sejuta macam metode yang seringkali untuk aplikasi kritikal sangat ketat, untuk beberapa didesain ringan untuk mempercepat time-to-market.
Kebaruan? Every combination of code never been used before.
*makin puyeng bacanya…*
@dnial
Bung…saya juga programmer.
Cuma ya itu, fokusnya beda sih. Agak repot juga kalau musti dites macem-macem kodenya. 😛
Masalahnya, tidak semua kebaruan itu laik publikasi. 😕
@Amd
*ikutan puyeng ah* @_@
BTW makasih komennya Mas dnial. 😛
Saya tambah lah komentarnya supaya jadi 7 (kalau dibales jadi 8 yah).
Anu….engineers dan researchers bertarung, kuli-ers mati ditengah-tengah….
*ikutan Amd, puyeng bacanya…..*
Kuli apaan. Situ kan pengalaman jadi engineer maupun researcher. 😐