Sejauh apa khayalan lo pas lihat tempat sendok & garpu berantakan di dua sekat yang harusnya untuk masing-masing? Refactoring! Ternyata banyak juga yang bisa dijadikan analogi dari keadaan itu loh.. Kali ini gw eksploitasi situasinya & kasih opini gw kapan sebaiknya refactoring dan kapan sebaiknya ditangguhkan.

Penasaran banget sama pendapat lo semua. Silakan komentar di bawah ya..!


Daftar Isi


Dengarkan

Langganan podcast | Ikuti survey pendengar

Segmen

Ada yang terlewat? Silakan komentar di bawah ya.. Jangan lupa berlangganan podcast dan newsletter Developer Muslim. Lihat arsip edisinya di sana. Kalau suka sama pilihan artikel-artikelnya, kenapa ga langganan? :)

Transkrip

Catatan: Apa yang tertera dalam transkrip belum tentu sama persis dengan apa yang saya ucapkan di podcast.

Halo-halo,.. apa kabar semuanya? Alhamdulillah gw baik-baik. Baru baca liputan acara Global Diversity CFP Day Jakarta 2019 di blognya Rizky Ariestiyansyah, salah satu mentor di acara itu. Gw saranin lo untuk baca karena di sana ada materi presentasi yang bisa diunduh. Gw udah update link liputannya di catatan episode lalu. Silakan lihat di devmuslim.id/episode88

Buat lo yang baru bergabung dengerin podcast ini gw ucapkan selamat datang. Makasih udah dengerin. Podcast ini bahas seputar developer, apa yang bikin mereka produktif, berkembang dan peduli sama lingkungan. Cuplikan episode yang udah dirilis, sebagiannya bisa dilihat di instagram.com/devmuslimid.

Pekan lalu gw liat tempat sendok garpu yang bersekat. Harusnya ditempatkan secara terpisah, sendok di satu tempat dan garpu di sekat yang lain. Tapi yang gw lihat ini keduanya ditempati sendok dan garpu. Ga tahu kenapa mungkin emang dasar fitrah manusia, wo elah, fitrah! Apa coba? Ya sebagian kita kan ga enak ya lihat hal yang berantakan begitu. Udah disediakan 2 tempat yang berbeda untuk masing-masing jenis alat makan, tapi malah semuanya diletakkan secara sembarangan.

Dan entah kenapa, tiba-tiba gw menganalogikan dengan developer yang baru bergabung ke proyek, lihat kode yang berantakan seperti itu. Terbayang dialognya yang segera menyarankan ke tim-nya untuk kodenya harus dirapihkan atau refactoring dan untuk kasus sendok dan garpu tadi, sebenarnya ga ada halangan / masalah teknis karena semua orang yang lihat itu dan cuma perlu ambil sendok & garpu masih bisa ambil sesuai dengan keperluannya. Dan tergantung dari basis kodenya juga, untuk sistem yang sudah berjalan lama, alasan untuk tidak melakukan apa-apa terhadap kode itu jadi bertambah, yaitu alasan klasik,

“Kalau ga ada masalah, user ga bingung ngambil sendok / garpu, ya kodenya jangan diutak-atik lagi. karena bisa jadi justru sistemnya akan menimbulkan bug baru.”

Dan akhirnya gw jepret lah tempat sendok garpu itu dan post di Twitter buat lucu-lucuan setengah serius. Sebagian besar tanggapan pengen refactor, karena kalau dilihat sekilas kan gampang, ibaratnya kalau di dunia digital, tinggal Ctr + F trus cari sendok, pindahin. Kemudian cari garpu, dan pindahin sesuai tempatnya.

Sebelum masuk bahas perbedaan pendapat sama perlu tidaknya refactoring, ada baiknya kita tahu dulu apa itu refactoring. Maaf gw belum sempat mencara padanan kata yang tepat untuk refactoring ini. Jadi dalam pengembangan perangkat lunak, code refactoring adalah suatu kegiatan dalam memperbaiki dan membangun kembali struktur kode dengan cara-cara tertentu tanpa mengubah kegunaan perangkat lunak tersebut secara eksternal. Di antara caranya adalah:

Menurut Martin Fowler dan Kent Beck adalah perubahan yang dilakukan pada struktur internal dari sebuah software agar lebih mudah dipahami dan lebih murah untuk dimodifikasi tanpa mengubah perilaku code tersebut. Ini adalah cara disiplin untuk membersihkan code, serta meminimalkan kemungkinan terjadinya bug pada program.

Nah, kembali ke tempat sendok garpu yang keduanya berantakan dan sama-sama dipakai untuk meletakkan sendok dan garpu di kedua tempatnya, maka hal ini jelas banget kalau kodenya perlu untuk refactoring karena sendok dan garpu seharusnya diletakkan secara terpisah. Walaupun ada yang berpendapat itu ga masalah karena user masih bisa mengambil sendok & garpu sesauai dengan keperluannya, namun kita harus tetap mengupayakan kode kita sebersih mungkin, segala hal yang bisa membuat kebingungan harus kita minimalkan. Kenapa begitu? Karena pemakaian fungsi itu bermacam-macam kondisinya, atau keadaan si pemakai fungsi itu. Sesuatu yang masuk akal buat developer A belum tentu jadi hal yang lumrah / biasa buat developer yang lain.

Untuk kasus penempatan sendok garpu. Bisa aja orang yang mau makan ini buta. Kalau diletakkan secara terpisah, kita bisa memberitahu orang ini kalau sendok di kiri dan garpu di kanan. Atau lebih baik dari itu, kita bisa memposisikan sesuai dengan intuisi dan kebiasaan orang memakai sendok garpu itu. Kalau sendok nya di kanan dan garpunya di kiri, tentu akan sesuai dengan intuisi kebanyakan orang karena biasanya mereka menggunakan sendok dengan tangan kanan dan garpu dengan tangan kiri.

Contoh lainnya adalah dengan adanya konvensi / kesepakatan yang dibuat bersama tim, itu bisa menghemat waktu untuk berdiskusi saat kasus lain muncul. Misalnya gimana dengan sendok sup? Itu akan diletakkan di sebelah kanannya sendok karena masih mirip-mirip kegunaannya dengan sendok makan biasa. Contohnya lagi keputusan untuk meletakkan pisau. Sebaiknya di letakkan di sebelah kanan karena itu termasuk alat yang digunakan dengan tangan kanan misalnya. Apapun keputusan yang masuk akal buat tim, ya itulah yang diterapkan.

Nah, kembali lagi ke situasi kalau developer lihat bagian kode yang ga sesuai dengan kesepakatan atau merasa implementasinya bisa lebih baik lagi. Kapan sebaiknya dia refactor kode itu?

  1. Kalau kita lagi mengerjakan fitur yang menyentuh fungsi itu, baik secara langsung atau tidak. Ini juga perlu batasan, tergantung dari penggunaan fungsi itu sama bagian kode yang lain. Sejauh apa kebergantungannya. Karena kalau agak banyak, bisa jadi akan sedikit keluar dari sekup fitur / pekerjaan yang sedang kita lakukan.
  2. Kalau ada waktu khusus. Tergantung dari tim, ada yang membuat jadwal tersendiri untuk mencari bagian mana yang bisa lebih baik lagi implementasinya.

Menurut gw 2 ini sih yang umum. Kalau punya usulan tambahan atau pendapat lain, silakan komentar di catatan episode atau kirim email.

Nah, ada saat di mana refactor itu tidak disarankan. Ini menurut pendapat pribadi gw ya.

  1. Saat memperbaiki bug, terutama bug yang lumayan kompleks. Seringkali pas kita lagi benerin bug, karena penelitian & penganalisaan masalah dalam memecahkan bug, kita jadi tersingkap sama kode-kode yang perlu refactor. Pada saat seperti ini, gw pribadi kurang suka kalau ada komit yang isinya refactor. Karena tujuan kita saat itu adalah membetulkan bug. Fokus kita berbeda dengan saat ngerjain fitur atau memang khusus untuk refactor. Berdasarkan pengalaman, ada hal-hal yang terluput kalau kita refactor saat membetulkan bug. Saran gw, seberapa sepelepun refactoring yang bisa kita lakukan dan seberapa yakin pun refactoring yang kita lakukan ini ga akan mempengaruhi yang lain, tetap sebaiknya jangan refactoring saat benerin bug. Tunda aja di kesempatan lainnya, atau buat catatan mengenai apa yang akan kita refactor begitu selesai membetulkan bug.
  2. Saat mengerjakan fitur yang tidak berhubungan langsung dengan kode yang akan direfactor. Lagi-lagi seberapapun gatelnya kita untuk refactor, kalau bisa hindari. Karena nanti saat kita kembali melihat komit-komit kita dan ternyata itu ga berhubungan dengan tugas kita, kita akan kebingungan mencari sebab kenapa kode itu direfactor padahal tugas kita adalah X. Ingat ya, mata dan pemahaman kita hari ini berbeda dengan kita beberapa bulan ke depan. Apalagi orang lain yang melihat kembali komit-komitnya.

Baik itulah sekilas opini gw mengenai refactoring. Jadi refactoring itu proses yang bagus, bahkan penting. Jangan ditinggalkan karena alasan apapun, karena refactoring dengan strategi yang bagus, bisa bikin kode kita jadi lebih mudah untuk dimengerti, yang nantinya juga akan lebih mudah kalau debug, dan yang penting juga itu akan membuat aplikasi kita lebih efisien.

Namun perlu dipertimbangkan juga kapan sebaiknya refactoring dan kapan suatu kode yang ga optimal itu kita biarkan. Yang mendasari opini gw itu adalah lebih fokus ke tugas kita pada saat itu. Gitu aja sih.

Baik, itu aja yang bisa gw sampaikan kali ini. Sekali lagi kalau lo punya pendapat lain atau mau menambahkan sesuatu mengenai refactoring ini, silakan email gw ke [email protected] atau tinggalkan komentar di catatan episode, devmuslim.id/episode89.

Pertanyaan, kritikan, saran atau cuma mau kenalan, atau mau ngenalin seseorang? Boleh banget! Silakan kirim email atau DM gw langsung di Twitter atau di Instagram dengan akun yang sama, @devmuslimid. Kalau belum ada bahan yang mau disampaikan, lo bisa lihat rundown topik-topik yang insya Allah akan dibahas di podcast ini di Github. Siapa tahu muncul pertanyaan susulan atau kepikiran untuk topik lain, ya kan? Silakan kunjungi https://bit.ly/devmuslimrundown b i t titik l y garis miring d e v m u s l i m r u n d o w n.

Podcast ini bagian dari Product & Development Podcast Community Indonesia. Informasi lebih lanjut bisa ke github.com/pdpcid.

Podcast ini tersedia di Apple Podcast, Google Podcast, dan lain-lain. Lo bisa lihat pilihan2nya di http://anchor.fm/devmuslimid. Jangan lupa kasih komentar & rating yang bagus di aplikasi manapun lo dengerin podcast ini. Buktikan kepedulian & dukungan lo untuk podcast ini.

Baik, gw pamit dulu. Sampai di episode developer muslim podcast berikutnya insya Allah.

Berbagi itu Tanda Peduli

Jangan merasakan manfaat episode ini sendirian aja. Ayo sampaikan informasi ini ke teman-teman developer lainnya. Kasih rating & komentar yang bagus di layanan-layanan podcast ini. Saya juga senang sekali dapat tanggapan & komentar di bawah.


Kembali ke: