Rob Pike'ın Programlama İçin 5 Kuralı (1989)

• Kural 1: Bir programın zamanını nerede harcayacağını öngöremezsiniz. Darboğazlar beklenmedik yerlerde ortaya çıkar; bu yüzden gerçekten darboğaz olduğu kanıtlanana kadar hızı artırmaya çalışmayın
• Kural 2: Ölçüm önce gelir. Performans ayarı yalnızca ölçümden sonra yapılmalı; optimizasyon ancak kodun bir bölümü bütüne baskın geldiğinde düşünülmelidir
• Kural 3: Karmaşık algoritmalar küçük n için yavaştır. Karmaşık algoritmalar büyük sabitler taşır; n sık sık büyümüyor ise basit yöntemi kullanın. n büyüse bile önce Kural 2 uygulanmalıdır
• Kural 4: Karmaşık algoritmalar daha fazla hataya sahiptir ve uygulanmaları zordur. Basit algoritmalar ve basit veri yapıları kullanmak tercih edilmelidir
• Kural 5: Veri esastır. Doğru veri yapısını seçip iyi organize ederseniz, algoritma neredeyse kendiliğinden ortaya çıkar. Programlamanın merkezi algoritmalar değil, veri yapılarıdır

İlgili felsefe ve alıntılar

• Kural 1 ve 2, Tony Hoare'un "erken optimizasyon bütün kötülüklerin kaynağıdır" özdeyişiyle aynı anlama gelir
• Ken Thompson, Kural 3 ve 4'ü "Şüphe duyduğunda basit yöntemi (Brute Force) kullan" diye yeniden yorumladı
• Kural 3 ve 4, KISS (Keep It Simple, Stupid) tasarım felsefesinin bir örneğidir
• Kural 5, Fred Brooks'un 『The Mythical Man-Month』 kitabında zaten değinilmiş bir noktadır ve
  çoğu zaman "akıllı nesneler kullanan basit kod yazmak" diye özetlenir

[GN⁺]

Hacker News görüşleri

• Jonathan Blow’un konuşmasını hatırlatıyor
  O, konuya üretkenlik açısından yaklaşıyordu. Braid’in geliştirilmesinin ilk dönemlerinde neredeyse her şeyi basit dizilerle uygulamış, yalnızca darboğaz oluştuğunda değiştirmişti
  “Hızdan ya da bellekten daha önemli olan şey, tek bir programı hayata geçirmek için harcanan ömür zamanıdır” sözü özellikle etkileyiciydi

  • Oyunlar, çok sayıdaki benzer nesneyi saniyede 60 kareden fazla hızla tekrar tekrar işlediği için, basit dizi tabanlı yapı makul bir varsayılan seçenektir
  • Oyun geliştirmede kareyi 16ms içinde render etmek gerektiğinden, sabit boyutlu tablolar ve doğrusal arama yaygın bir örüntüdür. Bu, dinamik bellek tahsisinin öngörülemezliğinden kaçınmak için yapılan yapısal bir tercihtir
  • Bu bakış açısı oyun dışındaki genel geliştirme için de geçerlidir. Hepimiz teslim tarihi ve maliyet kısıtları altında çalıştığımız için, mühendislik zamanının kendisi de bir maliyettir
  • Yine de oyunlardan çıkan dersleri genel programlamaya aynen genişletirken dikkatli olmak gerekir. Oyunlar yeniden kullanımdan çok özel amaçlı kod odaklıdır; genel yazılımsa veri odaklıdır
  • Ben ise dizi yerine hash map ile başlayan tiplerdenim

• Rule 1’i gerçekten ciddiye alırsanız, Rule 3~5 doğal olarak gelir
  Darboğazların öngörülemeyeceği öncülünü kabul ederseniz, basit kod yazmak ve ölçmek tek makul strateji haline gelir
  Pratikte en sık başarısız olunan şey erken optimizasyon değil, erken soyutlamadır. Gerekli olmayan esneklik uğruna karmaşık katmanlar kurulur ve bu da bakım maliyetini artırır

  • “Soyutlama doğal olarak ortaya çıkmalı, önceden tasarlanmamalı” sözünü ekip içinde sık sık alıntılıyorum
  • Erken soyutlama geliştirici zamanını boşa harcar, teknik borç yaratır ve hata olasılığını artırır. Çoğu zaman ‘gelecekteki sorunlara hazırlanmak’ bahanesiyle ortaya çıkar
  • İlgili bir makale olarak Philip Wadler’in yazısına bakılabilir
  • Ben performanstan çok okunabilirlik ve bakım kolaylığını önemsiyorum. Bu yüzden benim için temel olan Rule 4, Rule 1 ise bunun sonucudur
  • Aşırı parçalanmış karmaşık yapılandırma dosyalarıyla ilgili örnekler yaşadım. Sonunda 8 basit YAML dosyası yeterli oldu

• 90’larda gece 2’de bir veri kümesi arama özelliği yazmak zorunda kaldığım bir deneyimim var
  Yorgunluktan önce bunu doğrusal arama ile yazıp sonra düzeltmeye karar vermiştim, ama gerçekte 4 saatlik testte yalnızca 6 saniye fark çıktı
  Sonunda düzelttim ama anlamlı bir fark yoktu

  • Küçük n değerlerinde doğrusal arama hatta daha hızlı olabilir
  • Ama O(n²) algoritmalar “yayına alınır ama sonunda prod’da patlar” türünden bir risk taşır

