“Berfungsi — jangan sentuh” — apa itu, inti prinsip dan risiko

Apa itu prinsip “berfungsi — jangan sentuh”?

Prinsip “Berfungsi — jangan sentuh” (Inggris: “If it ain't broke, don't fix it”) — adalah aturan empiris yang memperingatkan pengembang untuk tidak melakukan perubahan pada kode yang berfungsi tanpa alasan yang cukup. Di dasar prinsip ini terletak statistik sederhana: sebagian besar cacat justru dimasukkan dalam proses memodifikasi kode yang ada.

Prinsip ini bukan dogma — ini lebih merupakan heuristik yang membantu pengambilan keputusan dalam kondisi ketidakpastian. Semakin kompleks dan berantakan basis kode, semakin tinggi kemungkinan bahwa perubahan “tidak bersalah” akan merusak sesuatu yang tidak diduga akan rusak.

Menurut penelitian perusahaan Microsoft (2024), sekitar 60% dari semua insiden kritis di produksi terkait dengan perubahan kode baru-baru ini yang dilakukan dengan niat baik tetapi tidak cukup diuji dalam kondisi beban nyata.

Sejarah dan asal-usul prinsip

Idiom “If it ain't broke, don't fix it” berasal dari budaya teknik Amerika pertengahan abad ke-20. Penggunaan terdokumentasi paling awal dikaitkan dengan Bert Lance (1977), yang bekerja di Komite Keuangan Senat AS dan menentang regulasi yang berlebihan.

Ke dalam pemrograman, prinsip ini datang dari teknik perangkat keras, di mana mengganti chip yang berfungsi dengan yang baru dapat menyebabkan konsekuensi yang tidak terduga. Dalam konteks perangkat lunak, prinsip ini mendapatkan penyebaran khusus seiring dengan meningkatnya kompleksitas sistem perangkat lunak dan munculnya kode warisan.

Menariknya, dalam pemrograman prinsip ini memiliki sisi lain — “berfungsi, tapi lebih baik jangan disentuh” sering menjadi alasan untuk menolak refaktorisasi, yang dalam jangka panjang menyebabkan akumulasi kritis utang teknis. Menurut perusahaan konsultan Thoughtworks (2023), sekitar 40% proyek menghadapi masalah serius karena konservatisme berlebihan terhadap perubahan.

Kapan menerapkan prinsip

Prinsip “Berfungsi — jangan sentuh” sangat relevan dalam situasi tertentu ketika harga kesalahan melebihi potensi manfaat dari perubahan.

Proyek warisan tanpa pengujian

Dalam kode warisan yang tidak dicakup oleh pengujian, setiap perubahan adalah permainan rolet Rusia. Jika pengembang tidak dapat memeriksa bahwa perubahan tidak merusak modul tetangga, strategi terbaik adalah tidak menyentuh kode yang berfungsi. Pengecualian — hanya bug kritis atau persyaratan keamanan.

Sistem kritis

Dalam sistem di mana waktu henti tidak dapat diterima atau harga kesalahan sangat besar — perangkat lunak medis, avionik, transaksi keuangan — prinsip “berfungsi — jangan sentuh” adalah standar de facto. Setiap perubahan melalui beberapa tahap persetujuan dan pengujian.

Tenggat waktu ketat

Jika rilis besok dan kode berfungsi — jangan coba perbaiki arsitekturnya. Ubah hanya apa yang secara langsung memengaruhi fungsionalitas rilis. Tunda refaktorisasi ke sprint berikutnya (tapi jangan lupakan).

Risiko mengikuti prinsip

Mengikuti prinsip “berfungsi — jangan sentuh” secara membabi buta membawa risiko tidak kurang dari refaktorisasi tanpa akhir. Mari kita lihat bahaya utamanya.

Akumulasi utang teknis

Jika setiap pengembang berpedoman pada prinsip ini, basis kode dengan cepat berubah menjadi “kue lapis” dari solusi usang, kruk, dan algoritma tidak optimal. Cepat atau lambat utang teknis menjadi tak tertahankan — setiap perubahan membutuhkan berminggu-minggu analisis.

