Software Engineering at Google: Lessons Learned from Programming Over Time

Google memelihara salah satu basis kode terbesar yang pernah ada, dengan ekspektasi umur pakai puluhan tahun ke depan.

Setiap hari, puluhan ribu perubahan kode masuk ke sistem itu. Ribuan engineer bekerja di dalamnya, banyak yang belum lahir saat baris kode pertama ditulis.

Bagaimana caranya sebuah organisasi menjaga sistem sebesar itu tetap waras?

Titus Winters, Tom Manshreck, dan Hyrum Wright, tiga engineer senior di Google, menulis buku ini untuk menjawab pertanyaan itu, bukan lewat teori abstrak, tapi lewat pelajaran nyata dari pengalaman bertahun-tahun mengelola kode dalam skala yang nyaris tidak masuk akal bagi kebanyakan perusahaan lain.

Poin utama yang mereka tekankan sejak halaman pertama, programming dan software engineering itu dua hal yang berbeda, meski sering dianggap sama.

“Software engineering can be thought of as programming integrated over time.”

Programming adalah soal menulis kode yang berfungsi sekarang. Software engineering adalah soal menjaga kode itu tetap berfungsi, bisa dipahami, dan bisa diubah, bertahun-tahun ke depan, oleh orang-orang yang bahkan belum bergabung ke tim saat kode itu pertama kali ditulis.

Tiga prinsip inilah yang jadi benang merah seluruh buku: time, scale, dan trade-offs.

Bagian 1: Time, Kenapa Kode yang "Berfungsi Hari Ini" Belum Tentu Baik

Sepotong skrip cepat yang Anda tulis untuk keperluan sekali pakai, dan sebuah sistem yang akan dipakai jutaan orang selama sepuluh tahun ke depan, seharusnya tidak ditulis dengan standar yang sama.

Hyrum's Law, Kejutan yang Muncul dari Skala Besar

Salah satu konsep paling terkenal dari buku ini, yang bahkan dinamai dari salah satu penulisnya sendiri, adalah Hyrum's Law: dengan jumlah pengguna API yang cukup besar, tidak masalah apa yang Anda janjikan di kontrak API, semua perilaku sistem Anda yang bisa diamati pada akhirnya akan bergantung pada seseorang.

Artinya, meski Anda tidak pernah menjanjikan sebuah efek samping tertentu, kalau efek samping itu ada dan bisa diamati, cepat atau lambat, ada pengguna yang akan diam-diam bergantung padanya. Ini membuat perubahan sistem yang kelihatannya aman jadi jauh lebih rumit dari yang dibayangkan, terutama di skala Google.

Penulis mendorong pembaca untuk berpikir soal siklus hidup penuh kode, dari saat ditulis, dipakai luas, sampai akhirnya di-deprecate, bukan cuma berpikir sampai momen kode itu pertama kali lolos code review.

Bagian 2: Scale, Kenapa Aturan yang Berlaku untuk Tim Kecil Bisa Runtuh di Tim Besar

Sesuatu yang terasa sepele di tim beranggotakan lima orang, seperti setiap orang menulis kode dengan gayanya masing-masing, bisa jadi bencana di organisasi dengan ribuan engineer.

"Karena Saya Bilang Begitu" Bukan Alasan yang Cukup

Penulis menegaskan, keputusan teknis di skala besar tidak boleh cuma berdasarkan otoritas atau kebiasaan lama tanpa data pendukung. Tapi mereka juga jujur, di dunia nyata, kebanyakan keputusan tetap berupa campuran antara data, preseden, dan argumen, bukan murni data semata.

Google menggunakan pendekatan monorepo, satu repositori raksasa yang menampung sebagian besar kodenya, untuk memudahkan manajemen dependensi lintas tim dan kolaborasi berskala besar, meski pendekatan ini butuh tooling khusus yang sangat matang agar tetap bisa dikelola.

Prinsip yang berlaku di sini, kebijakan dan praktik yang berhasil di tim kecil sering kali harus dirombak total begitu organisasi tumbuh, bukan karena tim kecilnya salah, tapi karena asumsi dasarnya berubah seiring skala yang membesar.

Bagian 3: Trade-offs, Kenapa Tidak Ada Keputusan Teknis yang Gratis

Setiap keputusan arsitektur punya harga. Pertanyaannya bukan "apakah ada trade-off", tapi "trade-off mana yang paling masuk akal untuk konteks Anda sekarang".

Kelengkapan, Latensi, dan Ekspresivitas, Tiga Hal yang Saling Menarik

Penulis menjelaskan bagaimana desain sistem sering harus menyeimbangkan kelengkapan fungsional, kecepatan eksekusi, dan seberapa ekspresif atau fleksibel sebuah API atau sistem itu bisa dipakai. Mengoptimalkan satu aspek nyaris selalu berarti mengorbankan sedikit dari aspek lainnya.

Buku ini menolak pendekatan "satu solusi terbaik untuk semua kasus". Sebaliknya, penulis mendorong pembaca memahami konteks spesifik proyek mereka, apakah butuh iterasi sangat cepat, atau butuh stabilitas jangka panjang, sebelum menentukan trade-off mana yang paling masuk akal diambil.

