Aturan Pemrograman Rob Pike (1989)

• Artikel tentang 5 aturan pemrograman Rob Pike pada tahun 1989
• Aturan 1: Jangan berasumsi di mana program akan menghabiskan sebagian besar waktunya; bottleneck bisa muncul secara tak terduga. Hindari hack demi kecepatan sampai bottleneck itu terbukti.
• Aturan 2: Selalu ukur sebelum melakukan tuning demi kecepatan. Optimalkan hanya jika sebagian kode benar-benar memberi dampak signifikan pada sisanya.
• Aturan 3: Algoritma yang rumit itu lambat saat n kecil. Dan biasanya memang begitu. Gunakan algoritma rumit hanya jika n sering besar, dan bahkan saat itu pun terapkan dulu Aturan 2.
• Aturan 4: Algoritma dan struktur data yang sederhana lebih diinginkan. Keduanya lebih kecil kemungkinannya mengandung bug dibanding yang rumit dan lebih mudah diimplementasikan.
• Aturan 5: Struktur data yang tepat sangat menentukan dalam pemrograman. Jika data tersusun dengan baik, algoritmanya akan menjadi jelas dengan sendirinya.
• Aturan 1 dan 2 Pike mencerminkan pepatah Tony Hoare, "premature optimization is the root of all evil".
• Ken Thompson mengungkapkan kembali Aturan 3 dan 4 Pike sebagai "when in doubt, use brute force".
• Aturan 3 dan 4 mewujudkan filosofi desain KISS (Keep It Simple, Stupid).
• Aturan 5 sejalan dengan pernyataan Fred Brooks dalam 'The Mythical Man-Month', yang sering diringkas sebagai "Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious."

[GN⁺]

Komentar Hacker News

• Artikel tentang aturan pemrograman Rob Pike pada 1989
• Para komentator setuju bahwa inti pemrograman adalah struktur data, bukan algoritma
• Kritik bahwa wawancara LeetCode tidak berfokus pada struktur data ketimbang algoritma
• Argumen bahwa algoritma yang rumit itu lambat saat n kecil, dan dalam kebanyakan kasus n memang kecil
• Para komentator menekankan pentingnya memilih struktur data yang tepat dan menatanya dengan rapi
• Diskusi tentang penyalahgunaan database dan dampak negatif skema DB yang dihasilkan ORM
• Pedoman ini tampaknya merupakan strategi untuk mencegah over-engineering dan optimisasi prematur
• Beberapa komentator berpendapat bahwa pemborosan kecil pada performa bisa terakumulasi dan membuat program menjadi lambat
• Perdebatan tentang kutipan "optimisasi prematur adalah akar dari segala kejahatan" dan konteksnya
• Klaim sebagian komentator bahwa programmer yang baik dapat memprediksi apa yang akan melambat dan membuat taruhan edukatif sebelumnya
• Sanggahan bahwa algoritma yang kompleks untuk data sederhana dapat membawa peningkatan performa besar dan bahkan menyederhanakan
• Artikel ini terus memengaruhi pendekatan sebagian pembaca terhadap desain dan kompleksitas
• Diskusi tentang interpretasi aturan 5, dengan beberapa ketidaksetujuan terhadap frasa "tulislah kode bodoh yang menggunakan objek pintar"