Optimasi yang terlewatkan

Terkadang perubahan yang tampak berisiko justru secara signifikan meningkatkan kinerja atau keamanan. Prinsip “berfungsi — jangan sentuh” tidak boleh memblokir perubahan yang membawa manfaat terukur — mengurangi biaya server, mempercepat pemuatan halaman, meningkatkan keamanan.

Hilangnya kompetensi

Ketika tim bertahun-tahun tidak menyentuh bagian kode tertentu, mereka kehilangan pemahaman tentang cara kerjanya. Pengembang kunci pergi — dan kode berubah menjadi warisan tanpa kemungkinan pemeliharaan. Prinsip harus diterapkan dengan mempertimbangkan pemeliharaan jangka panjang proyek.

Jalan tengah: refaktorisasi tanpa fanatisme

Strategi optimal — jangan ikuti prinsip secara membabi buta, tetapi terapkan secara sadar, dengan mempertimbangkan konteks. Refaktorisasi diperlukan, tetapi harus aman.

Aturan pramuka

Aturan pramuka dalam pemrograman: “Tinggalkan kode lebih bersih dari yang kamu temui”. Jika pengembang melakukan perubahan pada modul, ia harus meningkatkan strukturnya, tetapi dalam batas wajar. Tidak menulis ulang semuanya dari awal, tetapi setidaknya mengganti nama variabel yang tidak terbaca dan menambahkan komentar.

Refaktorisasi di bawah perlindungan pengujian

Pengujian — satu-satunya cara untuk menerapkan prinsip “berfungsi — jangan sentuh” dengan aman. Jika kode dicakup oleh pengujian, setiap refaktorisasi menjadi dapat diprediksi: pengembang mengubah kode, menjalankan pengujian dan melihat apakah ada yang rusak. Tanpa pengujian — jangan sentuh. Dengan pengujian — refaktor dengan percaya diri.

// Contoh: refaktorisasi aman di bawah cakupan pengujian
class PriceCalculator {
    fun calculatePrice(basePrice: Double, discount: Double): Double {
        // Kode lama tapi berfungsi
        return basePrice - (basePrice * discount / 100.0)
    }
}

// Pengujian yang melindungi dari regresi
class PriceCalculatorTest {
    fun testCalculatePrice() {
        val calc = PriceCalculator()
        assertEquals(90.0, calc.calculatePrice(100.0, 10.0))
    }
}

Contoh ini menunjukkan pendekatan yang benar: pertama pengujian, lalu refaktorisasi. Jika pengujian lulus — perubahan aman. Prinsip “berfungsi — jangan sentuh” berubah menjadi “berfungsi di bawah pengujian — refaktor dengan berani”.

Contoh nyata dari praktik

Mari kita lihat skenario nyata di mana prinsip “berfungsi — jangan sentuh” terbukti menyelamatkan dan juga destruktif.

Kasus penyelamatan: masalah mirip Y2K

Seorang pengembang menemukan bahwa dalam kode pemrosesan tanggal digunakan format DD/MM/YY sebagai ganti YYYY. Kode berfungsi dengan benar dari tahun 2000 hingga 2025. Meskipun ada keinginan untuk “memperbaiki” — ia meninggalkan kode apa adanya, hanya memberikan komentar. Pada tahun 2026 perusahaan memperbarui sistem, dan solusi baru sudah memproses abad dengan benar. Perubahan dini hanya akan merusak logika yang berfungsi.

Kasus destruktif: kehilangan data karena “perbaikan”

Seorang insinyur memutuskan untuk “memperbaiki” kode impor data lama tetapi berfungsi dengan menggantinya dengan pustaka modern. Ia tidak mempertimbangkan bahwa pustaka lama menangani kasus batas spesifik yang tidak didokumentasikan. Setelah rilis — kehilangan data massal. Prinsip “berfungsi — jangan sentuh” dilanggar, dan harga kesalahan adalah dua minggu kerja tim untuk pemulihan.