Read, Curse, Patch, but Don’t Throw It Away

Saat saya diwawancara salah satu perusahaan software, saya ditanya: “In your opinion, what is good code?”. Tik, tuk, tik, tuk, jam di lab sudah mendekati tengah malam, ngantuk dan dag-dig-dug takut ketinggalan MRT sayapun memulai kicauan saya. Salah satu poin kicauan saya adalah, readability of the code. Intinya, pikiran saya yang masih agak ideal waktu itu menganggap bahwa code yang baik adalah code yang bisa dibaca dan dengan mudah dimengerti oleh orang lain sehingga code tersebut di masa mendatang mudah diubah sesuai kebutuhan meski si penulis code tersebut sudah berada di antah berantah. How one can maintain code if one cannot understand it, right? With great readability comes great maintainability! :)

Coba mari kita buka lembaran-lembaran lama masa kuliah. Kalau masa kuliah itu kan rata-rata masih masa bermain dan bersenang-senang yah, jadi kalau ada tugas datang (ga peduli tugas itu kelompok atau pribadi) pasti dikerjakan untuk mencapai tujuan utama! Sesuai spesifikasi (spek) dari dosen/asisten dan disubmit sebelum setepat-mungkin-dengan deadline (syukur-syukur kalau bisa ngerjain spek bonus :)). Di masa-masa nan indah itu, kalau deadline masih hitungan minggu biasanya kodenya cantik nan ciamik. Nah, begitu H-2, H-1, atau bahkan pada hari H saat sadar kalau tugas kita masih jauh dari kata “Selesai”, mulailah kita membabi buta mengejar deadline. Kode yang tadinya masih sangat cantik dengan nama variabel: totalPembelian, jumlahUangDibayar, isLoopFinished, dll; tiba-tiba penuh dengan: i, ii, iii, a, abc, zzzzz. Apa sih itu? Ga tau, yang penting jadi dulu programnya! Hal yang bikin keki adalah saat kita harus memperbaiki kode seperti itu! Ga ada dokumentasi, ga ada penjelasan sama sekali di dalam kodenya, nama variabel yang menggunakan bahasa alien. Graoooo, minta digampar banget kan.

Itu kisah mahasiswa kan, ga masalah donk, wonk tugas itu ga bakal disentuh-sentuh lagi abis dikumpulin, iya toh? Orang yang baca kodenya juga cuma segelintir orang aja kok. Beda ceritanya kalau uda masuk ke dunia sebenarnya, ga bisa lagi kaya gitu lah, harus bersih, rapi, mudah dibaca, since hasil karya kita itu bakal dibaca dan dipakai banyak orang, belum lagi kalau mau mengembangkan proyeknya, wah prinsip readable and reusable code harus benar-benar diaplikasikan! Is it correct?

Theoretically, yes! However……… Dunia itu tidak seindah daun kelor. Mungkin ada satu dua orang yang berpikiran mulia seperti itu, sayangnya lebih banyak orang yang memilih jalan pintas. “Gua dibayar untuk kerja, saya uda kerja, yaudahlah, ga usah bagus-bagus kerjaannya, bukan kantor babe gua ini”. Selepas dari dunia kampus dan laboratorium, tercemplunglah saya pada realita hidup sesungguhnya, bekerja! Software engineer judulnya, dan mulailah saya mengerjakan proyek-proyek yang diberikan.

Dalam setiap proyek, tidak pernah ada cerita saya harus membuat dari awal. Either use previous code or ask other software to generate our base code. Untuk hal yang kedua sih oke lah, kodenya tentu masih bersih dan rapi jali. Tapi, apa yang terjadi kalau harus memakai kode yang sudah diutak-atik sekian puluh orang? Jreng-jreng-jreng. A lot of comment inside the code! Jangan bayangin komentar yang ditulis itu menjelaskan fungsi yang ada, komentar dalam kode biasanya adalah kode lain yang entah kenapa dikomen tanpa penjelasan.

Belum lagi standar indentasi yang super berantakan (efek dari sekian banyak orang yang memodifikasi), nama variabel yang juga tidak jelas aturannya (untungnya, kayanya ga pernah ada deh orang yang nulis nama variable “aaaaa” atau “abcde” di dunia kerja; if you see one, just ask your manager to kick his ass out of your office asap :p), atau yang paling sering adalah redundansi kode. Bayangin aja, ada satu program yang harus menulis sebuah log file. Pada saat pertama kali dibuat, hanya ada satu bagian yang perlu, sehingga si penulis kode awal menulis operasi file dan penulisan log di bagian itu. Beberapa bulan kemudian, ternyata bagian lain juga membutuhkan penulisan log file, akhirnya penulis kode lain yang malas mencari tahu dan mengubah bagian lain, membuat fungsi operasi file dan penulisan log di bagian lain tersebut. Now, we have two same code. Bayangkan ada 2-3 orang lain yang melakukan hal serupa setelahnya. Lalu, seorang lain diminta untuk mengubah format penulisan log yang telah ada. Permintaan pengubahan formatnya mudah, coba tolong tambahkan titik di akhir setiap baris. Simpel kan. Tulis aja “.”. Kasih tiga juga ga masalah “…”.  Gampang! Saat dia mengubah di satu bagian, dia pun berpikir: masalah selesai. Tapi apa yang terjadi kalau kode tersebut dijalankan? Lho, kok ini ga ada titiknya? Diubah lagi bagian lain, dicoba lagi, lho, kok titiknya ilang lagi? Setelah orang terakhir membaca seluruh kode yang ada, dia pun mengutuki orang-orang yang menulis kode tersebut. Kenapa sih ga digabung aja kodenya? They are the same!!!

