Alasan Clean Code Penting bagi Bisnis

Keberlangsungan profit perusahaan bergantung pada kemampuan program dalam menerima perubahan.

Topik:

1. Kesempatan Bisnis dan Perubahan
2. Perubahan dan Clean Code
3. Clean Code Sejak Awal
4. Manfaat Refactoring
5. Bahaya Refactoring
6. Pengembangan Lambat Karena Mereka
7. Akhir Kata

Gambaran kode program. Sumber: [1]

Bayangkan Anda diperintahkan untuk mencabut kabel. Terdengar mudah bukan? Tapi bagaimana jika susunan kabel seperti gambar di atas. Salah cabut bisa mematikan perangkat dan tak sengaja menyenggol kabel lain. Menelusuri kabel dari ujung hingga ujung sampai yakin bahwa inilah yang harus dicabut. Tidak lagi 5 detik melainkan 15 menit untuk tugas ringan tadi. Itulah keadaan programmer yang berhadapan dengan kode yang tidak clean. Bisa saja bukan menit. Bisa mingguan. Bisa bulanan. Itu memperlambat kinerja.

Kesempatan Bisnis dan Perubahan

Clean code itu penting bagi bisnis. Apa yang diinginkan perusahaan dalam bisnis? Profit. Dari mana hal tersebut berasal? Opportunity. Seringkali menuntut perubahan. Akhirnya perusahaan harus mengubah software agar bisa mengambil kesempatan bisnis. “Pak calon pelanggan besar kita tidak mau menggunakan produk kecuali fitur XYZ ada ABC.”

Sebuah cerita startup yang sedang dalam ujung tanduk. Pekerja-pekerja dipecat. Pihak marketing berusaha mencari solusi. Marketing memutuskan untuk menjual produk baru di salah satu website mereka. Menghampiri programmer dan mengatakan “tolong untuk produk ini diberi harga sekian”. Hanya produk ini. lalu programmer mencoba. Membaca bagian internal program yang sudah lama tak disentuh. Menyelaminya kemudian ia sadar hal penting yang akan membuat dahi marketing berkerut. “Pak software kita ini hanya satu harga untuk semua produk jika harga produk ini [sekian] maka semua produk harus [sekian]”. [2]

Dari cerita tersebut, apa yang mungkin dipikirkan orang marketing?

• masa iya harga tidak bisa diatur buat produk itu aja.
• Saya cuma minta gitu aja kok.
• Salah satu kesempatan di masa sulit malah sulit dieksekusi.

Bisa saja mengubah kode program tersebut bukan? Tapi bayangkan situasi dimana estimasi mengatakan itu akan memakan waktu dan momentum sudah lewat.

Perubahan dan Clean Code

Clean code bukan tentang estetis. Bukan keindahan kode. Bukan. Clean code menitikberatkan pada kemampuan sistem untuk berubah. Clean code adalah enabler untuk kemampuan tersebut.

Untuk mencapai code yang clean butuh kemampuan dan pemahaman. Dalam software ada banyak prinsip, konsep dan aktifitas untuk mencapai clean: Refactoring, Single Responsibility Principle, Open/Closed Principle, Cohesien, Loose coupling, YAGNI, dan banyak lagi.

Refactoring adalah salah satu untuk mencapai clean.

Clean Code Sejak Awal

Awalnya anda “merasa” tidak penting bagi bisnis tapi saat clean code dibutuhkan Anda baru sadar. Telat. Sayangnya clean code harus sejak awal. Kenapa clean code harus dari sekarang?

Clean code tidak dicapai dengan satu hari atau dua minggu. Melainkan selama development. Setiap kali programmer selesai membuat fitur bekerja. Dia baru setengah beres. Setengahnya lagi setelah ia merapikan internal program. Refactoring.

Make it works, make it rights

Anda pasti pernah menulis. Setelah membaca ulang kalimat pertama hingga ketiga anda sadar tulisan Anda tidak natural untuk dibaca. Anda ganti kalimat-kalimat tersebut dengan penyampaian yang berbeda namun tetap menjaga arti. Itulah refactoring. Mengubah cara mencapai tujuan tanpa mengubah tujuan. Mengubah internal tanpa mengubah output. Fitur A ya tetap harus fitur A meski sudah refactoring. Hal inilah yang membuat pihak manajemen merasa ini sia-sia. Karena tak tampak secara fisik, tidak seperti kabel diatas. Dan tidak tampak manfaatnya seketika. Ini seperti investasi.

Tanpa refactoring “hutang” akan terus menumpuk. Maksud saya hutang memperbaiki struktur program. Bayangkan susunan kabel di atas. Semakin lama dibiarkan semakin ruwet. Semakin ruwet maka semakin lama untuk memperbaiki. Perusahaan tak mau memperbaiki lama karena deadline menanti. Sampai akhirnya proyek gagal karena:

Six months later, the project failed, in large part because the code was too complex to debug or tune to acceptable performance — Refactoring Book by Martin Fowler.

Refactoring harus sekarang karena saling berkaitan. jika Fitur-B berpondasi pada keruwetan Fitur-A maka Fitur-B terdampak. Merembet. Itulah alasan aktifitas ini harus dilakukan selama development berlangsung. Bukan di akhir.

Selain itu kenapa harus sekarang. Sifat manusia. Jika refactoring diabaikan maka akan seterusnya diabaikan. Seperti To Do List yang penuh membuat kita malas. Tak ada waktu lagi selain saat ini untuk refactoring.

