7 Kebiasaan Ngoding Ruby on Rails yang Bikin Kode Rapi

Kode Ruby on Rails yang rapi biasanya lahir dari kebiasaan harian yang dijalankan konsisten, bukan dari trik framework. Kalau kamu baru mulai kerja di proyek Rails yang sudah berjalan lama, tujuh kebiasaan berikut ini yang paling terasa bedanya. Semuanya bisa kamu terapkan tanpa menunggu refactor besar.

1. Beri nama model dan kolom sesuai isi domain

Nama yang asal-asalan jadi utang paling mahal di Rails. Kolom status dan status2 di tabel yang sama akan bikin kamu dan rekan timmu bertanya-tanya enam bulan kemudian. Sebelum menulis migration, tanyakan: kalau orang bisnis baca nama kolom ini, apakah dia langsung paham?

• payment_status lebih jelas daripada status.
• activated_at lebih jelas daripada aktif.
• Hindari singkatan yang cuma dipahami satu orang, seperti usr_ctg.

Rails memetakan nama model ke nama tabel secara otomatis. Kalau kamu memberi nama yang jujur, association, route, dan serialisasi JSON ikut enak dibaca tanpa banyak alias.

2. Simpan logika di model, bukan di controller

Controller yang panjang jadi sumber bug paling sering di proyek Rails. Kalau action-mu sudah lebih dari sepuluh baris, biasanya ada logika bisnis yang bisa dipindah. Pola yang paling gampang: buat method di model untuk aksi yang menjelaskan konsep domain.

class Invoice < ApplicationRecord
  def mark_paid!(paid_at: Time.current)
    update!(status: :paid, paid_at: paid_at)
  end
end

Controller tinggal memanggil invoice.mark_paid!. Method ini gampang dites di unit test, dan aturan bisnis tidak tersebar di beberapa action. Kalau logika makin rumit, pindahkan ke service object dengan nama yang jelas, misalnya InvoicePaymentService. Jangan buat service hanya karena ingin terlihat rapi.

3. Tulis migration yang aman dijalankan ulang

Migration yang gagal di tengah jalan dan meninggalkan tabel setengah jadi adalah mimpi buruk di server produksi. Dua kebiasaan kecil mengurangi risiko ini drastis.

1. Selalu isi method down atau pakai change yang memang reversible.
2. Pisahkan perubahan skema dan perubahan data. Jangan campur add_column dengan pengisian data default di satu file.

Kalau perlu mengisi data besar, buat migration terpisah dan jalankan lewat rake task supaya bisa diulang tanpa mengganggu skema. Ini juga memudahkan review: rekan timmu bisa melihat perubahan struktur tanpa terganggu potongan kode pengisian data.

4. Pakai scope untuk query yang sering dipakai

Query yang sama berulang di beberapa tempat cepat atau lambat akan berbeda perilakunya. Bungkus dengan scope bernama jelas di model.

class Order < ApplicationRecord
  scope :pending, -> { where(status: :pending) }
  scope :recent,  -> { order(created_at: :desc) }
end

Setelah itu, Order.pending.recent lebih mudah dibaca dan diuji daripada rangkaian where panjang di controller. Scope juga bisa dirangkai, jadi kamu tidak perlu menulis varian baru untuk setiap kombinasi filter.

Kalau kamu sedang membersihkan query yang berantakan dan menemukan bagian yang memakai helper view, cara memilih elemen dengan selector jQuery bisa jadi referensi saat memeriksa apakah elemen UI benar-benar terikat ke data yang tepat.

5. Perlakukan view sebagai lapisan tampilan, bukan tempat logika

View Rails punya akses ke semua hal, dan itu justru bikin gampang menyimpang. Kalau di dalam .erb ada percabangan lebih dari dua tingkat atau perhitungan, pindahkan ke helper, presenter, atau model.

• Format angka dan tanggal: taruh di helper.
• Label status: taruh di model atau enum helper.
• Query di view: hampir selalu tanda ada data yang belum disiapkan controller.

File view yang pendek lebih cepat dibaca saat debugging. Ketika ada bug tampilan, kamu bisa langsung fokus ke satu sumber, bukan menelusuri partial yang saling memanggil.

6. Tulis test untuk alur yang paling sering rusak

Tidak semua kode butuh test. Yang butuh test adalah alur yang paling sering berubah dan paling mahal kalau rusak. Di aplikasi Rails, biasanya itu bagian pendaftaran, pembayaran, dan otorisasi.

Mulai dari request spec atau system spec yang meniru satu alur pengguna dari klik sampai data tersimpan. Satu test yang menutup alur penuh lebih berguna daripada sepuluh unit test yang menguji getter. Kalau test mulai sulit ditulis, itu sinyal ada ketergantungan yang terlalu erat antar objek.

Saat memperbaiki test yang gagal, pesan error dari Rails sering menyesatkan. Panduan tips debug Ruby on Rails untuk pemula membahas cara membaca stack trace tanpa menghabiskan berjam-jam.

7. Review konfigurasi sebelum deploy, bukan sesudah

Banyak masalah produksi berasal dari konfigurasi yang tidak sengaja tertinggal di environment development. Sebelum deploy, biasakan memeriksa tiga hal: kredensial mana yang dipakai, apakah config.cache_classes sudah sesuai environment, dan bagaimana log disimpan.

Kalau kamu mengelola server sendiri, langkah-langkah di panduan deploy Ruby on Rails ke VPS untuk pemula bisa jadi checklist awal. Untuk aplikasi yang lebih besar, review konfigurasi ini sebaiknya masuk ke pull request, bukan dilakukan manual di server.

Kebiasaan mana yang paling berdampak?

Kalau harus pilih satu, mulai dari penamaan dan pemisahan logika model-controller. Dua hal ini memengaruhi hampir semua kebiasaan lain di daftar. Sisanya menyusul secara alami begitu struktur dasar sudah rapi.

Kalau kamu bekerja dengan tim yang terdiri dari beberapa developer, sepakati kebiasaan ini di dokumen singkat dan bahas di code review. Kode Rails yang rapi bergantung pada aturan bersama yang dijalankan konsisten, bukan pada selera individu.

Pertanyaan yang Sering Diajukan

Apakah semua logika bisnis harus pindah dari controller ke model?

Tidak harus semua. Controller tetap bertanggung jawab atas autentikasi, otorisasi, dan menyiapkan respons. Yang dipindah adalah aturan bisnis seperti validasi status, perhitungan harga, dan efek samping yang seharusnya selalu terjadi ketika suatu aksi dijalankan.

Seberapa banyak scope yang wajar dibuat dalam satu model?

Tidak ada angka pasti. Batas praktisnya: kalau daftar scope di satu model sudah lebih dari sepuluh dan mulai tumpang tindih, itu tanda model tersebut menangani terlalu banyak hal. Pecah tanggung jawabnya, bukan menambah scope baru.

Apakah menulis test sejak awal memperlambat pengembangan?

Di awal memang terasa lebih lambat. Tapi test untuk alur kritis biasanya membayar dirinya sendiri ketika ada perubahan skema atau upgrade gem. Fokuskan dulu pada alur yang paling sering berubah agar usahanya tidak terbuang.