Berfungsi di mesin saya: apa itu, mengapa terjadi dan cara mencegah

Apa arti “Berfungsi di mesin saya”

“Berfungsi di mesin saya” — frasa yang diucapkan pengembang ketika rekan atau penguji melaporkan bug, tetapi di mesin pengembang bug tersebut tidak dapat direproduksi. Secara lahiriah ini terlihat seperti penyangkalan masalah, tetapi secara teknis situasinya nyata: kode memang bisa berfungsi di satu lingkungan dan gagal di lingkungan lain. Perbedaan satu bit konfigurasi — dan perilaku aplikasi berubah secara drastis.

Frasa ini telah menjadi meme di komunitas IT karena sekaligus benar dan tidak berguna. Dari sudut pandang pengembang — kode memang berfungsi di mesinnya. Dari sudut pandang tim — masalahnya ada dan harus diselesaikan, bukan dibenarkan. Kelucuan situasinya adalah pengembang mengatakan kebenaran, tetapi kebenaran itu tidak membantu memperbaiki bug. Meme ini sangat populer sehingga ribuan postingan di Reddit, XKCD, dan konferensi DevOps didedikasikan untuknya.

Dari sudut pandang proses, frasa “berfungsi di mesin saya” adalah indikator masalah dengan reproduktifitas lingkungan. Jika dua pengembang tidak bisa mendapatkan hasil yang sama pada kode yang sama — berarti proses pengaturan lingkungan tidak terstandarisasi. Praktik DevOps menyatakan: lingkungan harus dapat direproduksi dengan satu perintah dari repositori tanpa tindakan manual.

Mengapa lingkungan lokal berbeda dari produksi

Lingkungan lokal pengembang hampir selalu berbeda dari produksi. Pengembang menggunakan macOS atau Windows, sementara server berjalan di Linux. Sistem operasi yang berbeda memiliki sistem file, pengkodean, pengaturan waktu thread, dan panggilan sistem yang berbeda. Bahkan jika kedua lingkungan adalah Linux — versi kernel, glibc, OpenSSL bisa berbeda.

Penyebab kedua — kumpulan perangkat lunak yang terinstal. Di mesin pengembang mungkin terinstal Node.js versi global 20, sementara di konfigurasi CI/CD disebutkan versi 18. Atau pengembang menggunakan PostgreSQL 16 secara lokal, sementara di produksi — PostgreSQL 14. Perbedaan dalam versi minor sering tidak terlihat, tetapi pembaruan mayor dapat mengubah perilaku kueri SQL. Menurut npm Inc., 67% bug yang terkait dengan dependensi disebabkan oleh perbedaan dalam versi patch.

Penyebab ketiga — kondisi jaringan. Di mesin lokal tidak ada penundaan, batasan bandwidth, dan masalah DNS. Di produksi, permintaan apa pun ke API eksternal bisa memakan waktu 500 ms, bukan 5 ms. Timeout, logika retry, race conditions — semua masalah ini hanya muncul di bawah beban nyata dan dalam kondisi jaringan nyata. Emulasi jaringan melalui alat seperti Toxiproxy membantu mengidentifikasi masalah ini sebelum deploy.

Penyebab tipikal bug tidak dapat direproduksi secara lokal

Penyebab pertama — kurangnya data. Pengembang bekerja dengan fixture pengujian, sementara di produksi ada jutaan catatan dengan nilai yang tidak terduga. NULL di bidang yang dianggap wajib oleh pengembang, karakter Unicode dalam nama, string yang terlalu panjang — semua ini dapat menyebabkan bug yang tidak dapat direproduksi di basis data lokal dengan data sintetis.

Penyebab kedua — flag kompilasi dan build yang berbeda. Build rilis (Release/Distribution) dapat berbeda dari build debug (Debug). Optimasi kompiler, penghapusan log debug, inlining fungsi — semua ini dapat menyembunyikan atau, sebaliknya, memunculkan bug. Contoh tipikal: di build debug, sebuah assert berfungsi yang gagal di build rilis karena urutan inisialisasi variabel yang berbeda.

Penyebab ketiga — cache lokal dan file sementara. Pengembang mungkin tidak melihat bug karena skrip lama di-cache di browser, data usang disimpan di Redis, dan file sementara dari eksekusi sebelumnya menggantung di sistem file. Startup bersih (mode penyamaran, pembersihan cache, instalasi baru) sering mereproduksi bug yang tidak muncul “dengan sendirinya”.

Penyebab keempat — konflik dependensi global dan lokal. Alat seperti Ruby gems, Python pip, Node.js npm dapat memiliki paket yang terinstal secara global yang “membantu” kode berfungsi secara lokal, tetapi tidak ada di produksi. Penggunaan lingkungan virtual (virtualenv, venv, nvm) mengisolasi proyek dari instalasi global dan membuat lingkungan dapat direproduksi.

Dampak pada kerja tim dan kepercayaan