Cerita lain, sebuah  software house berusaha membuat sebuah online game, fitur-fitur ditambahkan, dan setelah sekian tahun, terjadilah pembicaraan kurang lebih seperti berikut:

A: Ini kenapa sih kok crash mulu gamenya.

B: Iya nih, kayanya karena fitur baru yang ditambahin deh, sebelom ditambahin oke kok.

A: Yauda, ilangin dulu deh bentar, mau didemoin dulu nih.

B: Oke, diapus yah…… (sekian detik kemudian) Tuh udah.

A: Oke, sini dicoba. (lima menit berselang) Lho, kok masih crash sih???

B: Eh? Iya yah, kenapa yah??? (mulai bingung) Coba deh fiturnya tambahin lagi.

A: Uda belom?

B: Bentar, dikit lagi.

A: Uda?

B: Coba gih.

(Sepuluh menit kemudian)

A: Hmmmm….

B: Gimana?

A: Bentar.

(Lima menit kemudian)

A: Hmmm, kok sekarang gapapa sih? Diapain tadi?

B: Ga diapa-apain?

A: Lho????

C: Eh, kok di sini tiap menit crash mulu yah?

A: Oh, man… Kayanya masalah memori deh ini. Udalah tulis ulang aja semuanya! Masalahnya uda ga jelas nih.

Percakapan seperti di atas bukan hanya terjadi sekali dua kali, tapi sudah tak terhitung banyaknya. Ada yang bertanya: jadi akhirnya nulis ulang donk? Nope, kode tersebut ga ditulis ulang, tapi setiap ada percakapan tersebut, dicarilah masalah yang kadang sudah ada dari sekian tahun sebelumnya dan diperbaiki. Hampir setiap kali seperti itu, hampir setiap kali harus mencari masalah yang entah dari mana datangnya, hampir setiap kali muncul pernyataan untuk menulis ulang kode tersebut. Pertanyaannya, kenapa ga pernah ditulis ulang? Bukannya lebih cepat?

Dua perusahaan besar, Netscape dan Borland, pernah melakukan hal tersebut. Mereka memutuskan menulis ulang kode program mereka dari awal. Hasilnya? Well….. Banyak orang yang bilang kalau itu adalah keputusan terburuk yang pernah diambil.

Kode yang ada sekian lama dan terus menerus digunakan dan diperbaiki biasanya tidak akan “manis” ataupun “cantik”. Akan ada banyak tambal sulam, akan banyak komentar-komentar ga jelas, akan banyak fungsi-fungsi yang dikomentari dan ditutup. Kadang sangat susah membacanya apa lagi mengerti isi kode tersebut, atau simply memunculkan pertanyaan: ini kenapa ditutup gini yah fungsinya? Masalahnya sama seperti yang ditulis di artikel ini: Things You Should Never Do, semua “kekacauan” itu muncul dari hasil testing sekian lama. Mungkin saja satu bagian dimatikan fungsinya karena ternyata membuat program tidak stabil, sebagian dimatikan akibat membuat performa tidak maksimal, atau satu bagian memang sengaja dibuat redundan. Mungkin kesalahan pada kode tersebut hanya satu, kurangnya dokumentasi yang baik sehingga tidak mudah mengubahnya. Apapun itu, suatu kode tidak layak dibuang hanya karena hal tersebut.

Kalaupun diputuskan untuk menulis ulang semua kode tersebut, apakah kode yang ditulis menjadi lebih bagus atau dapat memiliki performa yang sama dari kode yang telah dikerjakan sekian tahun?

Well, at the end of this story, apabila anda memiliki kode yang telah dikerjakan sekian lama. Tidak peduli seburuk apapun itu, tentu masih bisa diperbaiki sedikit demi sedikit. Baca baik-baik, nge-dumel lah bila perlu, perbaiki satu per satu, tapi jangan pernah buang kode tersebut dan mulai dari awal. It’s just not worth your time, dude!

About these ads

Tags: ,

2 responses to “Read, Curse, Patch, but Don’t Throw It Away”

  1. leli says :

    jadi kalo udah kacau mending di baikin satu demi satu aja? hm. pernah sih kepikiran buat nulis ulang tp kadang ga semulus awal bikin

    • samsi says :

      tergantung kebutuhan sih, kalau emang ada resource dan alasan yang cukup, bisa aja tulis ulang, cuma sebagian besar biasanya ga memungkinkan buat itu..

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 1,323 other followers

%d bloggers like this: