Refactoring: Memahami Teknik Efektif Mengubah Kode, Untuk Terhindar dari Cost yang Mahal
Karakteristik Software
Software sesuai dengan asal kata pembentuknya “soft”, seharusnya memiliki arti “lunak”. Lunak dalam konteks sebuah software merujuk pada sifat yang mudah untuk diubah dalam menyesuaikan dengan perubahan kebutuhan user. Namun pada kenyataannya, code yang membangun sebuah software banyak memiliki kekurangan yang menyebabkan software menjadi kaku dan sulit diubah.
Harapan vs. Kenyataan mengenai Software
Berikut ini adalah beberapa kondisi ideal dari software dengan kenyataan yang sering terjadi:
Harapan | Kenyataan |
---|---|
Arsitektur dari sebuah software harus kuat (robust) | Arsitektur dari sebuah software rapuh |
Arsitektur sebuah software harus sederhana dan mudah dipahami | Arsitektur sebuah software menjadi terlalu rumit |
Arsitektur sebuah software adalah lunak | Arsitektur sebuah software kaku |
Penyebab utama dari kenyataan yang tidak sesuai dengan kenyataan adalah arsitektur software yang kurang baik, yang melanggar prinsip-prinsip pemrograman yang ada.
Pentingnya Kualitas Perancangan
Kualitas perancangan yang buruk merupakan penyumbang error terbesar dibandingkan dengan kesalahan administrasi, dokumentasi, code, ataupun requirement. Hal ini menyebabkan biaya yang dikeluarkan karena kesalahan perancangan sangat tinggi, hingga mencapai $150
miliyar per tahun di USA atau sekitar $500
miliar di seluruh dunia. Sehingga perancangan software yang baik menjadi hal penting yang harus diperhatikan.
Sumber Gambar : https://sqgne.org/presentations/2012-13/Jones-Sep-2012.pdf
Kualitas perancangan dipengaruhi oleh dua hal:
-
Kualitas software
-
Hutang teknis (technical debt), seperti code debt, design debt, test debt dan documentation debt.
Definisi dan Manfaat Refactoring
Definisi Refactoring
Refactoring adalah perubahan yang dibuat pada struktur internal sebuah software menjadi lebih mudah untuk dipahami dan lebih murah untuk dimodifikasi tanpa mengubah behavior yang dapat diamati oleh pengguna akhir secara langsung.
Perubahan yang dilakukan bertujuan untuk meningkatkan kualitas dari code yang ada, namun perubahan internal yang dilakukan tidak merubah cara penggunaan aplikasi. Beberapa efek refactoring mungkin dirasakan, seperti aplikasi yang lebih robust dan lebih cepat. Sesuai dengan karakteristik dari software, proses perbaikan dan pengembangan aplikasi menyebabkan program berubah secara berkelanjutan. Hal ini menyebabkan program menjadi besar dan rumit, sehingga proses maintainpun menjadi semakin sulit. Refactoring membantu menyederhakana program yang menjadi terlalu rumit karena struktur yang berantakan.
Manfaat Refactoring
Secara garis besar, manfaat refactoring dibagi menjadi 4 sebagai berikut:
-
Refactoring meningkatkan rancangan aplikasi
-
Refactoring mempermudah dalam memahami aplikasi
-
Refactoring membantu dalam mencari sumber bugs
-
Refactoring membantu dalam membuat program lebih cepat
Kapan refactoring dilakukan?
Refactoring merupakan proses mengubah struktur internal yang sudah ada, sehingga biasanya proses refactoring secara menyuluruh dilakukan setelah program selesai dibuat yaitu pada proses review code. Namun pada beberapa proses pengembangan aplikasi, proses refactoring dapat dilakukan setiap kali sebuah modul/fungsi selesai dibuat. Proses pengujian aplikasi yang menemukan bugs juga merupakan pemicu dilakukannya refactoring. Dalam proses pencarian sumber bugs, proses perbaikan dapat dilakukan dengan melakukan refactoring.
Jenis-jenis Bad Code Smell
Definisi Bad Code Smell dan Design Smell
Bad Code Smell adalah karakteristik dari source code sebuah program yang dapat mengindikasikan masalah (yang lebih dalam) pada sebuah aplikasi. Sedangkan Design Smell adalah struktur perancangan yang mengindikasikan pelanggaran pada prinsip- prinsip perancangan sehingga memperburuk kualitas perancangan software.
Jenis-jenis Bad Code Smell
-
The bloater menunjukan sesuatu yang berkembang terlalu besar sehingga tidak dapat ditangani secara efisien. Sesuatu tersebut dapat berupa metode yang terlalu panjang, kelas yang terlalu besar, daftar parameter yang terlalu banyak, penggunaan data primitive yang berlebihan, ataupun penggunaan data clumps.
baca disini untuk memahami The Bloater lebih detail https://dikhimartin.com/refactoring-the-bloater
-
Penentu umum dari “smell” pada Object Orientation Abuser adalah penerapan konsep object oriented yang tidak diterapkan secara penuh. Seperti penggunaan operator switch yang banyak dan kompleks ataupun penggunaan operator if yang banyak dan berurut, yang seharusnya dapat digantikan dengan penerapan konsep object oriented. Penggunaan field sementara juga dapat menjadi indikasi bahwa field tersebut sebaiknya dideklarasikan dalam sebuah metode, bukan dalam ruang lingkup kelas.
baca disini untuk memahami The Object Orientation Abuser lebih detail https://dikhimartin.com/refactoring-object-orientation-abuser
-
The Change Preventer
Changer Preventer merupakan smell yang mencegah/mempersulit terjadinya perubahan pada aplikasi atau untuk kebutuhan perubahan dimasa yang akan datang. Pada suatu kondisi, sebuah perubahan membutuhkan modifikasi yang terlalu banyak pada sebuah kelas. Sedangkan pada kondisi lain, sebuah perubahan kecil mempengaruhi terlalu banyak kelas yang harus dimodifikasi. Kedua kondisi tersebut menyebabkan kesulitan yang tinggi dalam melakuan perubahan sistem yang dibutuhkan.
-
The dispensable
Hal umum yang ada pada semua dispensable smell adalah seluruhnya menunjukkan adanya sesuatu yang tidak dibutuhkan dan seharusnya dapat dihapus dari source code. Beberapa kondisi yang dapat dipertimbangkan untuk dihapus adalah:
-
Lazy class, merujuk pada kelas-kelas yang jarang digunakan atau hanya dibuat untuk kebutuhan pengembangan yang akan datang namun tidak terjadi.
-
Data class, merujuk pada kelas-kelas yang hanya berisi field dan metode yang digunakan untuk mengakses data-data tersebut (setter dan getter). Tanpa adanya metode/fungsi lain yang dideklarasikan pada kelas tersebut dapat menjadi indikasi bahwa data digunakan pada kelas lain yang memungkinkan untuk dilakukan penggabungan antara data class dan kelas pemanggilnya.
-
Duplicate code, merujuk pada fragment code yang sama atau serupa yang dapat digantikan dengan logika lain.
-
Dead code, merujuk pada variable, parameter field, metode ataupun class yang tidak lagi digunakan (obsolete).
-
Speculative generality, berupa field, metode ataupun kelas yang dirancang sebagai perkiraan dalam generalisasi namun tidak pernah digunakan.
-
-
The Coupler
The coupler merupakan kondisi dimana terdapat pelanggaran terhadap prinsip coupling. Coupling merupakan ukuran keterikatan sebuah module dengan module lainnya. Prinsip coupling menekankan pada penerapan low coupling, sehingga perubahan pada satu module tidak akan (atau sedikit) mempengaruhi module lainnya. Salah satu kondisi pelanggaran prinsip coupling adalah dimana sebuah metode mengakses data dari object lainnya lebih sering dibandingkan data dari dalam kelas itu sendiri. Penggunaan middle man juga merupakan indikasi pelanggaran dari prinsip low coupling.
Kesimpulan
-
Kesalahan perancangan merupakan kesalahan yang paling banyak terjadi, dimana “error design” ini sangat mempengaruhi kualitas sebuah software
-
Refactoring merupakan cara untuk meningkatkan kualitas sebuah software dengan melakukan perubahan struktur internal sebuah program tanpa mengubah behavior yang terlihat secara langsung oleh pengguna akhir
-
Kesalahan perancangan dibagi menjadi bad code smell (karakteristik source code) dan design smell (struktur perancangan).
-
Dalam jangka panjang, penerapan refactoring yang konsisten akan mengurangi hutang teknis dan meningkatkan kualitas serta fleksibilitas software, menjadikannya lebih mudah untuk dirawat dan dikembangkan di masa depan. Proses ini tidak hanya bermanfaat bagi pengembang tetapi juga meningkatkan pengalaman pengguna akhir dengan software yang lebih stabil dan handal.
-
Dengan memahami dan menerapkan konsep refactoring, pengembang dapat memastikan bahwa software yang mereka kembangkan tetap "lunak" dan siap menghadapi perubahan kebutuhan di masa mendatang.
Referensi
-
Steve Halladay. (2012). Principle-Based Refactoring. 01. Principle Publishing. Indianapolis. ISBN: 978-0615690223.
-
Refactoring Catalog, http://www.refactoring.com/catalog/
-
Bad Code Smells, https://sourcemaking.com/refactoring/smells
-
M. Fowler and K. Beck, "Bad Smells in Code," in Refactoring: Improving the Design of Existing Code, Addison-Wesley, 200
-
W. Stevens, G. Myers and L. Constantine, "Structured Design," IBM Syst J, vol. 13, no. 2, pp. 115-139, 1974.
-
Bad Code Smells Taxonomy,