Refactoring yang Baik vs. Refactoring yang Buruk

• Refactoring kode memainkan peran penting dalam menjaga kesehatan codebase
• Namun, refactoring yang keliru justru dapat membuat kode lebih kompleks dan lebih sulit dipelihara
• Kita perlu bisa membedakan refactoring yang baik dan yang buruk, serta memahami cara menghindari jebakan refactoring yang buruk

Sisi baik, sisi buruk, dan sisi jelek dari refactoring

• Abstraksi bisa menjadi hal yang baik atau buruk. Kuncinya adalah mengetahui kapan dan bagaimana menerapkannya
• Menjelaskan beberapa jebakan umum dan cara menghindarinya (kode asli dihilangkan)

1. Mengubah gaya penulisan kode secara drastis

• Developer sering melakukan kesalahan dengan sepenuhnya mengganti gaya penulisan kode saat melakukan refactoring
• Memperkenalkan library baru atau mengadopsi gaya penulisan kode yang benar-benar berbeda dapat berdampak buruk pada pemeliharaan
• Sebaiknya perbaiki kode agar lebih idiomatis dan mudah dibaca, tanpa memperkenalkan paradigma baru yang sepenuhnya berbeda atau dependensi eksternal

2. Abstraksi yang tidak perlu

• Menambahkan abstraksi baru secara berlebihan tanpa memahami kode yang ada merupakan masalah
• Hal itu hanya menambah kompleksitas dan bisa membuat kode lebih sulit dipahami
• Sebaiknya pisahkan logika menjadi fungsi-fungsi kecil yang dapat digunakan ulang, tetapi jangan memperkenalkan kompleksitas yang tidak perlu

3. Menambahkan ketidakkonsistenan

• Memperbarui hanya satu bagian dari codebase agar bekerja dengan cara yang sepenuhnya berbeda dapat menimbulkan kebingungan dan frustrasi
• Jika harus memperkenalkan pola baru, sebaiknya dapatkan persetujuan tim terlebih dahulu
• Penting untuk mempertahankan pendekatan yang konsisten terhadap pengambilan data di seluruh aplikasi

4. Tidak memahami kode sebelum melakukan refactoring

• Mempelajari kode sambil sekaligus melakukan refactoring bukanlah ide yang baik
• Itu dapat menimbulkan bug, menurunkan performa, dan menghapus fungsi
• Penting untuk memahami kode secara mendalam sebelum melakukan refactoring, lalu memperbaikinya sambil mempertahankan perilaku yang sudah ada

5. Memahami konteks bisnis

• Membuat pilihan teknis tanpa memahami bisnis bisa menjadi bencana
• Untuk situs e-commerce yang sangat bergantung pada SEO, client-side rendering bisa menjadi pilihan yang buruk
• Pendekatan server-side rendering seperti Next.js atau Remix bisa menjadi pilihan yang lebih baik dari sisi SEO dan performa

6. Penyatuan kode yang berlebihan

• Menyatukan kode demi membuatnya terlihat "rapi" dengan mengorbankan fleksibilitas bukanlah hal yang baik
• Saat membuat abstraksi, kita harus selalu mempertimbangkan use case yang dilayaninya
• Pastikan abstraksi memungkinkan semua fungsi yang disediakan oleh implementasi aslinya

Melakukan refactoring dengan cara yang benar

• Refactoring kode memang diperlukan. Tetapi harus dilakukan dengan cara yang benar
• Kode kita tidak sempurna dan perlu dirapikan, tetapi tetap harus konsisten dengan codebase yang ada
• Refactoring harus dilakukan setelah memahami kode dengan baik, dan abstraksi harus dipilih dengan hati-hati
• Tips untuk refactoring yang sukses:
  • Lakukan secara bertahap: buat perubahan kecil yang terkelola daripada menulis ulang secara besar-besaran
  • Pahami kode secara mendalam sebelum memperkenalkan refactoring besar atau abstraksi baru
  • Sesuaikan dengan gaya kode yang ada: konsistensi adalah kunci untuk pemeliharaan
  • Hindari memperkenalkan terlalu banyak abstraksi baru: pertahankan kesederhanaan kecuali kompleksitas itu benar-benar diperlukan
  • Hindari menambahkan library baru dengan gaya pemrograman yang sangat berbeda, terutama tanpa persetujuan tim
  • Tulis tes sebelum refactoring dan perbarui tes selama proses berlangsung. Ini membantu memastikan fungsi aslinya tetap terjaga
  • Saling menjaga akuntabilitas agar rekan tim mematuhi prinsip-prinsip ini

Alat dan teknik untuk refactoring yang lebih baik

• Untuk refactoring yang lebih baik, pertimbangkan memanfaatkan teknik dan alat berikut:

Alat linting

• Gunakan alat linting untuk menerapkan gaya kode yang konsisten dan menemukan potensi masalah
• Prettier dapat digunakan untuk formatting otomatis dengan gaya yang konsisten
• Eslint memungkinkan pemeriksaan konsistensi yang lebih rinci melalui plugin kustom

Code review