Kesadaran akan trade-off inilah yang membedakan keputusan teknis yang matang dari sekadar mengikuti tren atau kebiasaan tanpa mempertimbangkan konteks nyata proyek yang sedang dikerjakan.

Bagian 4: Testing sebagai Budaya, Bukan Sekadar Checklist

Bagaimana caranya organisasi menangani puluhan ribu perubahan kode setiap hari tanpa sistem kritis ambruk berulang kali?

Jawaban penulis, lewat budaya testing yang sangat matang dan otomatis, bukan cuma prosedur formal yang dijalankan sekenanya.

Melawan Flakiness dengan Pengujian Probabilistik

Google menghadapi masalah unit test yang kadang gagal secara acak, dikenal sebagai "flaky tests", dan penulis membahas bagaimana mereka mengembangkan pendekatan pengujian probabilistik untuk meminimalkan gangguan ini, sehingga tim tidak kehilangan kepercayaan pada hasil test mereka sendiri.

Code review juga diperlakukan sebagai bagian tak terpisahkan dari budaya testing ini, didukung tooling otomatis dan aturan kepemilikan kode yang jelas, memastikan setiap perubahan diperiksa dengan konsisten tanpa membebani satu orang untuk mengingat semua aturan secara manual.

Filosofi dasarnya, testing bukan langkah terakhir sebelum rilis, melainkan bagian yang terintegrasi penuh ke dalam alur kerja harian setiap engineer, dari commit pertama sampai kode itu benar-benar dipakai di produksi.

Bagian 5: Selalu Memutuskan, Selalu Pergi, Selalu Berkembang

Di bagian yang membahas kepemimpinan teknis, penulis merangkum filosofi kepemimpinan Google lewat tiga prinsip yang terdengar sederhana tapi dalam maknanya.

Always Be Deciding, Always Be Leaving, Always Be Scaling

Always be deciding berarti masalah-masalah ambigu tidak punya jawaban ajaib, hanya trade-off terbaik untuk momen itu, yang harus terus dievaluasi ulang seiring waktu berjalan.

Always be leaving berarti tugas seorang pemimpin teknis bukan menjadi satu-satunya orang yang tahu solusi, melainkan membangun organisasi yang bisa menyelesaikan kelas masalah tertentu secara mandiri, bahkan tanpa kehadiran pemimpin itu secara langsung.

Always be scaling berarti kesuksesan seorang pemimpin akan mendatangkan lebih banyak tanggung jawab seiring waktu, dan pemimpin itu harus secara proaktif mengelola pertumbuhan itu, demi menjaga waktu, perhatian, dan energinya sebagai sumber daya yang terbatas.

Pelajaran untuk Hari Ini

1. Pikirkan Siklus Hidup Penuh Kode Anda, Bukan Cuma Sampai Lolos Review Pertimbangkan bagaimana kode Anda akan dipakai, diubah, dan akhirnya dihentikan bertahun-tahun ke depan, bukan cuma apakah kode itu berfungsi hari ini.

2. Waspadai Hyrum's Law Setiap Kali Mengubah API atau Sistem yang Sudah Dipakai Luas Ingat, perilaku yang bisa diamati, meski tidak pernah dijanjikan resmi, kemungkinan besar sudah diandalkan seseorang di luar sana.

3. Sesuaikan Praktik Tim dengan Skala Organisasi Anda Saat Ini Kebijakan yang efektif di tim kecil belum tentu masih relevan begitu tim Anda tumbuh jauh lebih besar. Evaluasi ulang secara berkala.

4. Jadikan Testing Bagian dari Alur Kerja Harian, Bukan Langkah Terpisah Sebelum Rilis Investasikan waktu membangun budaya testing yang matang dan otomatis, agar kepercayaan tim terhadap hasil test tidak pernah goyah.

Penutup

Software Engineering at Google ditulis dari pengalaman mengelola salah satu basis kode terbesar dan paling lama umurnya di dunia teknologi. Meski banyak praktik spesifiknya, seperti monorepo raksasa dan tooling internal Google, tidak selalu bisa langsung diterapkan di organisasi yang jauh lebih kecil.

Yang membuat buku ini tetap berharga bagi siapa pun, prinsip dasarnya, time, scale, dan trade-offs, berlaku universal, tidak peduli seberapa besar organisasi Anda sekarang, karena cepat atau lambat, setiap kode yang bertahan cukup lama akan menghadapi tantangan yang sama.

Di era ketika tim engineering makin sering menggunakan AI untuk mempercepat penulisan kode, pertanyaan soal bagaimana menjaga kode itu tetap sustainable dalam jangka panjang justru menjadi semakin relevan, karena kecepatan menulis kode tidak otomatis berarti kemudahan memeliharanya bertahun-tahun ke depan.

Pertanyaan untuk Anda, seberapa sering tim Anda mempertimbangkan siklus hidup penuh kode yang ditulis hari ini, dibanding sekadar memastikan kode itu lolos review dan berfungsi untuk sekarang?

Tentang Buku Asli