Koddaki tekrarları çok erken kaldırmamak için nedenler
- DRY(Don't Repeat Yourself) ilkesi çok katı uygulanırsa "premature" soyutlamaya yol açabilir ve gelecekteki değişiklikleri daha karmaşık hale getirebilir
- Tekrarın gerçekten gereksiz olup olmadığını ya da zamanla bağımsız olarak gelişecek bir işlev olup olmadığını düşünmek gerekir
- Fonksiyonlar veya sınıflar aynı görünebilir ama farklı bağlamlara ve iş gereksinimlerine sahip olabilir
- Kodu kısaltmaktan çok, fonksiyonun amacının zaman içinde korunup korunmayacağını düşünmek gerekir
- Soyutlamanın riski: Özelliklerin farklı yönlerde gelişme olasılığı varsa soyutlama tersine zararlı olabilir
- Soyutlama tasarlarken, uzun vadede ayrı ayrı gelişebilecek davranışları erken aşamada birbirine bağlamamak gerekir
- Şüphe duyulduğunda, zaman içinde bu birleşimi haklı çıkaracak kadar güçlü ortak kalıplar ortaya çıkana kadar davranışları ayrı tutmak gerekir
- Küçük ölçekte, premature soyutlamanın karmaşıklığını çözmektense tekrarı yönetmek daha basit olabilir
- Geliştirmenin erken aşamalarında bir miktar tekrara izin verip soyutlama için beklemek gerekir
- Gelecekteki gereksinimler çoğu zaman öngörülemez
- YAGNI(You Aren't Gonna Need It) ilkesini düşünmek gerekir
- Tekrar ya sorun olmayacaktır ya da zamanla iyi düşünülmüş bir soyutlamaya duyulan ihtiyacı açıkça gösterecektir
10 yorum
Aslında DRY, tekrar varsa bunu azaltacak şekilde uygulanmalı,
ama koda en baştan DRY ölçütüyle bakmak yanlış bir uygulama gibi görünüyor.
Hacker News'teki görüşlerden biri:
DRY ilkesinin yanlış anlaşılması: DRY, kod tekrarını değil, bilgi/bilgi birikimi tekrarını önlemeyi amaçlar. Yalnızca kod tekrarına odaklanmak gereksiz optimizasyona yol açabilir.
Bu görüş bana en çok yakın geleni.
Geçiş dönemlerinde böyle şeyleri çok sık düşünmüyor muyuz? Mükemmel diye bir kod olmadığına göre, her gün kafa yormak da herhalde bizim işimiz. Bence duruma göre değişiyor.
Son zamanlarda yüksek soyutlama düzeyine sahip yapılara şüpheyle bakan yazılar sık sık çıkıyor.
MSA, clean code, SOLID, DRY vesaire...
İnsanlar galiba bu tür kavramlardan yorgunluk duymaya başladı.
Aslında bunlar; okunması kolay, anlaşılması kolay, bellek sızıntısı yapmayan, hatasız ve hızlı kod yazmaya çalışırken başvurulacak birer yol göstericiden ibaret...
Önemli olan, ölçülü biçimde ve şu an içinde bulunduğum iş durumuna uygun şekilde uygulamak olsa gerek.
https://velog.io/@kineo2k/…
Çok iyi bir yazı.
Özellikle waterfall modelinden agile modele geçerken bunun daha da önemli olduğunu düşünüyorum.
Agile olmamıza rağmen geleceği fazla tahmin etmeye çalışıyoruz.
Ne kadar hızlı olmak gerekir ki buna “aceleci” denebilsin?
Cevap çok basit. En başta yaparsanız, bu sadece “aceleci” olmaktır.
Biraz daha zor soru ise, bunu ne zaman yaparsanız “aceleci olmayan” bir şey olacağıdır.
Kelime oyunu gibi ama, en baştan yapmazsanız zaten "aceleci olmayan" bir şey olur sanırım ^^;
Evet, özellikle Agile'da
Hacker News görüşü
DRY ilkesinin erken uygulanması: DRY ilkesini en baştan uygulamak iyidir. Benzer verileri ayrı ayrı ele almak yerine ortak bir kod tabanı kullanmak daha verimlidir.
En iyi pratiklerin önceliği: Tüm en iyi pratikler aynı değildir. Okunabilirlik ve bütünlüğe öncelik vermek önemlidir. Kod yazmak, en uygun pratiği seçme sürecidir.
DRY ilkesinin yanlış anlaşılması: DRY, kod tekrarını değil bilgi/bilgi birikimi tekrarını önlemeyi amaçlar. Yalnızca kod tekrarına odaklanmak gereksiz optimizasyona yol açabilir.
Yeniden kullanılabilirlik sorunu: Belirli bir işlev bazen başka durumlarda yeniden kullanılmaz. Tekrarlanan çalışmayı önlemek için daha iyi bir yaklaşıma ihtiyaç vardır.
Karmaşık DRY çözümlerinin sorunu: Bazen tekrar eden kod, karmaşık bir DRY çözümünden daha iyidir. DRY'yi çok erken uygulamak beklenmedik yapısal sorunlara yol açabilir.
DRY bir en iyi pratik değildir: Tekrar, çoğu zaman soyutlama gerektiğinin bir işaretidir. Düşünmeden yapılan DRY uygulamaları, orta seviye mühendislerin sık yaptığı hatalardandır.
Basit kod örneği: İki işlev tek bir işlevde birleştirilebilir. Refaktör etmenin artılarını ve eksilerini net biçimde açıklamak önemlidir.
DRY kodun bakım sorunu: DRY kod karmaşıklaşabilir ve bakımı zorlaşabilir. Buna karşılık WET kod basittir ama değişiklikleri daha öngörülebilirdir.
DRY ilkesinin yan etkileri: DRY ilkesi kod tabanını karmaşıklaştırıp bakımını zorlaştırabilir. Bazı clean code kitapları sektöre olumsuz etki etti.
Genelleştirme ve performans: Genelleştirme performansı olumsuz etkileyebilir. Belirli veri kalıplarına göre yapılmış kod tekrarı, performans optimizasyonuna yardımcı olabilir.