• Terapkan code review yang menyeluruh untuk mendapatkan umpan balik dari rekan tim sebelum menggabungkan kode hasil refactoring
• Ini membantu menemukan potensi masalah sejak dini dan memastikan kode hasil refactoring sesuai dengan standar serta ekspektasi tim

Testing

• Tulis dan jalankan tes agar kode hasil refactoring tidak merusak fungsi yang sudah ada
• Vitest adalah test runner yang sangat cepat, andal, dan mudah digunakan, serta pada dasarnya tidak memerlukan konfigurasi
• Pertimbangkan menggunakan Storybook untuk visual testing
• React Testing Library adalah kumpulan utilitas yang baik untuk menguji komponen React (ada juga variasi untuk Angular dan lainnya)

Alat AI yang (tepat)

• Dukung upaya refactoring dengan alat AI yang dapat menyesuaikan diri dengan gaya dan aturan penulisan kode yang ada
• Visual Copilot adalah alat yang sangat berguna khususnya untuk menjaga konsistensi saat melakukan coding frontend
  • Membantu mengubah desain menjadi kode sambil tetap sesuai dengan gaya penulisan kode yang ada dan memanfaatkan komponen serta token design system dengan benar

Kesimpulan

• Refactoring adalah bagian yang diperlukan dalam pengembangan perangkat lunak, tetapi harus dilakukan dengan hati-hati sambil mempertimbangkan codebase yang ada dan dinamika tim
• Tujuan refactoring adalah memperbaiki struktur internal kode tanpa mengubah perilaku eksternalnya
• Refactoring terbaik sering kali tidak terlihat oleh pengguna akhir, tetapi sangat memudahkan kehidupan developer
• Refactoring meningkatkan keterbacaan, kemudahan pemeliharaan, dan efisiensi, tanpa membuat keseluruhan sistem menjadi membingungkan
• Saat ingin membuat "rencana besar" untuk kode, ambil jeda sejenak untuk benar-benar memahami kode, mempertimbangkan dampak perubahan, dan melakukan perbaikan bertahap yang akan dihargai tim
• Diri Anda di masa depan dan rekan tim akan berterima kasih atas pendekatan yang matang untuk menjaga codebase tetap bersih dan mudah dipelihara

[toaonly]

Ada juga yang sering langsung nekat melakukan refactoring tanpa kode pengujian.
Kalau dilihat-lihat, rasanya seperti sedang berjalan di atas tali yang amat berbahaya, jadi bikin deg-degan haha

[ahwjdekf]

Poin nomor 4, “tidak memahami kode sebelum melakukan refaktorisasi”, benar-benar sangat terasa bagi saya.

[bichi]

Ini terdengar sangat jelas dan seperti hal yang mendasar juga, haha. Enak dilihat karena sudah dirapikan. Saya rasa kalau melakukan refactoring, 100% akan menghasilkan kode yang lebih baik. Kalau tidak, bukankah itu berarti kemampuan saya justru mundur dibanding kemarin?

Melihat hal-hal yang jelas seperti ini dirangkum, rasanya seperti tulisan yang dibuat karena ada seseorang yang benar-benar mengacak-acak semuanya sampai penulisnya sangat kesal, hahaha

[kandk]

Ini lebih ke cara benar-benar menulis kode dengan baik di pekerjaan nyata, ketimbang cara melakukan refactoring dengan baik..
(Kelihatannya ini seperti tulisan yang dibuat karena kesal setelah ada junior datang, bilang mau me-refactor proyek legacy, lalu malah bikin banyak hal jadi rumit di sana-sini dan menimbulkan bug...)

[savvykang]

Orang yang tidak bisa membedakan atau malah mencampuradukkan unit pekerjaan dengan unit kode, terlepas dari banyak atau sedikitnya pengalaman mereka, biasanya melakukan refaktorisasi seperti itu. Kode yang mudah diperbaiki dan bisa dipelihara pada akhirnya harus memungkinkan orang lain yang datang belakangan tetap bisa membaca alur pekerjaan agar bisa dianggap memadai, dan saya juga kadang bertanya-tanya apakah hal seperti itu memang tidak akan dipahami kalau belum mengalaminya langsung di dunia kerja.

[savvykang]

Saya pernah mengalami satu kasus yang menjadi sinyal abstraksi berlebihan di React. Meskipun komponen tabel sudah diabstraksikan oleh UI framework, hanya karena skema dua tabel tampak mirip lalu memakai inversion of control untuk membuat komponen baru yang tidak punya peran apa pun menurut saya sebaiknya dihindari. Saya pernah melihat kasus orang terlalu memaksakan penerapan atomic design sampai membanjiri kode dengan komponen kosong sekitar sepuluh baris, dan itu sangat tidak nyaman karena harus melihat banyak bagian.

Aturan DRY pada dasarnya dimaksudkan agar kita tidak copy-paste kode yang bentuk dan perannya benar-benar sama, tetapi sepertinya selalu ada orang yang salah memahaminya. Mungkin ungkapan agar tidak membuta memercayai design pattern muncul dalam konteks seperti ini?