5 Aturan Pemrograman dari Rob Pike (1989)

• Aturan 1: Tidak mungkin memprediksi di mana program akan menghabiskan waktu. Bottleneck muncul di tempat yang tak terduga, jadi jangan mencoba meningkatkan kecepatan sampai benar-benar terbukti itulah bottleneck-nya
• Aturan 2: Pengukuran adalah yang utama. Tuning performa hanya dilakukan setelah pengukuran, dan optimisasi dipertimbangkan hanya ketika satu bagian kode benar-benar mendominasi keseluruhan
• Aturan 3: Algoritme kompleks lambat untuk n kecil. Algoritme kompleks memiliki konstanta besar, jadi gunakan cara yang sederhana kecuali n sering menjadi besar. Bahkan jika n membesar, terapkan dulu Aturan 2
• Aturan 4: Algoritme kompleks lebih banyak bug dan lebih sulit diimplementasikan. Lebih baik menggunakan algoritme sederhana dan struktur data yang sederhana
• Aturan 5: Data adalah inti. Jika memilih struktur data yang tepat dan menatanya dengan baik, algoritme akan hampir tampak dengan sendirinya. Pusat pemrograman bukanlah algoritme, melainkan struktur data

Filosofi dan kutipan terkait

• Aturan 1 dan 2 memiliki makna yang sama dengan pepatah Tony Hoare, “optimisasi dini adalah akar dari segala kejahatan”
• Ken Thompson menafsirkan ulang Aturan 3 dan 4 sebagai “kalau ragu, gunakan cara yang sederhana (Brute Force)”
• Aturan 3 dan 4 adalah contoh filosofi desain KISS(Keep It Simple, Stupid)
• Aturan 5 sudah pernah disebutkan Fred Brooks dalam 『The Mythical Man-Month』,
  dan sering diringkas sebagai “menulis kode sederhana dengan menggunakan objek yang cerdas”

[GN⁺]

Komentar Hacker News

• Mengingatkan pada ceramah Jonathan Blow
  Ia mendekatinya dari sudut pandang produktivitas. Pada tahap awal pengembangan Braid, hampir semuanya diimplementasikan sebagai array sederhana, lalu hanya diubah saat muncul bottleneck
  Ucapan “yang lebih penting daripada kecepatan atau memori adalah waktu hidup manusia yang dibutuhkan untuk mengimplementasikan sebuah program” terasa sangat membekas

  • Game memproses sangat banyak objek serupa berulang kali pada 60 frame per detik atau lebih, jadi struktur berbasis array yang sederhana adalah default yang masuk akal
  • Dalam pengembangan game, frame harus dirender dalam 16ms, jadi tabel berukuran tetap dan pencarian linear adalah pola yang umum. Ini adalah pilihan struktural untuk menghindari ketidakpastian alokasi dinamis
  • Sudut pandang ini juga berlaku untuk pengembangan umum di luar game. Kita semua bekerja di bawah tenggat dan batas biaya, jadi waktu engineering itu sendiri adalah biaya
  • Namun, pelajaran dari game perlu hati-hati jika diterapkan mentah-mentah ke pemrograman umum. Game berfokus pada kode tujuan khusus daripada reuse, sedangkan software umum berpusat pada data
  • Dalam kasus saya, saya tipe orang yang mulai dengan hash map, bukan array

• Jika Rule 1 diterima dengan sungguh-sungguh, maka Rule 3~5 akan mengikuti secara alami
  Jika kita mengakui premis bahwa bottleneck tidak bisa diprediksi, maka menulis kode sederhana dan mengukurnya menjadi satu-satunya strategi yang rasional
  Kegagalan yang paling sering sebenarnya bukan optimisasi prematur, melainkan abstraksi prematur. Orang membuat lapisan yang rumit demi fleksibilitas yang belum diperlukan, dan itu justru menaikkan biaya pemeliharaan

  • Di tim, kami sering mengutip kalimat “abstraksi harus muncul secara alami, bukan dirancang dari awal”
  • Abstraksi prematur membuang waktu developer, menambah utang teknis, dan meningkatkan kemungkinan bug. Sering kali muncul atas nama ‘bersiap untuk masalah masa depan’
  • Sebagai bacaan terkait, tulisan Philip Wadler layak dirujuk
  • Saya lebih mementingkan keterbacaan dan maintainability daripada performa. Jadi bagi saya Rule 4 itu fundamental, dan Rule 1 adalah akibatnya
  • Saya pernah mengalami kasus file konfigurasi kompleks yang dipecah berlebihan. Pada akhirnya, 8 file YAML sederhana sudah lebih dari cukup

• Saya pernah harus mengimplementasikan fitur pencarian dataset pada pukul 2 pagi di era 90-an
  Karena lelah, saya membuatnya dengan pencarian linear dulu dan berniat memperbaikinya nanti, tetapi dalam praktiknya selisihnya hanya 6 detik dalam pengujian selama 4 jam
  Akhirnya memang saya ubah, tetapi tidak ada perbedaan yang berarti

  • Untuk n kecil, pencarian linear justru bisa lebih cepat
  • Namun, algoritme O(n²) punya risiko “bisa dirilis, tetapi pada akhirnya meledak di production”