Selalu ada pengecualian. Diskusikan dengan programmer jika refactoring bisa ditahan sementara. Hanya sementara.

Manfaat Refactoring
Manfaat refactoring membantu programmer untuk lebih mudah dan lebih cepat menambah fitur baru. Atau mengubah fitur yang ada. Kita sedikit menambah waktu development agar mengurangi waktu di masa depan.

Kok bisa?

Ingat kasus kabel di atas? Waktu habis hanya untuk menulusuri ujung ke ujung. Ketakutan. Takut salah cabut. Persis, programmer bisa habis waktunya untuk memastikan dia tidak salah ubah karena keruwetan kode yang ada. Salah ubah? Ups. Pelanggan terdampak. “Kenapa tiba-tiba fitur A ada bug ya padahal kemarin lancar.”

Refactoring sederhananya seperti merapikan kabel.

Tapi tahukah refactoring itu bisa merugikan.

Bahaya Refactoring

Kemarin 2 + 2 = 4 lho sekarang 2 + 2 = 5. Sebagai pengguna calculator app saya tentu kaget. Oh ternyata programmer sedang ada perbaikan internal kode dan malah merusak output program.

Ternyata bug bukan hanya terjadi ketika kode tidak clean. Melainkan karena refactoring juga. Lho?

Singkat kata, ada syarat sebelum refactoring. Izinkan saya memperkenalkan teknik programmer yang sangat penting: Unit Testing.

Programmer tidak akan bisa melakukan refactoring tanpa unit test. Mari kita kupas. Refactoring adalah aktifitas mengubah kode menjadi lebih baik. Anda pasti sudah mengerti program itu sangat rawan jika diubah maka outputnya bisa salah, bug. Unit test adalah penjamin bahwa programmer akan melakukan refactoring dengan aman.

Hasil pengecekan unit test

Lihat. Unit test memberitahu saya bahwa program salah menampilkan tanggal. Alih-alih pukul 12 malah pukul 07.

Pengembangan Lambat Karena Mereka

Tidak mau melakukan refactoring dan unit test datang karena alasan memperlambat pengembangan. Refactoring dan unit test adalah sebuah aktifitas. Menambah development time.

Berikut adalah hal yang membuat keduanya terasa memakan waktu:

• Bagaimana jika sebenarnya kita lah yang terbiasa cepat-prematur dan pengembangan software sejatinya memang memakan waktu?
• Bagaimana jika sebenarnya kita hanya mempercepat development dengan cost memperlambat masa depan, menghasilkan bug yang bertubi-tubi dan akhirnya kehilangan pelanggan?
• Refactoring dan unit test membutuhkan skill. Jika belum terbiasa pasti tersendat-sendat. Programmer perlu belajar. Butuh waktu untuk mahir.

Jika sudah mengerti pengembangan software memakan waktu, manajemen pasti memperhatikan kekurangan tersebut dan mencari solusi. Yang saya tahu manajemen adalah “pengelola” risiko. Mungkin dengan:

• Memastikan fitur layak dikembangkan. Karena memakan waktu, apakah fitur X potensial? Seperti yang dipaparkan Product Manager Flip.id, Fadel Muhammad, di sebuah webinar bahwa kita jangan salah mengembangkan fitur. Bisa-bisa rugi. Ada biaya seperti maintenance, waktu, internet, server, tools, SDM, dan sebagainya. Tahapan awal yang harus dilakukan adalah discovery. Kemudian misalnya menggunakan konsep MVP. Atau sebelumnya menghadirkan versi manual dengan bantuan tangan manusia. Banyak yang menggunakan versi manual? Oh layak. Setelah dipastikan layak, barulah dilakukan automatisasi dengan software. Oh tak layak. Tak perlu dikembangkan. Karena stok waktu terselamatkan kita bisa mengalihkan waktu tersebut untuk menghadirkan fitur yang berkualitas bukan kuantitas semata.
• Memberikan harga software yang tidak di bawah harga seharusnya. Harga uang. Harga waktu. Menentukan rentang deadline yang “memadai” sehingga tidak dikejar-kejar.
• Mengambil pilihan tanpa refactoring dan unit test hanya untuk program yang sifatnya sementara dan tidak berubah.

Akhir kata

Perusahaan teknologi paham bahwa hidup mereka bergantung pada program. Sehingga program harus cukup fleksibel agar bisa menyerap perubahan. Hal tersebut dicapai dengan ketekunan. Refactoring. Unit Test. Tidak lupa konsep lain penting untuk diterapkan. Memang menambah waktu pengembangan. Tapi kita tak butuh fitur banyak bukan? Yang kita butuhkan adalah profit. Dicapai dengan efektifitas. Tepat sasaran.

Jika ada masukan alangkah senangnya bila disampaikan di kolom komentar.

Catatan kaki:
[1] https://www.flickr.com/photos/dougbeckers/12670969514

[2] Untuk mencapai clean ada kalanya perlu melakukan estimasi perubahan yang bisa terjadi. Kemudian mempersiapkannya di program dengan menyediakan area khusus di kode. Tapi tidak mudah. Jika semua diantisipasi program akan kompleks dan ruwet. Menimbang cost mempersiapkan dari sekarang vs. cost menunda sampai nanti benar-benar terjadi. Mana yang lebih baik di antara dua keputusan tersebut. Ini adalah pekerjaan yang tidak mudah. Itu mungkin pekerjaan software architect/system analyst.