`dry-run` seçeneğinin avantajları üzerine

 (henrikwarne.com)
1 puan yazan GN⁺ 2026-02-02 | 1 yorum | WhatsApp'ta paylaş
  • Rapor oluşturma uygulaması geliştirme sürecinde, çalıştırma sonucunu simüle edebilmek için --dry-run seçeneğinin eklendiği bir örnek
  • Bu seçenek, gerçek bir değişiklik yapmadan hangi işlemlerin gerçekleştirileceğini çıktılar; böylece güvenli test ve hızlı geri bildirim sağlar
  • Geliştirici bunu kullanarak yapılandırmayı, erişilebilirliği ve sistem durumunu anında kontrol eder ve günlük doğrulama aracı olarak kullanır
  • Kod içinde dryRun bayrağını kontrol etme gerekliliği, bir miktar ek karmaşıklık olarak dezavantaj şeklinde belirtilir
  • Komut temelli uygulamalarda --dry-run işlevi çok kullanışlıdır ve projeye ne kadar erken eklenirse geliştirme verimliliği o kadar artar

Arka plan

  • Yeni geliştirilen rapor oluşturma uygulaması, her iş gününde rapor üretir, bunları sıkıştırıp bir sftp sunucusuna yükler, hata yanıtlarını kontrol eder ve bildirim e-postası gönderir
    • Her adımda üretilen dosyalar ve geri bildirim dosyaları, aşamaya göre farklı dizinlere taşınır
  • Geliştirmenin başında, Subversion ve çeşitli Linux komutlarındaki --dry-run seçeneği hatırlanarak aynı işlev eklendi
    • Bu seçenek, gerçek değişiklik olmadan çalıştırıldığında neler olacağını çıktılar
  • --dry-run çalıştırıldığında, oluşturulacak ve hariç tutulacak raporlar, sıkıştırılacak ve taşınacak dosyalar, ayrıca sftp ile yüklenecek ve indirilecek dosyalar adım adım gösterilir

Kullanım ve faydalar

  • Geliştirme ve test sürecinde her gün kullanılacak kadar faydalı bir işlev
  • Çalıştırmadan önce durum kontrolü amacıyla kullanıldığında, yapılandırma, erişilebilirlik ve sistem durumu anında doğrulanabilir
    • Gerçek değişiklik olmadığı için güvenle çalıştırılabilir
  • Rapor durum dosyasındaki tarih değiştirildikten sonra, ilgili raporun oluşturulup oluşturulmayacağı hemen kontrol edilebilir
    • Gerçek rapor üretimi zaman alabilir, ancak dry-run hızlı geri bildirim sağlar
  • Tüm sistemi test ederken de hızlı bir doğrulama döngüsü sunar

Dezavantajlar

  • Kod içinde dryRun bayrağını tekrar tekrar kontrol etmek gerektiği için bir miktar kod kirliliği oluşur
    • Ana adımların her birinde bayrak kontrol edilerek gerçek çalıştırma yerine yalnızca log çıktısı verilir
  • Ancak bu kontrol derinlemesine değildir ve rapor oluşturma mantığının içinde ayrı bir işleme gerek yoktur
    • Yalnızca çalıştırılıp çalıştırılmayacağına karar veren üst seviyedeki adımlarda kontrol edilir

Sonuç

  • Komutla çalıştırılan ve çıktı üreten uygulamalar --dry-run seçeneğiyle iyi uyum sağlar
    • Buna karşılık, mesaj bekleyen reaktif uygulamalar için uygun değildir
  • Projenin başında eklenmiş olması, geliştirme verimliliğini artırmada büyük fayda sağlamıştır
  • Her durumda gerekli bir özellik değildir, ancak uygun koşullarda çok yararlı bir araç olarak değerlendirilir

İlgili okumalar

