DRY ve RUG — Tekrar Eden Kodun Gerçekten Daha İyi Tasarım Olduğu Durumlar

TL;DR

DRY (Don’t Repeat Yourself), çoğu yazılım mühendisliği eğitiminde öğretilen bir ilkedir. Ancak bazen tekrarı kabul etmek daha iyi bir tasarım olabilir. Burada önemli bir mental model olarak RUG — Repeat Until Good kullanılabilir.

Abstraksiyonu erken çıkarmaktansa, tasarımın netleşmesini beklemek için küçük tekrarları kabul etmek önemlidir.

DRY ilkesini körü körüne takip etmek, kırılgan abstraksiyonlar, gizli niyet ve alakasız bileşenler arasında sıkı bağlılık gibi sonuçlar doğurabilir.

Detayı Okuyun

DRY, benzer bir mantığın birçok yerde tekrar edilmesi durumunda güncellemelerin riskli hale gelmemesi için oldukça faydalıdır. Ancak, yazılım mühendisliği tartışmalarında az konuşulan bir başka fikir daha vardır:

Bazen tekrar, tasarımın evrimini sağlayan en güvenli yoludur.

Abstraksiyonu erken çıkarmak yerine, kodun doğru abstraksiyon doğal olarak ortaya çıkana kadar tekrar etmesine izin vermek gereklidir.

DRY’yi Körü Körüne Uygulamanın Riskleri

Tekrarı azaltmaya çalışırken, sıklıkla kırılgan abstraksiyonlar yarattığımızı görürüz.

Dependent method çağrıları gibi karmaşık yapılarla karşılaşabilirsiniz:

Controller
  → Service
      → Manager
          → Helper
              → Interface

Kodun basit bir davranışını anlamaya çalıştığınızda, tüm bileşenleri bir araya getirmenin zor olduğunu göreceksiniz.

Bazen bu abstraksiyonlar, yalnızca birkaç tekrar eden kod satırını kaldırmak için var olurlar ve ürün için gerçek bir değer katmazlar.

Aksine, sıkı bağlılık getirebilir. Sistemin farklı parçaları aynı abstraksiyona bağımlı hale gelir ve bu değişiklik istem dışı yan etkilere yol açabilir.

Tekrarın Gerçekten Daha Güvenli Olduğu Durumlar

İyi bir örnek, istek doğrulamasında ortaya çıkar. Laravel’de Form Request sınıflarını kullanmak yaygındır:

class StoreUserRequest extends FormRequest
{
    public function rules(): array
    {
        return [
            'email' => ['required', 'email'],
            'birth_date' => ['required', 'date', 'before:today'],
        ];
    }
}

Diğer bir isteğinizin de çok benzer bir doğrulama gerektirdiğini hayal edin:

class UpdateUserProfileRequest extends FormRequest
{
    public function rules(): array
    {
        return [
            'email' => ['required', 'email'],
            'birth_date' => ['required', 'date', 'before:today'],
        ];
    }
}

Evet, burada bir tekrar var. Ancak, paylaşılacak bir abstraksiyon çıkarmak, aslında bağımsız istekler arasında bağımlılığı artırabilir.

Bir istekteki doğrulama değiştiğinde, genellikle diğerlerini etkilemek istemezsiniz.

Pratik Bir Kural

DRY ilkesini alan veya iş mantığı ile çalışırken kullanın. RUG ilkesini ise scaffolding kodunda kullanmanız önerilir, çünkü tekrar:

• Mantığı açık tutar
• Gereksiz bağımlılığı önler
• Kodu anlamayı kolaylaştırır

Anahtar, her tekranın kötü olmadığını tanımaktır. Bazen en iyi abstraksiyon, henüz var olmayanıdır.

Bu düşünceyi tamamlarken, her zaman karar alma aşamasında benimle birlikte kalan bir fikri hatırlıyorum:

İyi kod, atması kolay olan koddur.

Bu, kodu silmek istediğimiz için değil. Kod basit, açık ve düşük bağlılığa sahip olduğunda, değişiklik yapmak, değiştirmek ve geliştirmenin güvenli hale geldiği anlamına gelir.