• Rule 5’e tamamen katılıyorum
  Zor problemler ne kadar büyükse, çözüm de o kadar çok veri yapıları ve API’nin yinelemeli olarak iyileştirilmesiyle bulunuyor. Yapı iyi kurulduğunda kontrol akışı doğal hale geliyor
  LLM’ler bu tür yapısal düşünmede zayıf. Karmaşık kontrol akışlarını iyi önerseler de, birleştirilebilir veri yapıları tasarımı konusunda başarılı değiller

  • Benim deneyimime göre Rule 5 aslında Rule 1’dir. “Kodu gösterirsen kafam karışır ama veritabanı şemasını gösterirsen her şey netleşir” diye bir söz vardır
  • Dağıtık servislerde Rule 5 sık sık göz ardı edilir. Birden fazla HTTP·DB çağrısını bölmek yerine, tek bir çağrıyla işlenebilecek bir yapı daha verimlidir

• Ben elektrik-elektronik (E.E.) kökenliyim ve Rule 3 sayesinde kariyerimin başlarında büyük bir sorun yaşamadım
  Ama daha sonra büyük ölçekli sistemlere geçince n büyüdü ve karmaşıklık gerçekten önemli hale geldi
  Rob Pike’ın söz ettiği dönemin ‘big iron’ sistemleri, bugünün gömülü ortamlarına benziyordu

  • Rule 3’e kısmen karşıyım. Küçük girdilerde fark etmeyebilir ama büyük girdilerde Big-O performansı önemlidir.
    İki algoritmanın uygulama zorluğu benzerse, büyük girdilerde hızlı olanı seçerim
    İlgili yazı: Less Than Quadratic
  • “fancy” kelimesinin anlamını problem alanına göre yorumlamak gerekir. n küçükse basit yaklaşım daha iyidir; n büyükse gelişmiş algoritmalar şarttır
    İnsanlar sık sık aşırı basit O(n²) yaklaşımı seçip prod’da patlama yaşar
  • Babam Fortran günlerinden beri lookup table kullanmayı severdi. Bu, tekrarlanan hesaplamayı azaltan klasik bir optimizasyon yöntemidir

• Pike’ın kurallarının mevcut özdeyişlerden daha iyi olduğunu düşünüyorum
  “Erken optimizasyon bütün kötülüklerin köküdür” gibi cümleler bağlamından kopunca yanlış anlaşılmaya çok açıktır
  Pike’ın versiyonu açık ve kötüye kullanılması zor
  Eskiden “Rule 5, aptal kodun akıllı nesneler kullanmasına izin ver” diye özetlenirdi,
  ama nesne yönelimli çağda bu, tersine karmaşıklığı gizleyen yanlış bir inança dönüştü

  • Tarihsel düşüncenin bağlantı zincirini korumak önemlidir
  • “Klasik özdeyişlerin zihinsel clickbait’i” ifadesi bir tür zekice benzetme gibi geliyor

• 10 yıldan uzun süredir aynı kod tabanını işletirken Pike’ın kurallarını tamamen içselleştirdim
  KISS/DRY ilkelerine bağlı kalmak ve moda teknolojiler yerine kendini kanıtlamış teknolojileri sürdürmek, uzun vadede daha istikrarlı oldu
  Nitekim ekibimizin geliştirme ilkeleri belgesi, Pike’ın kurallarıyla neredeyse aynı içerikte

• 1990’ların başındaki C++ döneminde, çift bağlı liste yerine basit dizi yeniden tahsisine geçince
  hatalar yalnızca kaybolmakla kalmadı, sistem ayrıca daha da hızlandı.
  Pahalı işlemleri daha seyrek yapmak iyi bir stratejiymiş, bunu öğrendim

• “Ölçmeden tuning yapma” kuralını Jeff Dean’in Latency Numbers Every Programmer Should Know metniyle karşılaştırmak ilginç
  Dean, ön bilgiyle performansın tahmin edilebileceğini söylüyor
  Sonuçta bu iki yaklaşım uzlaştırılabilir — tasarım aşamasında sezgisel olarak hızlı yapıları seçmeli, uygulamadan sonra ise ölçüm temelli ince ayar yapmalısınız

  • Gerçekten hızlı kod her iki yaklaşımı da kullanır. Tasarım aşamasında cache verimliliği dikkate alınır, sonrasında profiling ile darboğazlar giderilir
  • Gecikme (latency) değerleri algoritmanın teorik üst-alt sınırlarını gösterir; gerçek performans ise uygulamaya ve çalışma zamanı ortamına bağlıdır
  • ‘Erken optimizasyon’un yasakladığı şey, yerel hack düzeyindeki tuningdir. Genel tasarımda hızı hesaba katmak ise doğaldır

• Rule 1 ve 2 yalnızca yeni problemlerle uğraşırken mutlak kurallardır
  Aynı alanda tekrar tekrar sistem kurdukça, darboğaz noktaları önceden tahmin edilebilir hale gelir
  Deneyimli geliştiriciler tasarımdan önce bile kabaca bir performans hissine sahip olabilir

  • Ben de çoğu durumda darboğazları doğru tahmin ettim. Ön performans testleri nedeniyle yaklaşımımı değiştirdiğim de çok oldu
  • Ama 30 yıllık deneyimime göre, darboğaz çıkacağına dair his doğru olur, ama tam yeri ya da zamanı öngörülemez
  • “Rob Pike ne bilecek ki” diye bir şaka da vardı, ama kendisi Unix ve Go’yu yapan kişilerden biri. Kurallarının bir nedeni var