1 yorum

 
GN⁺ 2026-02-02
Hacker News görüşleri

  • Durum tutan sistemlerle etkileşirken --dry-run içinde de race condition oluşabilir
    Araç, mevcut duruma göre “ne yapacağını” gösterir, ancak gerçek çalıştırma anında koşullar değişmiş olabilir
    Bu yüzden ben Terraform’un “plan” modu yaklaşımını tercih ediyorum. Bu mod, yürütülebilir bir plan üretir ve plan anındaki varsayımlar değişirse durabilir ya da rollback yapabilir
    Ayrıca kodun her yerine if dry_run: eklemek gerekmez; planlama ve yürütmeyi ayırıp execute(plan()) biçimine sadeleştirebilirsiniz

    • Geçmişte yaşanan AWS DNS kesintisi vakası da buna benzer bir race condition yüzündendi
      DNS Planner ile Enactor arasındaki zamanlama sorunu nedeniyle eski bir planın en güncel planın üzerine yazılması yaşanmıştı
      Konu önceki HN başlığında da ele alınmıştı
    • Bu yaklaşımın sonunda aslında bir derleyici (spesifikasyon→plan) ve bir sanal makine (plan→yürütme) yazmış oluyorsunuz
    • Terraform ya da Ansible gibi altyapı araçları için ideal, ama basit raporlama araçlarında gereksiz karmaşıklık yaratabilir
      Çünkü plan modu kurmak için alan özelinde bir dil ya da veri yapısı gerekir
    • Ben de hassas dosyaları değiştiren bir betik yazıyorum ve bu yaklaşımı uyguluyorum
      (1) Dosya sistemi durumunu yakalayıp planı kaydet → (2) durumun değişmediğini doğrulayıp çalıştır ve log tut → (3) önceki durumla karşılaştırıp veri kaybı olup olmadığını doğrula
      Bu üç adımı ayrı betikler ya da bayraklar olarak kullanıyorum
    • O halde rm komutuna böyle bir plan modunun nasıl uygulanabileceğini merak ediyorum

  • Bir araçta --dry-run yoksa bazen kendim oluşturuyorum
    Örneğin karmaşık bir sed komutunu çalıştırmadan önce, diff ile değişiklikleri önceden karşılaştırıyorum
    diff -u <(echo "hello") <(echo "hello" | sed "s/hello/hi/g") gibi bir yöntemle farkı görebiliyorsunuz
    İlgili yazıları blogumda topladım

  • --dry-run kalıbını seviyorum, ama dry yolundaki kodun gerçek yol ile aynı davranması gerekiyor
    Sadece “şunu yapacağım” deyip gerçek mantığı atlamak, gerçek çalıştırmada hataların gözden kaçmasına neden olabilir
    Veritabanı yazımı ya da API çağrısı anına kadar aynı şekilde ilerlemeli

    • Ama bazıları bunun entegrasyon testi ile dry-run’ı karıştırmak olduğunu düşünüyor
      Dry-run, “ne olacağını” göstermek içindir; gerçek test ise ayrı bir alandır

  • Ben tersine --commit ya da --execute bayrağı koyup, varsayılan çalıştırmayı salt okunur (dry) bırakmayı tercih ediyorum
    Böylece yanlışlıkla gerçek değişiklik yapma ihtimali azalıyor

    • Son 8 yıldır bu yaklaşımı kullanıyorum; yalnızca --commit açıkça verildiğinde değişiklik yapıldığı için güvenli oldu
      Buna karşılık --dry-run vermeyi unutup sorun yaşadığım çok oldu
    • Benim dizin yinelenenlerini kaldırma aracım da bu deseni izliyor
      Varsayılan olarak sadece karşılaştırma yapıyor; gerçek hardlink değiştirmesi için --execute gerekiyor
    • Eskiden kullandığım araçlardan bazılarında, gerçek çalıştırmadan önce belirli bir ifadeyi yazmak gerekiyordu
      Böyle onay adımları hataları azaltmada etkili oluyor
    • Kişisel olarak --wet-run gibi bir bayrağı da seviyorum. Bazen bağlama göre ters anlamlı bayrak daha sezgisel olabiliyor
    • Yakın zamanda yazdığım bir betikte varsayılan davranış salt okunur; gerçek silme için DELETE-ACCOUNT yazmak gerekiyor
      Şimdiye kadar yanlışlıkla tek bir hesabı bile silmedim

  • Kodun kirlenmesini önlemek için kalıcılığı (persistence) enjekte edilebilir bir strateji olarak ayırmak gerekir
    Kodun her yerine if dry_run: serpiştirmek iyi değil
    Hatta production çalıştırmayı --wet-run ile açıkça belirtmek daha güvenli olabilir

    • Uygulamanın davranışını açıkça modelleyip bunu merkezi olarak ele almak iyi bir yaklaşım
      Böylece dry-run kararını yalnızca tek bir yerde vermek mümkün olur — “functional core, imperative shell” tarzında
    • Ama her seferinde rm --wet-run tempfile.tmp yazmak zahmetli olur
      Varsayılanın gerçek çalıştırma olması, bunun yerine son işlemi geri alan bir --undo seçeneği olması daha iyi olurdu
    • --wet-run adı hoşuma gitmese de, varsayılanı dry-run yapıp değişiklik için --no-dry-run zorunlu kılan bir yaklaşımı da kullandım
      Bir servis söz konusuysa, çalıştırma ortamına göre (dev/prod) güvenli modu otomatik seçmek ideal olur
    • Bu tür durumlarda tasarım desenleri kullanmak yapıyı temiz tutmaya yardımcı olabilir

  • Yazıda “başta --dry-run ekledim, ama beklenmedik şekilde faydalı oldu” denmişti,
    aslında bu tür bayrakları yapay zeka kodlama ajanları (ör. Claude) sıkça otomatik öneriyor
    Bugün birçok CLI aracında benzer kalıpların görülmesinin nedeni, bu tür ajan kaynaklı kod yakınsaması da olabilir

    • Ama yazarın Subversion’un --dry-run seçeneğinden ilham aldığını açıkça belirtmiş olması da gayet ikna edici bir gerekçe

  • Ben CLI yardımcı programlarına --really bayrağı ekleyip varsayılanı salt okunur bırakıyorum
    Amaç, hataları önlemek için bilinçli bir onay adımı gerektirmek

    • Eskiden --i-meant-that bayrağı olan bir komut da vardı
      Uzak bir makineyi silen bu komut, varsayılan olarak 10 saniye bekleyip iptal etme fırsatı veriyordu
      Neyse ki bu bayrak hiç yanlış kullanılmadı

  • PowerShell’in güzel yanlarından biri, [CmdletBinding(SupportsShouldProcess)] satırını ekleyince
    -WhatIf dry-run özelliğinin otomatik olarak kullanılabilmesi
    Bu gerçekten çok kullanışlı bir özellik

    • Üstelik -Confirm da birlikte etkinleşiyor ve ShouldProcess işleviyle kullanıcının onay eşiği ile etkileşim kurulabiliyor. Gerçekten çok şık bir tasarım

  • Yönettiğim dahili CLI’de if not dry_run: koşulunu REST API çağrılarının içine koyuyorum
    Böylece gerçek çağrı yerine, hangi isteğin gönderileceğini görmek için CURL komutu logu bırakabiliyorum
    Ancak API’ler arası etkileşim karmaşıklaştıkça simülasyon zorlaşıyor ve bu yapı basit bir if not dry_run: yaklaşımından çok daha karmaşık hale geliyor

    • Mümkün olduğunca gerçek davranışı yalnızca tek bir yerde gerçekleştirecek şekilde yapılandırmak, kodun kirlenmesini önleyebilir
      Ben de otomasyon pipeline’ları için birçok CLI’nin bakımını yapıyorum ve bu deseni neredeyse tüm araçlara uyguluyorum
    • Ama konsol araçlarında REST’i aşırı kullanmanın verimsiz olduğunu düşünenler de var
      Önce yerel aracı doğru yapmak gerektiğini savunuyorlar

  • Eğer --dry-run bayrağı kod tabanının her yanına dağılmışsa, durum makinesi deseni uygulayıp her aşamayı net biçimde ayırmak iyi olur