Yazılım Geliştirmede YAGNI Prensibi: O Soyutlama ya da Genel Koda Gerçekten İhtiyacınız Var mı?

YAGNI Nedir? İhtiyaç Duyduğunuzu İleriye Dönük Olarak İnşa Etmeyin

Bu tartışmanın merkezinde, YAGNI ilkesi yer alır, ki bu, Asla İhtiyacınız Olmayacağınıza dair bir uyarı — Yaklaşık Programlama ve yalın yazılım geliştirmede önemli bir kavramdır. Derek'in açıkladığı gibi, YAGNI, geliştiricilere gelecekte ihtiyaç duyacaklarını düşündükleri özellikleri veya işlevleri uygulamamalarını, onun yerine mevcut gereksinimlere odaklanmalarını söyler.

Derek daha fazla incelik katar: Sosyal kodlamadan kaçınırken, aynı zamanda ileride uyum sağlamaktan da kaçınmamalısınız. Zorluk, faydalı olabileceği özelliklere zaman harcamaktan kaçınmak, ancak yine de değişime açık olmaktır. Bu, çevik yazılım ve yazılım mühendisliğinde yaygın bir ikilemdir.

İki yaygın YAGNI yanlış uygulamasını şu şekilde açıklar:

1. Özellik Planlaması – Gelecek gereksinimlerini tahmin eder ve şimdi inşa etmeye başlarsınız.

2. Kod Soyutlamaları – Diğer özelliklerin ihtiyaç duyulabileceğini tahmin ederek mevcut kodu çok erken genelleştirir veya soyutlaştırırsınız.

Her iki durumda da, genellikle israf edilen çaba, ek karmaşıklık ve özellik büyümesi sonucunu ortaya çıkarması – iyi uygulama ve KISS ilkesinin (Keep It Simple, Stupid) teşvik ettiği şeylerin tam tersidir.

Gerçek Bir Örnek: Gönderi Bildirim Sistemi

İllüstrasyon için, Derek kullanıcının paketi teslim edildiğinde SMS gönderen bir gönderi yönetim sistemi örneğini kullanır. Sistem Twilio kullanır ve işlev ders gönderi olayını ele alarak, iletişim bilgilerini alır ve bir mesaj gönderir.

Bu basit kod geliştirme süreci mevcut gereksinimleri karşılar. Bu basit, test edilebilir ve değer sağlar. Ancak daha sonra şu soru ortaya çıkar: Gelecekte SMS sağlayıcılarını değiştirmek istesek ne olur?

Derek bu noktada, birçok geliştiricinin YAGNI ilkesini yanlış uyguladığını belirtir. Başka bir uygulamanın gelecekte olabileceği sahteken, SMS mantığını şu anda soyutlaştırmaları gerektiğini varsayarlar. Bu yüzden ISmsService gibi bir arayüz oluştururlar.

Soyutlamalar: Var Olmayabilecek Bir Gelecek İçin mi İnşa Ediyorsunuz?

Derek, bu erken soyutlamayı tartışır: yalnızca bir uygulamanız varsa ve sağlayıcıları değiştirmek gibi mevcut bir gereksiniminiz yoksa neden soyutluyorsunuz ki? Hiç gerçekleşmeyebilecek gelecekteki bir ihtiyaçta hayatı kolaylaştırmak için gereksiz bir karmaşıklık ekliyorsunuz.

Daha da ileri giderek yazılım mühendisliği maliyetine dikkat çeker. Nihayetinde ikinci bir sağlayıcı eklediğinizde, arayüzünüzün Twilio'nun spesifik ihtiyaçlarına ("from" telefon numarası mantığı gibi) çok sıkı bir şekilde bağlı olduğunu fark edersiniz. Aniden, soyutlama bir yük haline gelir. Sınırlı bilgi üzerinde inşa edilen soyutlamaların genellikle hatalar tanıştırmasının ve yeniden yapılandırmayı karmaşık hale getirmesinin nedeni budur.

Burada alınacak ana nokta şu: Zaman kazanmıyorsunuz, yetersiz bağlam nedeniyle yanlış bir şey inşa ediyorsunuz.

Çok Erken Genel Olmak: Bir Geliştirici Tuzağı

Bilgisayar bilimi projelerinde en yaygın YAGNI ihlallerinden biri, şeylerin ihtiyaç duymadan önce genel hale getirme itkisidir. Derek, başka bir örnek aracılığıyla bunu ele alıyor—SMS ve e-posta bildirimlerini tek bir genel bildirim sisteminde gruplamak.

Bunu yapmak için bir geliştirici, bir Bildirim Türü (SMS veya E-posta), evrensel bir adres alanı tanımlayabilir ve her ikisini ele alacak tek bir hizmet oluşturabilir. Ancak bu aşırı soyut tasarım, mantığı karmaşık hale getirir ve yönetimi zor, kırılgan koşullu kod yolları oluşturur.