• Saya sepenuhnya setuju dengan Rule 5
  Semakin sulit masalahnya, semakin sering ia diselesaikan lewat perbaikan iteratif pada struktur data dan API. Jika strukturnya tertata baik, alur kontrol akan mengikuti dengan alami
  LLM lemah dalam cara berpikir struktural seperti ini. Mereka pandai mengusulkan alur kontrol yang kompleks, tetapi kurang mampu merancang struktur data yang bisa dikomposisikan

  • Dalam pengalaman saya, Rule 5 pada dasarnya adalah Rule 1. Ada ungkapan, “kalau diperlihatkan kodenya, semuanya membingungkan, tetapi kalau diperlihatkan skema database-nya, semuanya jadi jelas”
  • Dalam layanan terdistribusi, Rule 5 sering diabaikan. Daripada memecahnya menjadi banyak panggilan HTTP·DB, struktur yang bisa ditangani dalam satu panggilan lebih efisien

• Saya berlatar belakang teknik elektro (E.E.), dan berkat Rule 3 saya tidak mengalami masalah besar di awal karier
  Namun, setelah pindah ke sistem berskala besar, n membesar dan kompleksitas benar-benar menjadi penting
  ‘Big iron’ pada masa yang dibicarakan Rob Pike mirip dengan lingkungan embedded saat ini

  • Saya agak tidak setuju dengan Rule 3. Untuk input kecil mungkin tidak masalah, tetapi untuk input besar performa big-O itu penting.
    Jika dua algoritme punya tingkat kesulitan implementasi yang mirip, saya memilih yang lebih cepat untuk input besar
    Tulisan terkait: Less Than Quadratic
  • Makna “fancy” harus ditafsirkan sesuai domain masalah. Jika n kecil, pendekatan sederhana lebih baik, tetapi jika n besar, algoritme tingkat lanjut itu wajib
    Sering kali orang memilih pendekatan O(n²) yang terlalu sederhana lalu mengalami ledakan di production
  • Ayah saya sejak era Fortran senang memakai lookup table. Itu cara optimisasi klasik untuk mengurangi perhitungan berulang

• Saya pikir aturan Pike lebih baik daripada pepatah lama yang sudah ada
  Kalimat seperti “optimisasi prematur adalah akar dari segala kejahatan” mudah disalahpahami karena konteksnya hilang
  Versi Pike jelas dan sulit disalahgunakan
  Dulu ada ungkapan lama bahwa “Rule 5 bisa diringkas menjadi ‘biarkan kode bodoh memakai objek pintar’”,
  tetapi di era pemrograman berorientasi objek, itu justru berubah menjadi keyakinan keliru yang menyembunyikan kompleksitas

  • Penting untuk menjaga mata rantai pemikiran historis tetap tersambung
  • Ungkapan “clickbait mental dari pepatah klasik” terasa seperti metafora yang jenaka

• Setelah mengelola codebase yang sama selama lebih dari 10 tahun, saya benar-benar sudah menginternalisasi aturan Pike
  Menjaga prinsip KISS/DRY dan mempertahankan teknologi yang sudah teruji, alih-alih mengejar tren, terbukti lebih stabil dalam jangka panjang
  Faktanya, dokumen prinsip pengembangan tim kami hampir sama persis dengan aturan Pike

• Pada era awal C++ di tahun 1990-an, saya pernah mengganti doubly linked list dengan realokasi array sederhana,
  dan bukan hanya bug-nya hilang, performanya malah lebih cepat.
  Saya belajar bahwa melakukan operasi mahal lebih jarang adalah strategi yang baik

• Menarik membandingkan aturan “jangan tuning tanpa mengukur” dengan Latency Numbers Every Programmer Should Know dari Jeff Dean
  Dean mengatakan bahwa dengan pengetahuan sebelumnya kita bisa memprediksi performa
  Pada akhirnya, kedua posisi ini bisa selaras — pada tahap desain kita memilih struktur yang secara intuitif cepat, lalu setelah implementasi kita melakukan penyesuaian halus berbasis pengukuran

  • Kode yang benar-benar cepat memakai kedua pendekatan. Pada tahap desain ia mempertimbangkan efisiensi cache, lalu setelah itu menghilangkan bottleneck lewat profiling
  • Angka latensi hanya menunjukkan batas teoretis algoritme; performa nyata berubah tergantung implementasi dan lingkungan runtime
  • Yang dilarang oleh ‘optimisasi prematur’ adalah tuning tingkat hack lokal. Mempertimbangkan kecepatan dalam desain keseluruhan adalah hal yang wajar

• Rule 1 dan 2 bersifat mutlak hanya saat menangani masalah baru
  Jika kita berulang kali membangun sistem di domain yang sama, kita bisa memprediksi titik bottleneck sebelumnya
  Developer berpengalaman bisa punya intuisi kasar soal performa bahkan sebelum desain dimulai

  • Saya juga dalam banyak kasus memprediksi bottleneck dengan tepat. Sering juga pendekatan saya ubah lewat pengujian performa sebelumnya
  • Tetapi dari pengalaman 30 tahun, walaupun feeling bahwa bottleneck akan muncul sering benar, lokasi atau waktunya yang tepat tetap tidak bisa diprediksi
  • Ada juga candaan “memangnya Rob Pike tahu apa”, tetapi dia adalah orang yang membuat Unix dan Go. Ada alasan mengapa aturannya seperti itu