Frasa “berfungsi di mesin saya” menghancurkan kepercayaan dalam tim. Jika seorang pengembang secara teratur tidak dapat mereproduksi bug, rekan kerja mulai meragukan kompetensinya atau ketelitian pengujiannya. Seiring waktu, ini menyebabkan micromanagement: setiap perubahan perlu diverifikasi oleh pengembang kedua, yang memperlambat pengembangan. Menurut Google Project Aristotle, keamanan psikologis dalam tim secara langsung memengaruhi produktivitas, dan perselisihan konstan tentang lingkungan adalah salah satu faktor penurunannya.

Masalah kedua — perlambatan code review. Jika seorang pengembang tidak dapat mereproduksi bug secara lokal, ia dapat menolak pull request rekan dengan kata-kata “di tempat saya berfungsi — berarti masalahnya di kamu”. Ini memicu konflik dan menunda pengiriman fitur. Standarisasi lingkungan menghilangkan konflik ini: jika kedua pengembang bekerja dalam container Docker yang sama, pertanyaan “di siapa yang berfungsi” kehilangan makna.

Masalah ketiga — kehilangan bug di pelacak. Bug yang “tidak dapat direproduksi di pengembang” sering ditutup dengan catatan “tidak dapat direproduksi” (Cannot Reproduce). Sebulan kemudian, bug muncul di produksi, dan perbaikannya memakan biaya 10 kali lebih mahal. Aturan: jika bug dapat direproduksi setidaknya pada satu orang — bug itu ada, terlepas dari apakah bug itu berfungsi di pengembang atau tidak.

Cara menstandarisasi lingkungan pengembang

Cara pertama dan paling efektif — Docker. Seluruh proyek harus berjalan melalui docker-compose up tanpa tindakan tambahan. Basis data, cache, antrean pesan, server web — semuanya dijalankan dalam container. Pengembang hanya menginstal Docker dan Git. Sisanya — di dalam container. Ini menjamin bahwa semua anggota tim memiliki lingkungan yang sama terlepas dari OS.

Cara kedua — manajer versi. Jika Docker tidak memungkinkan (batasan lisensi, infrastruktur lama), gunakan nvm (Node.js), rbenv (Ruby), pyenv (Python), sdkman (Java). Manajer versi memungkinkan peralihan versi bahasa dan alat dalam proyek. File .nvmrc, .ruby-version, .python-version harus ada di repositori dan diperiksa oleh CI/CD.

Cara ketiga — Vagrant untuk mesin virtual. Vagrant menjalankan mesin virtual dengan OS dan konfigurasi yang ditentukan di atas VirtualBox atau VMware. Di dalam VM, semua dependensi diinstal melalui skrip provisioning (shell, Ansible, Puppet). Vagrant lebih berat dari Docker, tetapi memberikan isolasi penuh di tingkat OS — berguna untuk proyek yang bergantung pada versi kernel Linux tertentu.

Cara keempat — makefile dan skrip bootstrap. Bahkan Makefile sederhana dengan target install, test, build, clean dapat menstandarisasi tindakan rutin. Perintah make install harus menginstal semua dependensi, mengonfigurasi basis data, dan membuat data pengujian. Titik masuk tunggal untuk semua pengembang mengecualikan kesalahan manual dalam pengaturan lingkungan.

Alat untuk mencegah perbedaan lingkungan

Alat utama — file lock dependensi. package-lock.json (npm), yarn.lock (Yarn), Podfile.lock (CocoaPods), pubspec.lock (Flutter) menetapkan versi yang tepat dari setiap paket. Tanpa file lock, dua pengembang yang menginstal dependensi pada waktu yang berbeda bisa mendapatkan versi minor yang berbeda. File lock harus ada di repositori dan tidak diedit secara manual.

Alat kedua — .env.example di repositori. File templat variabel lingkungan dengan komentar. Pengembang menyalinnya ke .env dan mengisi nilainya sendiri. Pipeline CI/CD memeriksa bahwa semua variabel wajib telah ditentukan. Menurut GitLab 2023, tim yang menggunakan .env.example mengurangi jumlah insiden terkait variabel lingkungan sebesar 40%.

Alat ketiga — hook pre-commit. Pemeriksaan otomatis yang berjalan sebelum setiap commit: linter, formatter, pemeriksaan tipe, tes. Jika hook dikonfigurasi sama di semua pengembang, kesalahan pemformatan atau tipe yang “lolos di mesin lokal” tidak akan mencapai produksi. Husky untuk JavaScript dan pre-commit untuk Python adalah solusi populer.

Alat keempat — pipeline CI/CD yang menjalankan tes di lingkungan bersih. Jika tes lulus di CI tetapi tidak secara lokal — masalahnya ada di pengaturan lingkungan lokal. Jika tes tidak lulus di CI — pull request tidak digabungkan. Aturan ketat ini mengecualikan masuknya bug yang “berfungsi secara lokal” ke cabang utama.