Bu, klasik bir özellik tıkanıklığıdır ve yalın yazılım geliştirme ve sağlam ilkeleri görmezden gelmenin simgesidir. Kullanıcıların acil ihtiyaçlarına hizmet etmeyen tahmin edici bir kod yazıyorsunuz—herhangi bir çevik yazılım geliştirme sürecinde kırmızı bir bayrak.

Değişim Yerine Genişletmeyi Tercih Edin

Aşırı mühendislik yapmak yerine, Derek en basit çözüm yaklaşımını önermektedir: daha sonra e-posta bildirimlerini desteklemeniz gerekirse, bu özelliği ayrı ayrı uygulayın.

Olay odaklı bir mimari kullanarak, her olay birden fazla bağımsız işleyici tetikleyebilir. Örneğin, bir işleyici SMS için, diğeri e-posta için. Birini etkilenmeden kaldırabilirsiniz. Bu yöntem, sadeliği teşvik eder, değişen gereksinimleri destekler ve endişelerin ayrılmasını sağlar - hepsi çevik ve test odaklı geliştirme en iyi uygulamalarıyla uyumludur.

Sistemleri aşırı tasarlanmadan genişletilebilir inşa ederek, tüm olası gelecekleri tahmin etmeden esnekliği korursunuz. Bu, gereksiz karmaşıklıktan kaçınmanın ve uyumlu kalmanın yoludur.

YAGNI'yi İhlal Etmenin Gerçek Maliyeti

Derek, gereksiz özellikler inşa etmenin gerçek maliyetine dikkat çeker:

• Hiçbir zaman kullanmadığınız bir şeyi inşa etmek için harcadığınız zaman

• Derhal değer sağlamayan eklenen karmaşıklık

• Artık kullanılmayan veya aşırı inşa edilmiş kodu sürdürmesi gereken geliştiriciler için artan sahiplik maliyeti

• Fazla mühendislik nedeniyle hatalar ve hatalar için daha fazla alan

Bu, çevik yazılım geliştirme prensiplerinden bir diğeriyle uyumludur: şimdi değer sağlamak üzerinde odaklanın, muhtemel olmayan gelecekte değil.

Tecrübeli geliştiricilerin genellikle gelecek ihtiyaçlar hakkındaki içgüdülerine güvenme hatasına düştüğünü ve yanıldığını belirtiyor. Tecrübeye rağmen, sisteminizin aylar sonra ne gerektireceğini tahmin etmek genellikle kaybedilen bir oyundur.

Son Düşünceler: Bağlam Önemlidir, Sadelik Kazanır

Derek, tasarım ilkelerine veya soyutlamalara karşı olmadığını açıklayarak konuyu toparlar. Aslında, evrimleşebilecek sistemler inşa etmeye inanır. Ancak hata, mevcut gerekçelendirme olmadan şeyleri uygulamada—temelde YAGNI'yi ihlal etmektedir.

Geliştiricileri şimdi değeri olan kod ve özellikler yazıp uygulamaya teşvik eder. Mevcut kullanıcılarınız pahasına gelecekteki gereksinimlerin peşinden gitmekten kaçının. Temiz kod uygulamalarına bağlı kalın ve sizi spekülatif yapılara kilitlemeden değişimi destekleyen tasarım stratejilerini tercih edin.

Ayrıca, geleceğe yönelik inşa edip asla ihtiyaç duymadıkları YAGNI korkunç hikayelerini paylaşmaya geliştiricileri davet eder—birçok projede yaygın bir hikaye.

Sonuç: YAGNI'yi Geliştirme Sürecinize Uygulayın

YAGNI ilkesi, bir geliştiricinin araç kutusundaki en değerli araçlardan biri olarak kalır. Bu, sadece ihtiyaç olanı inşa et—fazlasını değil diyerek bizi hatırlatan çeviklik, yalın ve KISS felsefeleriyle uyumludur. Bu fikrin Derek Comartin'in videosunda, gerçek dünya kodu ve geliştirme süreci örnekleri ile nasıl etkili bir şekilde uygulanacağına dair açık bir rehber sunmaktadır.

Bu yüzden, soyutlamanın bir tabakasını, genel sınıfı veya ekstra bir özelliği eklemek için cazip olduğunuzda durun ve kendinize şunu sorun:

Sahip olduğunuz bir sorunu mu çözüyorsunuz

Hayali geleceklere zaman harcamaktan kaçının. Bugün değer inşa etmeye odaklanın. Yazılımınızı basit, sürdürülebilir ve gerçek ihtiyaçlara duyarlı tutun.

Çünkü büyük olasılıkla—ihtiyacınız olmayacak.