Seni Refactoring Codebase Legacy Tanpa Mengundang Bencana

Beberapa hari lalu, Tech Lead-ku mengirimkan sebuah pesan di chat tim yang terus mengendap di kepalaku sampai sekarang:

"…we can start look over the tests and consistency of code and architecture, are there pieces which should be moved around following the Clean Architecture already going on? Where are the technical debts? First thing should be for us to clean up the project to more easily grasp what is going on, but to do this we also need to be wary not to break anything, hence write tests first and make good arguments in PRs to why the changes are made, and make them PRs small and easy to digest for the developers already in the project."

Kodenya sendiri sebenarnya tidak rumit. Yang membuatku terus memikirkannya justru satu hal: urutan berpikir yang beliau tekankan sebelum kita menyentuh keyboard.

Konteks obrolan kami saat itu adalah tentang sebuah library Kotlin Multiplatform yang sudah berumur, menopang lintas platform (Android, iOS, hingga backend), dan dikerjakan bersama oleh banyak orang. Tim sedang mencoba migrasi perlahan menuju Clean Architecture.

Saat dihadapkan pada kode lama yang berantakan, refleks pertama mayoritas developer adalah langsung "bersihkan sekarang juga". Padahal pesan dari Lead-ku tadi mengingatkan: tanpa urutan yang benar, refactoring justru bisa berubah jadi bencana.

---

1. Pahami Dulu, Baru Ubah

Sebelum meributkan clean code, test coverage, atau arsitektur idaman, tanyakan dulu pada diri sendiri: apa tujuan kode ini dibuat dan siapa yang menggunakannya?

Ini terdengar elemental, tapi paling sering diabaikan saat ego teknis kita tersulut melihat kode jelek. Tanpa memahami konteks bisnis dan kompromi masa lalu di balik kode tersebut, refactor yang kita lakukan berisiko tinggi merusak keputusan desain yang sebenarnya sengaja dibuat.

Memahami alur komunikasi sistem adalah fondasi. Baru setelah itu kita bisa secara rasional menilai:

• Mana test yang absensinya membahayakan.
• Di mana letak inkonsistensi penulisan.
• Komponen mana yang memang layak dipindah rumah.

---

2. Memetakan Technical Debt Secara Presisi

Seperti yang disinggung di chat tadi ("Where are the technical debts?"), mengatakan "Project ini penuh utang teknis" itu gampang dan murah. Yang sulit adalah menunjuk hidungnya secara presisi.

Technical debt yang berguna adalah utang yang punya alamat jelas. Bagian mana yang melanggar batas arsitektur? File mana yang menyembunyikan side effect? Jika kita belum bisa memetakan lokasinya secara rinci, artinya kita belum benar-benar paham masalahnya.

---

3. Goal Pertama: Buat Kode Mudah Dipahami

Lupakan ambisi "100% Clean Architecture dalam satu sprint". Target seperti itu hampir selalu berakhir kegagalan atau burnout.

Tetapkan goal yang realistis seperti pesan Lead-ku: buat codebase tersebut lebih mudah dibaca daripada saat kita pertama kali membukanya.

Kode yang mudah dipahami adalah kemenangan taktis. Ketika alurnya transparan, biaya untuk melakukan perbaikan di masa depan secara otomatis menjadi jauh lebih murah.

---

4. Jaring Pengaman: Test Dulu, Refactor Kemudian

Karena goal utama kita adalah memperjelas alur tanpa mengubah perilaku sistem, risiko merusak feature yang sudah jalan di production sangatlah tinggi.

Disiplin urutannya tidak boleh dibalik:

1. Tulis test dulu untuk mengunci perilaku (behavior) kode saat ini.
2. Lakukan refactor dengan memanfaatkan test tersebut sebagai jaring pengaman (safety net).
3. Sertakan alasan yang kuat dalam deskripsi Pull Request (PR).
4. Pecah PR menjadi porsi-porsi kecil.

Di lapangan, orang kerap terburu-buru merapikan kode dan baru panik membuat test ketika aplikasi crash di tangan user. Test-driven refactoring bukan formalitas, tapi asuransi.

---

5. PR Kecil Adalah Bentuk Empati

Poin terakhir dari chat tersebut yang paling membekas buatku: Pull Request yang baik adalah PR yang menghargai waktu rekan tim.

Refactor bukan cuma tentang membuat kode tampak indah di mata kita, tetapi tentang kemudahan orang lain untuk meninjau, memahami, dan memeliharanya di kemudian hari.

PR raksasa yang mengubah puluhan file sekaligus hanya akan menghasilkan dua hal:

• Ditolak karena membuat bingung.
• Di-approve asal-asalan karena reviewer sudah lelah melakukan scrolling.

PR yang kecil, terfokus, dan disertai penjelas alasan yang jernih adalah bentuk rasa hormat tertinggi pada rekan satu tim.

---

Pelajaran Penting

Pesan dari Lead-ku memberikan urutan berpikir universal yang berlaku untuk project apa pun yang memiliki jejak sejarah panjang:

Pahami konteks → Petakan utang → Tulis test → Refactor pelan-pelan → Ajukan PR kecil.

Pada akhirnya, perbaikan kode yang paling berharga bukanlah perubahan besar yang dramatis, melainkan perubahan kecil yang dapat dipercaya dan dilanjutkan dengan tenang oleh tim setelah kita beralih ke task berikutnya.